耦合与内聚

代码耦合：一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。) 

 

软件工程规定写代码的原则是“高内聚，低耦合”。内聚是代码块间的独立性，耦合是各个代码块间的联系。

 

对于低耦合，粗浅的理解是：一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。 

 

代码内聚就是一个模块内各个元素彼此结合的紧密程度，高内聚就是一个模块内各个元素彼此结合的紧密程度高。所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。

 

高内聚，低耦合的系统有什么好处呢？事实上，短期来看，并没有很明显的好处，甚至短期内会影响系统的开发进度，因为高内聚，低耦合的系统对开发设计人员提出了更高的要求。长期来看，低耦合的模块便于进行单元测试，且便于维护。

通俗地讲一讲

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

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

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

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

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

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

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

纪律严明，令行禁止

不会出现上级发出命令后找不到人执行，或找到人却不愿意做的尴尬情况（很内聚有木有）

命令不跨级

除非特殊情况，否则命令都是通过直接上级传达的，司令很少会单独找小兵做事（每一级在上一级看来都高内聚的，同时连长、班长、团长这些头头充当了本级的一个接口，上一级仅通过接口来向下级发命令）

有人说，如果司令直接找小兵给他做事不是比一级一级传达效率更高吗？no！为什么？原因有几条（注意看，都能跟我们编程时的道理联系上，所以说万物都是想通的）

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

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

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

职能划分明确

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