对于开发者而言,耦合原则表示程序中单个的模块应该尽可能的独立。
处理一个模块时,不应该依赖另一个模块的内部工作。
内聚原则是指,在一个给定的模块内部,所有的代码应该只完成一个单个的目标。
IT界有一句很著名的口号:强内聚、松耦合。
即使是最初级的程序员,在常常的被教导中,他也了解了这句口号的含义:我们的程序要模块化,模块要完成明确的一组关联的服务功能,要求它的各部分是相关的、有机组合起来是完整体(外部程序来看黑盒子),模块的内部各成分之间相关联程度要尽可能高(强内聚);而模块与模块之间又要求是可分拆的、少依赖的(松耦合)。
人们易于实现强内聚的模块,例如:一个函数实现一个独立的功能,这就是强内聚。
人们不易实现松耦合,因为,孤独的模块毫无意义,只有模块间的相互协调地工作,才能实现系统的目的。而对于模块间的相互关系的设计,没有一定的经验是难以把握。耦合的强度依赖于:(1)一个模块对另一个模块的调用;(2)一个模块向另一个模块传递的数据量;(3)一个模块施加到另一个模块的控制的多少;(4)模块之间接口的复杂程度。等等。
当然,“强内聚、松耦合”也是有矛盾的,如:内聚性越强,则要求的函数越多(每个函数只作一件“事”),这样,将它们组合成“大”的功能,也就越复杂,就不可能达到松耦合。因此,应在二者之间作出平衡与折衷的选择,这也体现程序员的水平。从系统论的角度来看,系统是有层次的,即系统可以分为子系统,模块可分为子模块,“强内聚、松耦合”的“度”的把握,应结合系统的次层性来考虑,即通常应在层次性上作出折衷,如:模块内子程序(下一个层次上)应共享数据(有一定的耦合度),而减少全局变量能降低子程序性间的耦合性。
面向对象的语言进一步强化了“强内聚、松耦合”,类的封装性既强调了相关内容(数据及其操作)的内聚,又强调了类的独立性和私密性。而类的继承性以及友元等,就是在松耦合的原则下规范了类之间的关联关系。类与类之间通常通过接口的契约实现服务提供者/服务请求者模式,这就是典型的松耦合。
“强内聚、松耦合”对于程序编写分工、程序的可维护性以及测试都有重要的关系,如:从设计角度来看,在“强内聚、松耦合”的指导下进行的设计得到的程序模块,符合项目管理的WBS(工作分解结构)的要求,其相对独立的模块可以分配到具体的程序员进行开发,另外,程序编码外包也必须建立在这种原则的设计之下;从程序生命期角度来看,它有利于提高程序质量,特别是方便于程序的日后维护,即程序模块的相对独立性是可维护性的保证;再从测试角度来看,符合“强内聚、松耦合”的程序,易于对局部(模块)进行黑盒测试,也易于编写测试用的“桩”和“驱动”。
“强内聚、松耦合”也是对组织结构的要求,项目组分为几个小组(正式的或非正式的),各小组的工作应是高度相关的,各小组之间的工作应尽量是较少相关或有明确的接口,从而减少沟通成本。其实,“强内聚、松耦合”是系统中应遵守的普遍原则,我们在许多领域都可以找到它的应用。
“强内聚、松耦合”是我们不得不念的“三字经”,我们一定要念好它。
转载于:https://www.cnblogs.com/haik/archive/2010/04/02/1703435.html