起因:模块独立性指每个模块只完成系统要求的独立子功能,并且与其他模块的联系最少且接口简单,
两个定性的度量标准――耦合性和内聚性。
耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越
紧密,其耦合性就越强,模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方
式及传递的信息。
耦合性分类(低――高): 无直接耦合;数据耦合;标记耦合;控制耦合;公共耦合;内容耦合;
1 无直接耦合:
2 数据耦合: 指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递;
3 标记耦合: 指两个模块之间传递的是数据结构,如高级语言中的数组名、记录名、文件名等这些名字即标记,其实传递的是这个数据结构的地址;
4 控制耦合: 指一个模块调用另一个模块时,传递的是控制变量(如开关、标志等),被调模块通过该控制变量的值有选择地执行块内某一功能;
5 公共耦合: 指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。
6 内容耦合: 这是最高程度的耦合,也是最差的耦合。当一个模块直接使用另一个模块的内部数据,或通过非正常入口而转入另一个模块内部。
内聚性又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的
度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。
内聚性匪类(低――高): 偶然内聚;逻辑内聚;时间内聚;通信内聚;顺序内聚;功能内聚;
1 偶然内聚: 指一个模块内的各处理元素之间没有任何联系。
2 逻辑内聚: 指模块内执行几个逻辑上相似的功能,通过参数确定该模块完成哪一个功能。
3 时间内聚: 把需要同时执行的动作组合在一起形成的模块为时间内聚模块。
4 通信内聚: 指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据。
5 顺序内聚: 指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素输出就是下一功能元素的输入。
6 功能内聚: 这是最强的内聚,指模块内所有元素共同完成一个功能,缺一不可。与其他模块的耦合是最弱的。
耦合性与内聚性是模块独立性的两个定性标准,将软件系统划分模块时,尽量做到高内聚低耦合,提高模块的独立性,为设计高质量的软件结构奠定基础。
有个例子很容易明白:一个程序有50个函数,这个程序执行得非常好;然而一旦你修改其中一个函
数,其他49个函数都需要做修改,这就是高耦合的后果。
一旦你理解了它,你编写概要设计的时候设计类或者模块自然会考虑到“高内聚,低耦合”。
耦合指的模块之间的关系,最弱的耦合设计是通过一个主控模块来协调n个模
块之间的运作。还是举一个我举过的例子:客户要求在界面上增加一个字段,
你的项目要修改几个地方呢?如果你只要修改项目文档,那么你的开发构架就
是最低强度的耦合,而这种设计 成熟的开发团队都已经做到了,他们使用开发
工具通过项目模型驱动数据库和各层次的代码,而不是直接修改那些代码;
内聚指的是模块内部的功能,最强的内聚就是功能单一到不能拆分,也就是原
子化,所以强内聚和弱耦合是相辅相成的,一个良好的设计是由若干个强内聚
模块以弱耦合的方式组装起来的
1. 低耦合(Low Coupling)
“低耦合”这个词相信大家已经耳熟能详,我们在看spring的书籍、MVC的数据、设计模式的书籍,无处不提到“低耦合、高内聚”,它已经成为软件设计质量的标准之一。那么什么是低耦合?
耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。这里所说的元
素,即可以是功能、对象(类),也可以指系统、子系统、模块。假如一个元
素A去连接元素B,或者通过自己的方法可以感知B,或者当B不存在的时候就不
能正常工作,那么就说元素A与元素B耦合。耦合带来的问题是,当元素B发生变
更或不存在时,都将影响元素A的正常工作,影响系统的可维护性和易变更性。
同时元素A只能工作于元素B存在的环境中,这也降低了元素A的可复用性。正因
为耦合的种种弊端,我们在软件设计的时候努力追求“低耦合”。低耦合就是
要求在我们的软件系统中,某元素不要过度依赖于其它元素。请注意这里
的“过度”二字。系统中低耦合不能过度,比如说我们设计一个类可以不与JDK
耦合,这可能吗?除非你不是设计的Java程序。再比如我设计了一个类,它不
与我的系统中的任何类发生耦合。如果有这样一个类,那么它必然是低内聚
(关于内聚的问题我随后讨论)。耦合与内聚常常是一个矛盾的两个方面。最
佳的方案就是寻找一个合适的中间点。
目前已经有大量的框架帮助我们降低我们系统的耦合度。比如,使用struts我
们可以应用MVC模型,使页面展现与业务逻辑分离,做到了页面展现与业务逻辑
的低耦合。当我们的页面展现需要变更时,我们只需要修改我们的页面,而不
影响我们的业务逻辑;同样,我们的业务逻辑需要变更的时候,我们只需要修
改我们的java程序,与我们的页面无关。
使用spring我们运用IoC(反向控制),降低了业务逻辑中各个类的相互依赖。
假如类A因为需要功能F而调用类B,在通常的情况下类A需要引用类B,因而类A
就依赖于类B了,也就是说当类B不存在的时候类A就无法使用了。使用了IoC,
类A调用的仅仅是实现了功能F的接口的某个类,这个类可能是类B,也可能是另
一个类C,由spring的配置文件来决定。这样,类A就不再依赖于类B了,耦合度
降低,重用性提高了。
使用hibernate则是使我们的业务逻辑与数据持久化分
离,也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数
据放到值对象中,然后交给hibernate,或者从hibernate那里得到值对象。至
于用Oracle、MySQL还是SQL Server,如何执行的操作,与我无关。
本文出自 “我的JAVA世界” 博客,请务必保留此出处http://hanchaohan.blog.51cto.com/2996417/1438990