关于“高内聚,低耦合”的笔记
2017-05-13 00:00
190 查看
摘要: 耦合这个词有点抽象,网上搜了一下,有个回答是很值得记录下来,感谢两位大牛的回答
不要一棒子把“耦合”削死。耦合是一个宽泛的概念。两个程序模块有关联就叫做耦合。
某些模块必然要关联起来才能工作,这是由业务逻辑决定的,不能否认。所以解耦并不是字面意义上的把关联拆掉,而是把模块之间的关联放松到必要的程度。一些建议:
模块只对外暴露最小限度的接口,形成最低的依赖关系。
只要对外接口不变,模块内部的修改,就不得影响其他模块;
删除一个模块,应当只影响有依赖关系的其他模块,而不应该影响其他无关部分;
软件工程有一条铁律“高内聚、低耦合”就是这个道理:必要的耦合不可否认,没有耦合程序就做不成事;但是不必要的紧耦合,就会让程序“牵一发而动全身”,最终让程序员的编写和维护都无从下手。
人类同一时间只能专注于一小部分的内容。“高内聚、低耦合”就是为了满足人类的这个特点——小尺度上只专注一个模块,局部的编码工作才能够进行。大尺度上把具体代码转化为一些抽象的“模块”和“依赖关系”,才能够抓大放小,把握住程序的脉络,拼合出一个完整的产品。
想象一下“社会大分工”这个模型——每一个小单位只专注自己的业务部分,与其他单位只存在业务外包的关联,以及物质、信息的交互。事实已经证明:这样的模型比以前大国企“大包大揽”自办各种职能部门的效率,有量级程度的提高。这就是“高内聚、低耦合”在现实世界中的体现。
程序就是人类创造的第二世界,程序的逻辑无非是世界运行规律的抽象。跳出程序看程序,就会发现不一样的观点和角度。
原文链接:https://segmentfault.com/q/1010000002421856/a-1020000002424624
不要一棒子把“耦合”削死。耦合是一个宽泛的概念。两个程序模块有关联就叫做耦合。
某些模块必然要关联起来才能工作,这是由业务逻辑决定的,不能否认。所以解耦并不是字面意义上的把关联拆掉,而是把模块之间的关联放松到必要的程度。一些建议:
模块只对外暴露最小限度的接口,形成最低的依赖关系。
只要对外接口不变,模块内部的修改,就不得影响其他模块;
删除一个模块,应当只影响有依赖关系的其他模块,而不应该影响其他无关部分;
软件工程有一条铁律“高内聚、低耦合”就是这个道理:必要的耦合不可否认,没有耦合程序就做不成事;但是不必要的紧耦合,就会让程序“牵一发而动全身”,最终让程序员的编写和维护都无从下手。
人类同一时间只能专注于一小部分的内容。“高内聚、低耦合”就是为了满足人类的这个特点——小尺度上只专注一个模块,局部的编码工作才能够进行。大尺度上把具体代码转化为一些抽象的“模块”和“依赖关系”,才能够抓大放小,把握住程序的脉络,拼合出一个完整的产品。
想象一下“社会大分工”这个模型——每一个小单位只专注自己的业务部分,与其他单位只存在业务外包的关联,以及物质、信息的交互。事实已经证明:这样的模型比以前大国企“大包大揽”自办各种职能部门的效率,有量级程度的提高。这就是“高内聚、低耦合”在现实世界中的体现。
程序就是人类创造的第二世界,程序的逻辑无非是世界运行规律的抽象。跳出程序看程序,就会发现不一样的观点和角度。
原文链接:https://segmentfault.com/q/1010000002421856/a-1020000002424624
相关文章推荐
- Java程序设计关于低耦合与高内聚理念
- 关于 iOS 开发中,代码如何做到高内聚,低耦合,MVC 三层分离的小感悟
- 关于耦合内聚的概念
- 关于“内聚和耦合”
- Java关于低耦合与高内聚理念
- 关于模块化设计的内聚和耦合的个人理解
- 关于JAVA 封装性 以及高内聚,低耦合的理解
- 关于软件工程中的耦合和内聚
- 内聚和耦合(学习笔记与思考)
- 关于.NET Remoting乱七八糟的笔记 1
- 摘抄笔记 关于学习
- 软件测试学习笔记--(关于排错)
- 关于函数重载解析笔记001
- 学习笔记:关于科学方法在社会科学中的局限性
- CMS-一篇关于分类资源管理系统设计思路的笔记
- 关于函数重载笔记002
- 关于Lempel-Ziv压缩算法的笔记
- 关于WBS的笔记体会
- 关于在FPGA上实现AES算法的笔记
- C++对象模型之一 关于对象笔记