高内聚低耦合 浅析

Posted Jenaral

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高内聚低耦合 浅析相关的知识,希望对你有一定的参考价值。

 

内聚是从功能角度来度量模块内的联系,一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系;
耦合是软件结构中各模块之间相互连接的一种度量,耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
 
 
内聚就是一个模块内各个元素彼此结合的紧密程度,高内聚就是一个模块内各个元素彼此结合的紧密程度高。
 
所谓高内聚是指一个软件模块是由相关性很强的代码组成,只负责一项任务,也就是常说的单一责任原则。
 
耦合:一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差,模块间耦合的高低取决于模块间接口的复杂性,调用的方式以及传递的信息。)
 
对于低耦合,粗浅的理解是:一个完整的系统,模块与模块之间,尽可能的使其独立存在。也就是说,让每个模块,尽可能的独立完成某个特定的子功能。模块与模块之间的接口,尽量的少而简单。如果某两个模块间的关系比较复杂的话,最好首先考虑进一步的模块划分。这样有利于修改和组合。[1]

 

简单概括:耦合就是程序中的一部分跟其他部分之间的关系。解耦合就是把必要的耦合理顺,同时尽量减少不必要的耦合(这一句其实就是高内聚低耦合的通俗解释)。

如何看待耦合取决于你是从什么视角和层次看待一个程序。如果你正在关注的是一个函数或一个类的内部实现,这个粒度就很细。这个时候你关注的可能是如何把函数/类写的漂亮,让它在功能正确的同时又容易理解。你可以通过改善代码的排版、优化算法、将重复的操作封装为一个新的函数、给变量或函数取更有意义的名字等方法来改善它。

这些方法可以说都跟“高内聚低耦合”有关系。改善代码排版:让代码更有代码的样子,让人更容易看清每句代码的作用和意图。合适的名字:如果你给变量取个名字叫variable,从语意上讲它可以存储任意的值,它的模棱两可的名字让人难以分清它和其他代码的关系(与其他部分有了不必要的耦合),这就会让阅读代码的人茫然不知所措。让变量名字更有意义实际上是高内聚的一种体现,即这个变量你是想让它干嘛的,别人一眼就能看出来。提取函数就更不用说了。

如果你正在设计一个模块,你关注的可能是模块中的类和对象,也就是如何让模块中的类和对象之间的关系更加简单和清楚。四人帮的《设计模式》这本书主要就是讲这个的,其中的每一个模式都是想办法降低类和对象之间的耦合性。

那如果你正在设计一个系统呢,你可能就不关心其中的类了(至少一开始不应该关心),你应该将精力集中到这个系统可以分成几个模块、各个模块怎样组合到一起(术语称为“协作”)构成整个系统等问题上。如果你设计的模块还要去关注其他模块的实现细节,那你的系统就太失败了。

所以,不管你的角度如何,关注的层次高低,降低复杂度都是必要的。这就是耦合和解耦合的核心理念。

据说任何比喻都是蹩脚的,但我还是想举一个现实中极其高效与低耦合的例子,那就是军队。一个国家的军队少则数万人,多则数百万人,这么庞大的一个系统,它的效率却是惊人的高。为什么?简单来说这要归功于它的几个行事原则:

纪律严明,令行禁止
不会出现上级发出命令后找不到人执行,或找到人却不愿意做的尴尬情况(很内聚有木有)

命令不跨级
除非特殊情况,否则命令都是通过直接上级传达的,司令很少会单独找小兵做事(每一级在上一级看来都高内聚的,同时连长、班长、团长这些头头充当了本级的一个接口,上一级仅通过接口来向下级发命令)
有人说,如果司令直接找小兵给他做事不是比一级一级传达效率更高吗?no!为什么?原因有几条(注意看,都能跟我们编程时的道理联系上,所以说万物都是想通的)

  1. 司令发出的命令通常都是很大的任务,往往要跨越很多部队甚至兵种,如果让司令一个一个通知不是要累死?(高层抽象不应该直接与底层实现耦合)

  2. 如果允许任意的跨级下达命令,那就很有可能导致多个上级同时给一个士兵下达不同的命令,那这个士兵不是要累死?(导致系统状态不一致、或分布式系统的忙闲不一等情况)

  3. 士兵与直接上级之间的沟通通常是无障碍的,但跨级就难说了。哪个士兵擅长做什么事只有他的直接上级最清楚,跨级下达命令时可能会导致任务完成效率下降、甚至任务无法完成的后果(高层抽象往往难以驾驭底层细节,进而导致使用不当甚至误用)

职能划分明确
部队会按地域、时域、部门、兵种等来划分整个部队的职责,这样一层一层、一块一块地把整个部队分成职责明确的一个个小部分,各个部分相对独立又是一个有机整体,因此想不高效都很难啊。

 

 

某些模块必然要关联起来才能工作,这是由业务逻辑决定的,不能否认。所以解耦并不是字面意义上的把关联拆掉,而是把模块之间的关联放松到必要的程度。一些建议:

  • 模块只对外暴露最小限度的接口,形成最低的依赖关系。
  • 只要对外接口不变,模块内部的修改,就不得影响其他模块;
  • 删除一个模块,应当只影响有依赖关系的其他模块,而不应该影响其他无关部分;

软件工程有一条铁律“高内聚、低耦合”就是这个道理:必要的耦合不可否认,没有耦合程序就做不成事;但是不必要的紧耦合,就会让程序“牵一发而动全身”,最终让程序员的编写和维护都无从下手。

人类同一时间只能专注于一小部分的内容。“高内聚、低耦合”就是为了满足人类的这个特点——小尺度上只专注一个模块,局部的编码工作才能够进行。大尺度上把具体代码转化为一些抽象的“模块”和“依赖关系”,才能够抓大放小,把握住程序的脉络,拼合出一个完整的产品。

想象一下“社会大分工”这个模型——每一个小单位只专注自己的业务部分,与其他单位只存在业务外包的关联,以及物质、信息的交互。事实已经证明:这样的模型比以前大国企“大包大揽”自办各种职能部门的效率,有量级程度的提高。这就是“高内聚、低耦合”在现实世界中的体现。

程序就是人类创造的第二世界,程序的逻辑无非是世界运行规律的抽象。跳出程序看程序,就会发现不一样的观点和角度。

以上是关于高内聚低耦合 浅析的主要内容,如果未能解决你的问题,请参考以下文章

高内聚低耦合

浅谈面向对象开发原则:高内聚,低耦合

高内聚低耦合

高内聚低耦合

软件设计之——“高内聚低耦合”

Office之什么是高内聚低耦合