对高内聚,低耦合的理解

简介: 内聚:一个模块内各个元素彼此结合的紧密程度 耦合:一个软件结构内不同模块之间互连程度的度量     (一)这是判断设计好坏的标准,主要是面向OO的设计,主要是看类的内聚性是否高,偶合度是否低。

内聚:一个模块内各个元素彼此结合的紧密程度

耦合:一个软件结构内不同模块之间互连程度的度量

 

  (一)这是判断设计好坏的标准,主要是面向OO的设计,主要是看类的内聚性是否高,偶合度是否低。
   

    高内聚:类与类之间的关系而定。高,意思是他们之间的关系要简单,明了,不要有很强的关系,不然,运行起来就会出问题。一个类的运行影响到其他的类。

    低耦合:类内部的方法而言。把程序的功能尽量分散,别在一个类里只写一个或很好的方法,因为那样会给你的调试等带来很多问题。出了错你都不知道在什么地方。

    (二)系统的各个模块尽可能具有较大的独立性,换句话说,希望这样设计软件结构,使得每个模块完成一个相对独立的特定子功能,并且和其他模块之间的关系很简单,以便能方便地把不同场合下写成的程序模块组合成软件系统。衡量模块独立性的定性标准是内聚(一个模块内各个元素彼此结合的紧密程度)和耦合(一个软件结构内不同模块之间互连程度的度量)。高内聚、低耦合的模块是设计时追求的目标。

(三)“模块独立性指每个模块只完成系统要求的独立子功能,并且与其他模块的联系最少且接口简单,两个定性的度量标准――耦合性和内聚性。
    

耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。
    
无直接耦合;数据耦合;标记耦合;控制耦合;公共耦合;
    
内容耦合(低――高); 1无直接耦合;2数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递;3标记耦合指两个模块之间传递的是数据结构,如高级语言中的数组名、记录名、文件名等这些名字即标记,其实传递的是这个数据结构的地址; 4控制耦合指一个模块调用另一个模块时,传递的是控制变量(如开关、标志等),被调模块通过该控制变量的值有选择地执行块内某一功能。; 5公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。6内容耦合:这是最高程度的耦合,也是最差的耦合。

当一个模块直接使用另一个模块的内部数据,或通过非正常入口而转入另一个模块内部。内聚性又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。
    
偶然内聚;逻辑内聚;时间内聚;通信内聚;顺序内聚;
    
功能内聚(低――高)1偶然内聚指一个模块内的各处理元素之间没有任何联系。 2逻辑内聚指模块内执行几个逻辑上相似的功能,通过参数确定该模块完成哪一个功能。3时间内聚:把需要同时执行的动作组合在一起形成的模块为时间内聚模块。4通信内聚指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据。5顺序内聚指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素输出就是下一功能元素的输入。6功能内聚:这是最强的内聚,指模块内所有元素共同完成一个功能,缺一不可。与其他模块的耦合是最弱的。耦合性与内聚性是模块独立性的两个定性标准,将软件系统划分模块时,尽量做到高内聚低耦合,提高模块的独立性,为设计高质量的软件结构奠定基础。

有个例子很容易明白:一个程序有50个函数,这个程序执行得非常好;然而一旦你修改其中一个函数,其他49个函数都需要做修改,这就是高耦合的后果。
一旦你理解了它,你编写概要设计的时候设计类或者模块自然会考虑到“高内聚,低耦合”。


目录
相关文章
|
12月前
|
JSON 数据库 数据格式
|
3月前
软件复杂度问题之什么是高内聚低耦合设计,实现一个高内聚低耦合的接口该如何解决
软件复杂度问题之什么是高内聚低耦合设计,实现一个高内聚低耦合的接口该如何解决
迪米特法则:降低耦合,提升代码质量与可维护性
迪米特法则是一项强大的设计原则,可以帮助我们构建松散耦合的软件系统,提升代码的质量、可维护性和可扩展性。通过减少模块之间的依赖关系,我们可以更轻松地进行修改、重构和扩展。
93 1
迪米特法则:降低耦合,提升代码质量与可维护性
|
5月前
模块功能高内聚低耦合
模块功能高内聚低耦合
47 1
|
设计模式 关系型数据库 数据安全/隐私保护
软件架构设计原则之单一职责原则
单一职责(Simple Responsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责,一旦发生需求变更,修改其中一个职责的逻辑代码,有可能导致另一个职责的功能发生故障。这样一来,这个类就存在两个导致类变更的原因。如何解决这个问题呢?将两个职责用两个类来实现,进行解耦。后期需求变更维护互不影响。这样的设计,可以降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险。总体来说,就是一个类、接口或方法只负责一项职责。
103 0
软件架构设计原则之单一职责原则
|
5月前
软件设计原则:耦合与内聚
软件设计原则:耦合与内聚
108 0
|
11月前
|
设计模式 网络协议 测试技术
你的代码是否按照高内聚、低耦合的原则来设计的?
你的代码是否按照高内聚、低耦合的原则来设计的?
|
设计模式 关系型数据库
软件架构设计原则之迪米特法则
迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP),尽量降低类与类之间的耦合度。迪米特原则主要强调:只和朋友交流,不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称为成员朋友类,而出现在方法体内部的类不属于朋友类。
99 1
|
存储 安全 程序员
软件工程的耦合和内聚
软件工程的耦合和内聚
244 0