这篇文章应该算作前两篇文章的后续思考。 在前两篇文章中，考虑到了分层的方法，参考了别人的代码架构。

其实我们说到最后，好的代码，我们分层，做模块，无非就是实现一个高内聚和低耦合。 举个简单的例子，将某个模块代码直接删除之后，将上层调用处注释，重新编译，是否还能编过？（不考虑功能的运行） 如果还能，说明这个模块和同层的其他模块没有耦合性，即同级的模块不依赖这个模块的实现，不依赖这个模块的结构体，这个模块就有高内聚和低耦合。

内聚，耦合。 这两个词说了很多遍，究竟具体在说什么？

什么是内聚性。 内聚性由由Larry_Constantine提出，WIKI 是这么介绍的：

内聚性（Cohesion）也称为内聚力，是一软件度量，是指机能相关的程序组合成一模块的程度[1]，或是各机能凝聚的状态或程度[2]。是结构化分析的重要概念之一。量测内聚性的方式很多，有些方法是由分析源代码，得到非量化的结果，有些方法则是检查源代码的文本特征，以得到内聚性的量化分数。内聚性是属于顺序式的量测量，一般会以“高内聚性”或“低内聚性”来表示。一般会希望程序的模块有高内聚性，因为高内聚性一般和许多理想的软件特性有关，包括鲁棒性、可靠度、可复用性及易懂性（understandability）等特性，而低内聚性一般也代表不易维护、不易测试、不易复用以及难以理解。 耦合性是一个和内聚性相对的概念。一般而言高内聚性代表低耦合性，反之亦然。内聚性是由赖瑞·康斯坦丁所提出，是以实务上可减少维护及修改的“好”软件的特性为基础[3]。

什么是耦合性。 耦合性由由Larry_Constantine提出，WIKI 是这么介绍的：

耦合性（英语：Coupling，dependency，或称耦合力或耦合度）是一种软件度量，是指一程序中，模块及模块之间信息或参数依赖的程度。 内聚性是一个和耦合性相对的概念，一般而言低耦合性代表高内聚性，反之亦然。耦合性和内聚性都是由提出结构化设计概念的赖瑞·康斯坦丁所提出[1]。低耦合性是结构良好程序的特性，低耦合性程序的可读性及可维护性会比较好。

耦合主要分为以下几类，耦合度从低到高，分别是：

非直接耦合 < 数据耦合 < 标记耦合 < 控制耦合 < 外部耦合 < 公共耦合 < 内容耦合

控制耦合 如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。 偷一张别人的图，看的很明白： 不论这个Flag是怎么传过来的，在功能逻辑上，B模块是依赖于A模块的。

外部耦合(External Coupling) 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。 举个例子，DE模块都直访问了一个全局变量，而不是通过入参传入。

公共耦合 若一组模块都访问同一个公共数据环境，则他们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。 类似外部耦合，只不过依赖不再是简单变量。

内容耦合 又称病态耦合。如果发生下列情形，两个模块之间就发生了内容耦合。

在内容耦合的情形，所访问模块的任何变更，或者用不同的编译器对它再编译，都会造成程序出错。好在大多数高级程序设计语言已经设计成不允许出现内容耦合。它一般出现在汇编语言程序中。这种耦合是模块独立性最弱的耦合。

依赖注入、命名查找

我的观点是： 高内聚，低耦合肯定是我们的追求，但并不是内聚越高，耦合越低就一定好，并非要是使用很多兜圈子的代码来降低耦合，我们应该允许单向调用。