关于依赖和耦合：从小国寡民到和谐社会

　　在老子的“小国寡民”论中，提出了一种理想的社会状态：邻国相望，鸡犬之声相闻，民至老死，不相往来。这是他老人家的一种社会理想，老死不相往来的人群呈现了一片和谐景象。因为不发生瓜葛，也就无所谓关联，进而无法导致冲突。这是先祖哲学中的至纯哲理，但理想的大同总是和现实的生态有着或多或少的差距，人类社会无法避免联系的发生，所以小国寡民的理想成为一种美丽的梦想，不可实现。同样的道理，映射到软件“社会”中，也就是软件系统结构中，也预示着不同的层次、模块、类型之间也必然存在着或多或少的联系，这种联系不可避免但可管理。正如人类社会虽然无法实现小国寡民，但是理想的状态下我们推崇和谐社会，把人群的联系由复杂变为简单，由曲折变为统一，同样可以使得这种关联很和谐。所以，软件系统的使命也应该朝着和谐社会的目标前进，对于不同的关系处理，使用一套行之有效的哲学，把复杂问题简单化，把僵化问题柔性化，这种哲学或者说方法，在我看来就是：依赖的哲学，也就是本文所要阐释的中心思想。

　　因为“耦合是不可避免的”，所以首先就从认识依赖和耦合的概念开始，来一步步阐释依赖的哲学思想。

　　（1）什么是依赖和耦合

　　依赖，就是关系，代表了软件实体之间的联系。软件的实体可能是模块，可能是层次，也可能是具体的类型，不同的实体直接发生依赖，也就意味着发生了耦合。所以，依赖和耦合在我看来是对一个问题的两种表达，依赖阐释了耦合本质，而耦合量化了依赖程度。因此，对于关系的描述方式，就可以从两个方面的观点来分析。

　　从依赖的角度而言，可以分类为：

　　● 无依赖，代表没有发生任何联系，所以二者相互独立，互不影响，没有耦合关系。

　　● 单向依赖，关系双方的依赖是单向的，代表了影响的方向也是单向的，其中一个实体发生改变，会对另外的实体产生影响，反之则不然，耦合度不高。

　　● 双向依赖，关系双方的依赖是相互的，影响也是相互的，耦合度较高。

　　从耦合的角度而言，可以分类为（此处回归到具体的代码级耦合概念，以方便概念的阐释）：

　　● 零耦合，表示两个类没有依赖。

　　● 具体耦合，如果一个类持有另一个具体类的引用，那么这两个类就发生了具体耦合关系。所以，具体耦合发生在具体类之间的依赖，因此具体类的变更将引起对其关联类的影响。

　　● 抽象耦合，发生在具体类和抽象类的依赖，其最大的作用就是通过对抽象的依赖，应用面向对象的多态机制，实现了灵活的扩展性和稳定性。

　　不同的耦合，代表了依赖程度的差别，以“粒度”为概念来分析其耦合的程度。引用中间层来分离耦合，可以使设计更加优雅，架构更加富有柔性，但直接的依赖也存在其市场，过度的设计也并非可取之道。因为，效率与性能同样是设计需要考量的因素，过多的不必要分离会增加调用的次数，造成效率浪费。

　　后文分析依赖倒置原则的弊端之一正是对此问题的进一步阐述。

　　（2）耦合是如何产生的

　　那么，软件实体之间的耦合是如何产生呢？回归每天挥洒的代码片段，其实就是在重复的创造着耦合，并且得益于对这种耦合带来的数据通信。如果将历史的目光回归到软件设计之初，人类以简单的机器语言来实现最简单的逻辑，给一个输入，实现一个输出，可以表达为如图3-1所示的形式。

　　随着软件世界的革命，业务逻辑的复杂，以上的简单化处理已经不足以实现更复杂的软件产品，当系统内部的复杂度超越人脑可识别的程度时，就需要通过更科学的方法或者方式来梳理，

　　因此，人类开始发挥重组和简单化处理的优势，开发者不得不在软件设计上做出平衡。平衡的结果就是通过对复杂的系统模块化，把复杂问题简单处理，从而达到能够被人脑识别的目的。基于这种指导原则，随着复杂度的增加模块的划分更加朝着精细化发展，尤其是面向对象程序设计理论的出现，使得对复杂的处理实现了更科学的理论基础。然而，复杂的问题可以通过划分实现简单的功能模块或者技术单元，但由此应运而生的子单元会越来越多，而且越来越多的子单元必须发生数据的通信才能完成统一的业务处理，所以产生的数据通信管理也越来越多。对于子单元的管理，也就是本文关注的核心概念——依赖，成为新的软件设计问题，那么总结前人的经验，提炼今人的智慧，对耦合的产生做如下归纳：