| « | June 2026 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | |
|
公告 |
| 暂无公告... |
| Blog信息 |
|
blog名称:
日志总数:83
评论数量:123
留言数量:0
访问次数:270212
建立时间:2006年8月17日 |
| |
|
 [软件设计]强内聚与松耦合
文章收藏, 软件技术
lylhelin 发表于 2008/3/3 17:46:09 |
|
http://www.educity.cn 作者：漆英 来源：学赛网 2005年10月12日
IT界有一句很著名的口号：强内聚、松耦合。
即使是最初级的程序员，
在常常的被教导中，他也了解了这句口号的含义：我们的程序要模块化，模块要完成明确的一组关联的服务功能，要求它的各部分是相关的、有机组合起来是完整体
(外部程序来看黑盒子)，模块的内部各成分之间相关联程度要尽可能高(强内聚);而模块与模块之间又要求是可分拆的、少依赖的(松耦合)。
人们易于实现强内聚的模块，例如：一个函数实现一个独立的功能，这就是强内聚。
人们不易实现松耦合，因为，孤独的模块毫无意义，只有模块间的相互协调地工作，才能实现系统的目的。而对于模块间的相互关系的设计，没有一定的
经验是难以把握。耦合的强度依赖于：(1)一个模块对另一个模块的调用;(2)一个模块向另一个模块传递的数据量;(3)一个模块施加到另一个模块的控制
的多少;(4)模块之间接口的复杂程度。等等。
当然，“强内聚、松耦合”也是有矛盾的，如：内聚性越强，则要求的函数越多(每个函数只作一件“事”)，这样，将它们组合成“大”的功能，也就
越复杂，就不可能达到松耦合。因此，应在二者之间作出平衡与折衷的选择，这也体现程序员的水平。从系统论的角度来看，系统是有层次的，即系统可以分为子系
统，模块可分为子模块，“强内聚、松耦合”的“度”的把握，应结合系统的次层性来考虑，即通常应在层次性上作出折衷，如：模块内子程序(下一个层次上)应
共享数据(有一定的耦合度)，而减少全局变量能降低子程序性间的耦合性。
面向对象的语言进一步强化了“强内聚、松耦合”，类的封装性既强调了相关内容(数据及其操作)的内聚，又强调了类的独立性和私密性。而类的继承
性以及友元等，就是在松耦合的原则下规范了类之间的关联关系。类与类之间通常通过接口的契约实现服务提供者/服务请求者模式，这就是典型的松耦合。
“强内聚、松耦合”对于程序编写分工、程序的可维护性以及测试都有重要的关系，如：从设计角度来看，在“强内聚、松耦合”的指导下进行的设计得
到的程序模块，符合项目管理的WBS(工作分解结构)的要求，其相对独立的模块可以分配到具体的程序员进行开发，另外，程序编码外包也必须建立在这种原则
的设计之下;从程序生命期角度来看，它有利于提高程序质量，特别是方便于程序的日后维护，即程序模块的相对独立性是可维护性的保证;再从测试角度来看，符
合“强内聚、松耦合”的程序，易于对局部(模块)进行黑盒测试，也易于编写测试用的“桩”和“驱动”。
“强内聚、松耦合”也是对组织结构的要求，项目组分为几个小组(正式的或非正式的)，各小组的工作应是高度相关的，各小组之间的工作应尽量是较少相关或有明确的接口，从而减少沟通成本。其实，“强内聚、松耦合”是系统中应遵守的普遍原则，我们在许多领域都可以找到它的应用。
“强内聚、松耦合”是我们不得不念的“三字经”，我们一定要念好它。(2003-8)
|
|
|