哪种人是软件设计中的稀缺型人才？

当logback出来之后，事情开始变得复杂，当我们想替换一个新的logger vendor的时候，为了尽量减少代码改动，不得不上各种Bridge(桥接)，到最后日志代码变成了谁也看不懂的代码迷宫。下图就是我费了九头二虎之力，才梳理清楚的一个老业务系统的日志框架依赖情况。

试想一下，假如一开始我们就能遇见到这种紧耦合带来的问题。在应用和日志框架之间加入一层抽象解耦。后续的那么多桥接，那么多的向后兼容都是可以省掉的麻烦。而我们所要做的事情，实际上也很简单——就是加一个接口做解耦而已(如下图所示)：

要给外界提供API的时候

上文已经介绍过JCP和JSR了，大家有空可以去阅读一些JSR的文档。不管是做的比较成功的JSR-221(JDBC规范)、JSR-315(Servlet规范)，还是比较失败的JSR-94(规则引擎规范)等等。其本质上都是在定义标准、和制定API。其规范的内容都是抽象的，其对外发布的形式都是接口，它不提供实现，最多会指导实现。

还有就是我们通常使用的各种开放平台的SDK，或者分布式服务中RPC的二方库，其包含的主要成分也是接口，其实现不在本地，而是在远程服务提供方。

类似于这种API的情况，都是在倒逼开发者要把接口想清楚。我想，这也算微服务架构一个漂亮的“副作用”吧。当原来单体应用里的各种耦合的业务模块，一旦被服务化之后，就自然而然的变成“面向接口”的了。

通过依赖倒置来实现面向接口(How)

关于依赖倒置，我以前写过不少文章，来阐述它的重要性。实际上，我上面给出的关于扩展需求的Switch案例，关于解耦的logger案例。其背后用来解决问题的方法论都是依赖倒置。

如上图所示，依赖倒置原则主要规定了两件事情：

1. 高层模块不应该依赖底层模块，两者都应该依赖抽象(如上面的图2所示)

2. 抽象不应该依赖细节，细节应该依赖抽象。

我们回头看一下，不管是Switch的设计，还是抽象Logger的设计，是不是都在遵循上面的两条定义内容呢。

实际上，DIP(依赖倒置原则)不光在对象设计，模块设计的时候有用。在架构设计的时候也非常有用，比如，我在做COLA 1.0的时候，和大多数应用架构分层设计一样，默许了Domain层可以依赖Infrastructure层。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!