内聚性和耦合性

内聚性

内聚性,又称块内联系,指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。内聚性是对一个模块内部各个组成元素之间相互结合的紧密程度的度量指标。模块中组成元素结合的越紧密,模块的内聚性就越高,模块的独立性也就越高。理想的内聚性要求模块的功能应明确、单一,即一个模块只做一件事情。模块的内聚性和耦合性是两个相互对立且又密切相关的概念。

内聚性从弱到强:

(1) 偶然内聚:模块中的代码无法定义其不同功能的调用。但它使该模块能执行不同的功能,这种模块称为巧合强度模块。

(2) 逻辑内聚:这种模块把几种相关的功能组合在一起, 每次被调用时,由传送给模块参数来确定该模块应完成哪一种功能

(3) 时间内聚:把需要同时执行的动作组合在一起形成的模块为时间内聚模块。

(4) 过程内聚:构件或者操作的组合方式是,允许在调用前面的构件或操作之后,马上调用后面的构件或操作,即使两者之间没有数据进行传递。

(5) 通信内聚:指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据。

(6) 顺序内聚:指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素输出就是下一功能元素的输入。即一个模块完成多个功能,这些模块又必须顺序执行

(7) 功能内聚:这是最强的内聚,指模块内所有元素共同完成一个功能,联系紧密,缺一不可。

耦合性

耦合性也叫块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。

模块之间联系越紧密,其耦合性就越强,模块的独立性则越差,模块间耦合的高低取决于模块间接口的复杂性,调用的方式以及传递的信息。

(独立性由强到弱)

非直接耦合(Nondirect Coupling)

如果两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的,这就是非直接耦合。这种耦合的模块独立性最强。

数据耦合(Data Coupling)

如果一个模块访问另一个模块时,彼此之间是通过数据参数(不是控制参数、公共数据结构外部变量)来交换输入、输出信息的,则称这种耦合为数据耦合。由于限制了只通过参数表传递数据,按数据耦合开发的程序界面简单、安全可靠。因此,数据耦合是松散的耦合,模块之间的独立性比较强。在软件程序结构中至少必须有这类耦合。

印记耦合(Stamp Coupling)

如果一组模块通过参数表传递记录信息,就是标记耦合。事实上,这组模块共享了这个记录,它是某一数据结构的子结构,而不是简单变量。这要求这些模块都必须清楚该记录的结构,并按结构要求对此记录进行操作。在设计中应尽量避免这种耦合,它使在数据结构上的操作复杂化了。如果采取“信息隐蔽”的方法,把在数据结构上的操作全部集中。

控制耦合(Control Coupling)

如果一个模块通过传送开关、标志、名字等控制信息,明显地控制选择另一模块的功能,就是控制耦合。这种耦合的实质是在单一接口上选择多功能模块中的某项功能。因此,对所控制模块的任何修改,都会影响控制模块。另外,控制耦合也意味着控制模块必须知道所控制模块内部的一些逻辑关系,这些都会降低模块的独立性。

外部耦合(External Coupling)

一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息,则称之为外部耦合。例如C语言程序中各个模块都访问被说明为extern类型的外部变量。外部耦合引起的问题类似于公共耦合,区别在于在外部耦合中不存在依赖于一个数据结构内部各项的物理安排。

公共耦合(Common Coupling)

若一组模块都访问同一个公共数据环境,则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。 这种耦合会引起下列问题:

所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关,若修改某个数据的大小,将会影响到所有的模块。

无法控制各个模块对公共数据的存取,严重影响软件模块的可靠性和适应性。

公共数据名的使用,明显降低了程序的可读性。

公共耦合的复杂程度随耦合模块的个数增加而显著增加。若只是两个模块之间有公共数据环境,则公共耦合有两种情况。

若一个模块只是往公共数据环境里传送数据,而另一个模块只是从公共数据环境中取数据,则这种公共耦合叫做松散公共耦合。若两个模块都从公共数据环境中取数据,又都向公共数据环境里送数据,则这种公共耦合叫做紧密公共耦合。只有在模块之间共享的数据很多,且通过参数表传递不方便时,才使用公共耦合。否则,还是使用模块独立性比较高的数据耦合好些。

内容耦合(Content Coupling)耦合性最高,最差的设计

如果发生下列情形,两个模块之间就发生了内容耦合。

一个模块直接访问另一个模块的内部数据;

一个模块不通过正常入口转到另一模块内部;

两个模块有一部分程序代码重叠(只可能出现在汇编语言中);

一个模块有多个入口。

在内容耦合的情形,所访问模块的任何变更,或者用不同的编译器对它再编译,

都会造成程序出错。好在大多数高级程序设计语言已经设计成不允许出现内容

耦合。它一般出现在汇编语言程序中。这种耦合是模块独立性最弱的耦合。

内聚性和耦合性,布布扣,bubuko.com

时间: 2024-10-27 12:26:18

内聚性和耦合性的相关文章

php设计模式及耦合性和多形性

什么是设计模式: 设计模式就是一个教你如何利用真实可靠的设计来组织你的代码的模板. 所有的设计模式都有一些常用的特性:一个标识(a name),一个问题陈述(a problem statement)和一个解决方案(a solution). 1.一个设计模式的标识是重要的,因为它会让其他的程序员不用进行太深入的学习就能立刻理解你的代码的目的(至少通过这个标识程序员会很熟悉这个模式). 2.问题描述是用来说明这个模式的应用的领域. 3.解决方案描述了这个模型的执行.一个好的设计模式的论述应该覆盖使用

耦合性

耦合性 耦合性(Coupling),也叫耦合度,是对模块间关联程度的度量.耦合的强弱取决与模块间接口的复杂性.调用模块的方式以及通过界面传送数据的多少.模块间的耦合度是指模块之间的依赖关系,包括控制关系.调用关系.数据传递关系.模块间联系越多,其耦合性越强,同时表明其独立性越差.软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.划分模块的一个准则就是高内聚低耦合. 基本信息 耦合性(或称“耦合度”) 英文 : coupling 耦合性也叫块间联系.指软件系统结构中各模块间相互联系紧密程度

浅谈 Redis 与 MySQL 的耦合性以及利用管道完成 MySQL 到 Redis 的高效迁移

http://blog.csdn.net/dba_waterbin/article/details/8996872 ㈠ Redis 与 MySQL 的耦合性            在业务架构早期.我们便该"吃着碗里的看着锅里的".切莫让MySQL 有梦.而Redis 无心    毕竟.有些关系型的结构不适合放到Redis跑."男女搭配.干活不累"嘛.推荐让MySQL与Redis喜结连理        其次.这 2 人.一般是在不同场景做选择.而不会在性能上选择. 

第7周作业--耦合性

耦合式对一个软件结构内不同模块之间互联程度的度量.耦合强弱取决于接口的复杂度, 进入或访问某一模块的点,以及通过接口的数据.一般模块之间的可能的连接方式有七种, 构成耦合的七种类型,它们的关系为: A. 非直接耦合:两个模块没有直接的关系(模块1和模块2),独立性最强 B.数据耦合:即一个模块访问另一个模块的时候,彼此之间是通过数据参数来交换输入.输出信息的,这种耦合为数据耦合.这种耦合较为松散,模块间独立性较强. C.特征耦合:即一组模块通过参数传递记录信息,用户情况是个数据结构,图中模块都与

追踪CM_CONTROLCHANGE消息的产生和执行过程,可以较好的领会VCL的思想(就是到处通知,但耦合性很弱)

追踪CM_CONTROLCHANGE消息的流向,可以较好的 测试代码: procedure TForm1.Button1Click(Sender: TObject);var Image2 : TImage;beginImage2 := TImage.Create(self);Image2.Left := 100;Image2.Top := 50;Image2.Picture.LoadFromFile('c:\pic.jpg');Image2.Parent := Form1;end; proced

O-C相关-05:对象与对象的关系

对象与对象的关系 1.对象与对象的关系 依赖 关联 组合 常常讨论对象与对象关系时会提供两个属于:内聚性,耦合性 内聚一般指功能上的指向性 耦合一般指关联上的依赖性 2.依赖: 对象之间最弱的一种关联方式,是临时性的关联.代码中一般指由局部变量.函数参数.返回值建立的对于其他对象的调用关系. 依赖一般情况下是以下几种情况之一: a.ClassA中某个方法的参数类型是ClassB:  这种情况成为耦合: b.ClassA中某个方法的参数类型是ClassB的一个属性: 这种情况成为紧耦合: c.Cl

深圳移动笔试回忆

深圳移动笔试回忆: 1.内聚性和耦合性是度量软件模块独立性的重要准则,软件设计时应力求耦合低,内聚高 2.在开发一个系统时,如果用户对系统的目标不很清楚,难以定义需求,这时最好使用_A_____.A.原型法B.瀑布模型C.V-模型D.螺旋模型 原型法适合于用户需求不明确的场合.它是先根据已知的和分析的需求,建立一个原始模型,这是一个可以修改的模型.在软件开发的各个阶段都把有关信息相互反馈,直至模型的修改,使模型渐趋完善.在这个过程中,用户的参与和决策加强了,缩短了开发周期,降低了开发风险,最终的

教你写Android网络框架之基本架构

转载请注明出处,本文来自[ Mr.Simple的博客 ]. 我正在参加博客之星,点击这里投我一票吧,谢谢~ 前言 在前段时间,偶然参加了博客之星的评选,也偶然的进入到了鸿洋和任玉刚两知名博主的开发群,感受到了很浓厚的技术探讨氛围,于是自己也冒出了写一些系列博客的想法.虽说本人水平有限,但是也希望自己的博客能够帮到一些需要帮助的人.需要你是高手,那么显然不适合你,就没有必要再看下去了.如果你对框架开发或者说Android网络请求不是很了解,每次要使用网络时都要到百度搜索一番,那么着可能是你需要的.

设计模式6大基本原则之(二)

上一篇博客中介绍了设计模式6大基本原则的前三个,这篇博客将着重介绍剩下的三个基本原则. 里氏代换原则(Liskov Substitution Principle) 子类必须能够替换掉它的父类.也就是说子类可以扩展父类的功能,但不能改变父类原有的功能. 遵循里氏代换原则的好处? 由于子类型的可替换性才使得使用父类的模块在无需修改的情况下就可以扩展. 打个比方说,香蕉是水果的一种,香蕉具有水果的特性.假如有一天我们需要再增加苹果.橘子.苹果拥有水果 的特性,由于都是继承于水果,除了更改实例化的地方程