哪种人是软件设计中的稀缺型人才？
|
当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层。
这种看起来“无伤大雅”的设计，实际上还是存在不小的隐患，也违背了我当初想把业务复杂度和技术复杂度分开的初心，当业务变得更加复杂的时候，这种“偷懒”行为很可能会导致Domain层堕落成大泥球(Big mud ball)。因此，在COLA 2.0的时候，我决定用DIP来反转Domain层和Infrastructure层的关系，最终形成如下的结构：
这样做的好处是Domain层会变得更加纯粹，其好处体现在以下三点： 1、解耦： Domain层完全摆脱了对技术细节(以及技术细节带来的复杂度)的依赖，只需要安心处理业务逻辑就好了。2、并行开发： 只要在Domain和Infrastructure约定好接口，可以有两个同学并行编写Domain和Infrastructure的代码。3、可测试性： 没有任何依赖的Domain里面都是POJO的类，单元测试将会变得非常方便，也非常适合TDD的开发。 什么时候不需要接口 "劲酒虽好，可不要贪杯哦!" 和许多其它软件原则一样，面向接口很好，但也不应该是不分背景、不分场合胡乱使用的杀手锏和尚方宝剑。因为过多的使用接口，过多的引入间接层也会带来一些不必要的复杂度。 比如，我就看过有些应用的内部模块设计的过于“灵活”，给什么DAO、Convertor都加上一层Interface，但实际情况是，应用中对DAO、Convertor的实现进行替换的可能性极低。类似于这样的，装模作样，装腔作势的Interface就属于可有可无的鸡骨头(比鸡肋还低一个档次)。 就像《Effective Java》的作者Joshua Bloch所说： “同大多数学科一样，学习编程的艺术首先要学会基本的规则，然后才能知道什么时候可以打破这些规则。” 【编辑推荐】
点赞 0 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
