2.5 低耦合 Low Coupling

低耦合 是我们耳朵听出茧子的一个专业名词了,但却并非只是一个行业用语,而是每个行业每个组织都追求的一个目标。做不到低耦合,有何谈权责划分明晰的职责分配,如果连你、我之间的边界都不清晰,谁都想做别人的主,那岂不是满大街都是上帝了?

 

对于广大读者来说,我觉得应该没必要解释 “耦合” 是啥意思了,想想自己刚入行时写的代码,想想修改代码时牵一发动全身的连环车祸现场,你就知道啥是“高耦合”,“低耦合” 取个反就行了。

 

要想实现低耦合的目标,首先要做到 信息专家 ,信息专家倡导的就是把专业的事交给专业的人做,但是只有“信息专家”这一条原则还是远远不够的,因为 “低耦合” 有更高的精神追求,它要解决更高层面的问题:“如何减少因变化产生的影响?”,为了达成这个目标,核心工作就是要减少 依赖性(类与类之间的依赖,对象与对象之间的依赖,组件与组件之间的依赖,系统与系统之间的依赖),只要依赖性降低了,目标就达到了一半,另一半则是要提升重用性和扩展性。

 

“继承”、 “组合”、“接口” 会成为实现 “低耦合” 的重要技术手段,但是我仍然不希望文章中出现代码。我们会使用各种模式和方法和实现 “低耦合”。“观察者模式”、“装饰者模式”、“工厂模式”、“抽象工厂”、“策略模式”、“适配器模式” 等等都可以辅助我们实现低耦合,以及目前大行其道的依赖注入IOC容器,都可以将耦合降低到非常低的程度。

 

面向接口编程 是我们常常挂在嘴边的装 B 词汇,但是真到了工作的时候,我们大部分人采用的仍然是 针对具体实现编程,不同的解决方案之间的替换也没有做到统一的定义和规范性的要求,我们不能只是简单的对接口的语法调用非常熟悉,而是能真正的从业务出发,提炼出业务中的不同功能模块的体现核心价值的向外开放的功能接口,学会面向抽象的接口编程,而不是拘泥于具体的实现,利用面向接口编程的方式,对于测试也极为友好,也简化了测试的工作。

 

作为程序的设计者,程序的灵活性和可扩展性虽然非常重要,但也不要过度,“低耦合” 并不是降低程序执行效率的借口,不能为了低耦合这一个目标而放弃整个森林。其实坦白来说,高耦合本身没啥问题,如果你要做的软件系统本身就很“稳定”,模块,系统,对象,数据都按照一个万年不变的方式运行,以后也不会有啥变的话,那再高的耦合度都能接受。 我们必须在降低耦合和封装之间进行良好的权衡和取舍,要有能力识别出程序中可变和不可变的部分,对于不可变的部分,耦合就耦合吧,这个时候为了效率可以牺牲代码的可维护性和可扩展性。而对于经常变化的部分或者极其不稳定的部分,请一定要对自己好一点,耦合一定要低,不然以后天天晚上加班的一定是你,而导致你加班流泪到深夜哽咽唱着妇人叹的不是别人,Just Yourself !这其实也是为什么新人加班比较多的一部分原因,由于经验和实践能力的不足,做出来的程序只是能满足当前短期内的需要,一旦出现更多的场景和变化,程序马上就搞不定了,必须推翻重来。很多新人会抱怨工作时间太长,而其实抱怨的未必有道理,有时真的是由于自己的原因。

 

达不到低耦合这个目标,还有一种情况难以避免。不是编程技术不够,而是对业务理解不够透彻,这种情况下,不要折磨自己和身边的技术人员,把负责业务的人拉过来,让他给技术团队做培训,让他们帮助识别可变和不可变的因素,把业务中不同阶段的规则都详细的讲给开发者,并共同研究实现方案。耦合不光有技术层面的,还有社会分工协作层面的,不能因为我们从事了技术这个行业,就把这部分的内容给忽视了,技术应用的再多,再高大上,没有解决业务问题,一切都是浮云~

 

我们会发现,我们无法把 “低耦合”,“信息专家”,“高内聚”,“间接沟通”,“预防变化” 等等原则分拆开,都是你中有我,我中有你的。但是 耦合和内聚是程序设计中真正核心的基本原则,做到了“低耦合”,我们的工作就会变得更加简单,它会带来很多的有点:

 

  • 当前构件不受其他构件变化的影响
  • 易于单独理解
  • 便于复用
  • 代码易维护,好修改,减少不必要的加班
  • 有时间交女朋友 

 

其实怎么才算是“ 低耦合” 真的没有一个衡量标准,如果你是 一个人开发项目,自己舒服就好哪怕是 “中度耦合” 也没啥关系。如果是团队协作的项目,则要避免 过低耦合,因为很多公司会出现这种状况,为了追求更低的耦合而设计大量无意义的辅助类,比买椟还珠还荒谬。