重要的JAVA开发思想之——高内聚低耦合

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

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

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

程序就是人类创造的第二世界，程序的逻辑无非是世界运行规律的抽象。

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

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

纪律严明，令行禁止

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

命令不跨级

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

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

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

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

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

职能划分明确

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

另一个例子：

如果你有做电学实验的经历，这个概念就太好解释了。两块电路板之间的接线就是耦合，接线越多，电路越复杂，以至于连电路设计者自己都被绕蒙了。一旦发现错误，头绪太多很难理清，即所谓维护性变差。想往电路里接入更多板子难度也会加大，即所谓扩展性变差。就算勉强把电路跑通了，同样的接线方法也很难在其他电路中复制，即所谓复用性差。这就是高耦合的坏处。

尽管耦合有种种坏处，但是又不可避免，因为没有耦合电路就跑不起来。怎么办呢?有个解决方法就是把耦合性尽可能藏起来。一块芯片内部电路极其复杂，但是对于外界来说它的内部电路无关紧要。这种把耦合性尽可能藏起来的做法就叫解耦，对内部而言就是高内聚，对外界而言就是低耦合。逻辑效果上就是进行了一层抽象。使得外部可以把芯片视作一个整体，只需要关心它有哪些接口，而这些接口，实际上也是耦合，只不过已经是最小化的耦合了。

有了这样一层抽象之后，工程师就可以不去关心具体的电路实现，玩纯粹的逻辑。这就催生了编程语言。所以编程语言本身已经是在底层硬件解耦的基础上所做的高度抽象了。而软件工程中提到的狭义上的解耦，是指在编程语言(确切的说是用编程语言编制的程序)基础上进行更高层次的解耦，从而获得更高层次的抽象。这样一层层解耦抽象上去，包括操作系统和应用软件在内的整个软件大厦就建造出来了。但是追根溯源，耦合与解耦概念的起源还是在硬件层次上，而软件本身其实就是经过解耦的硬件基础上的抽象。

另外解耦是一个过程，在软件工程中体现为以高内聚低耦合为原则对代码进行重构。