文章目录
- 一、高内聚低耦合
- 1.1 程序架构设计
- 1.2 低耦合
- 1.2.1 耦合概念
- 1.2.2 如何降低耦合
- 1.3 高内聚
- 1.4 不能完全低耦合
一、高内聚低耦合
1.1 程序架构设计
高内聚低耦合，是软件工程中的概念，是判断软件设计好坏的标准，主要用于程序的面向对象的设计，主要看类的内聚性是否高，耦合度是否低。目的是使程序模块的可重用性、移植性大大增强。通常程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。
- 内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事，它描述的是模块内的功能联系；
- 耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
Tips：元素可以是方法、对象（类），也可以指系统、子系统、模块、服务等。
- 1）高内聚低耦合是软件架构的一种概念、思想；
- 2）内聚与耦合想相对的，内聚程度越高那么耦合度就低，内聚程度越低往往耦合度就高；
- 3）我们在软件设计时，应该尽量做到高内聚、低耦合；
1.2 低耦合
1.2.1 耦合概念
耦合，简单的来说就是元素（类）与元素（类）之间的关系；我们在设计程序时应该降低元素与元素之间的直接关系；降低元素与元素之间的耦合性；
假如一个元素A去调用元素B，或者通过自己的方法可以感知B，当B不存在的时候就不能正常工作，那么就说元素A与元素B耦合。耦合带来的问题是，当元素B发生变更或不存在时，都将影响元素A的正常工作，影响系统的可维护性和易变更性。同时元素A只能工作于元素B存在的环境中，这也降低了元素A的可复用性。
1.2.2 如何降低耦合
简单的来说就是元素A不能过度依赖元素B；
- 1）定制合理的职责划分，让系统中的对象各司其职，不仅是提高内聚的要求，同时也可以有效地降低耦合；
- 2）使用接口而不是继承：我们不难发现。继承就是一种耦合，假如子类A继承了父类B，父类B修改了任何功能将直接影响到子类，而接口则是将功能延迟到了子类中来实现；
1.3 高内聚
架构设计时的内聚高低是指，设计某个模块时，模块内部的一系列相关功能的相关程度的高低。相关程度越高，我们称之为高内聚，反之低内聚；内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。
很明显，程序的内聚性越高，代表功能的相关性也就越高，从一定程度上来说，这个功能就应该属性这个元素；因此耦合性就降低了；
程序讲究的是低耦合，高内聚。就是同一个模块内的各个元素之间要高度紧密，但是各个模块之间的相互依存度却要不那么紧密。
1.4 不能完全低耦合
高内聚低耦合只是一个度的问题，我们并不能做到完全的高内聚低耦合；有时候太过严格反而会适得其反
我们可以举几个代码上的例子：
1）我们的UserServlet中，出现了UserService和DeptService，从一定程度上来讲，Dept的业务应该是不属于我User管辖的
如果要严格按照"高内聚，低耦合"的要求来，那么只能把DeptService的业务写在DeptServlet中，这样做虽然是降低了UserServlet与DeptService的联系，提高了UserServlet的内聚，但很显然，UserService变得非常臃肿（高耦合、低内聚）
2）我们再"严格"一点，ArticleServlet的功能应该由ArticleServlet来提供，而不需要借助其他类，否则ArticleServlet就与ArticleService产生耦合关系：
那么为了进一步降低耦合性，只能把ArticleService的代码编写到ArticleServlet中，那么很显然，ArticleSerlvet的内聚性就非常低了，因为很多不是属于ArticleServlet的代码也编写到ArticleServlet中了；
因此"高内聚低耦合只是一个度的问题"，但是实际的设计开发过程中，总会发生这样那样的问题与情况，真正做到高内聚、低耦合是很难的，很多时候未必一定要这样， 更多的时候“最适合”的才是最好的， 不过，理解思想，审时度势地使用， 融会贯通，灵活运用，才是设计的王道。
比如说我们设计一个类可以不与JDK耦合，这可能吗？除非你不是设计的Java程序。再比如我设计了一个类，它不与我的系统中的任何类发生耦合。如果有这样一个类，那么它必然是低内聚，而且是非常低的内聚（因为所有的功能都在一个类的，耦合非常高，内聚非常低）。耦合与内聚常常是一个矛盾的两个方面。最佳的方案就是寻找一个合适的中间点。
- 高内聚：一个的元素中的功能应该都是相关程度非常高的，不要提供与本身无关的功能
- 低耦合：尽量与其他元素不要产生关系；