软件开发及过程管理——理解高内聚-低耦合

骑猪看日落 2023-09-28 08:10 117阅读 0赞

**目录**

一. 低耦合（Low Coupling）

二. 哪些是耦合

三. 高内聚-低耦合的作用

3.1 根据可能的变化设计软件

3.2 合理的职责划分

3.3 使用接口而不是继承

四. 设计模式专栏

--------------------

## **一. 低耦合（Low Coupling）** ##

> 低耦合”这个词相信大家已经耳熟能详，已经成为软件设计质量的标准之一。

>  **耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。**这里所说的元素，即可以是功能、对象（类），也可以指系统、子系统、模块。
> 
>  *  假如一个元素A去连接元素B，或者通过自己的方法可以感知B，或者当B不存在的时候就不能正常工作，那么就说元素A与元素B耦合。
>  *  耦合带来的问题是，当元素B发生变更或不存在时，都将影响元素A的正常工作，影响系统的可维护性和易变更性。
>  *  同时元素A只能工作于元素B存在的环境中，这也降低了元素A的可复用性。 正因为耦合的种种弊端，在软件设计的时候努力追求“低耦合”。

>  **低耦合要求在软件系统中，某元素不要过度依赖于其它元素。**请注意这里的“过度”二字。系统中低耦合不能过度，比如说设计一个类可以不与JDK耦合，这可能吗？除非不是设计的Java程序。再比如设计了一个类，它不与系统中的任何类发生耦合。如果有这样一个类，那么它必然是低内聚（关于内聚的问题随后讨论）。耦合与内聚常常是一个矛盾的两个方面。最佳的方案就是寻找一个合适的中间点。

--------------------

## **二. 哪些是耦合**  ##

>  *  元素B是元素A的属性，或者元素A引用了元素B的实例（这包括元素A调用的某个方法，其参数中包含元素B）；
>  *  元素A调用了元素B的方法；
>  *  元素A直接或间接成为元素B的子类；
>  *  元素A是接口B的实现。

>  *  幸运的是，目前已经有大量的框架帮助降低系统的耦合度。
>  *  比如，使用struts我们可以应用MVC模型，使页面展现与业务逻辑分离，做到了页面展现与业务逻辑的低耦合。当页面展现需要变更时，只需要修改页面，而不影响业务逻辑；同样，业务逻辑需要变更的时候，只需要修改java程序，与页面无关。
>  *  使用spring运用IoC（反向控制），降低了业务逻辑中各个类的相互依赖。假如类A因为需要功能F而调用类B，在通常的情况下类A需要引用类B，因而类A就依赖于类B了，也就是说当类B不存在的时候类A就无法使用了。使用了IoC，类A调用的仅仅是实现了功能F的接口的某个类，这个类可能是类B，也可能是另一个类C，由spring的配置文件来决定。这样，类A就不再依赖于类B了，耦合度降低，重用性提高了。
>  *  使用hibernate则是使业务逻辑与数据持久化分离，也就是与将数据存储到数据库的操作分离。在业务逻辑中只需要将数据放到值对象中，然后交给hibernate，或者从hibernate那里得到值对象。至于用Oracle、MySQL还是SQL Server，如何执行的操作，与程序员无关。

--------------------

## **三. 高内聚-低耦合的作用** ##

> 作为优秀的开发人员，仅仅依靠框架提供的降低软件耦合的方法是远远不够的。根据经验，以下一些问题应当引起注意：

### **3.1 根据可能的变化设计软件**  ###

>  *  采用职责驱动设计，设计中尽力做到“低耦合、高内聚”的一个非常重要的前提是，软件是在不断变化的。如果有变化，希望通过以上的设计，使在适应或者更改这样的变化的时候，付出更小的代价。
>  *  这里提供了一个非常重要的信息是，努力降低耦合的是那些可能发生变更的地方，因为降低耦合是有代价的，是以增加资源耗费和代码复杂度为代价的。如果系统中某些元素不太可能变更，或者降低耦合所付出的代价太大，当然就应当选择耦合。
>  *  有一次我试图将我的表现层不依赖于struts，但发现这样的尝试代价太大而失去意义了。对于软件可能变更的部分，应当努力去降低耦合，这就给提出一个要求是，在软件设计的时候可以预判日后的变化。
>  *  根据以往的经验，一个软件的业务逻辑和采用的技术框架往往是容易变化的2个方面。客户需求变更是软件设计必须考虑的问题。在RUP的开发过程中，为什么需要将分析设计的过程分为分析模型和设计模型，从分析模型到设计模型的过程实际上是系统从满足直接的客户需求到优化系统结构、适应可预见的客户需求变更的一个过程。
>  *  这种客户需求的变更不仅仅指对一个客户需求的变更，更是指软件从适应一个客户需求到适应更多客户需求的过程。另一个方面，现在技术变更之快，EJB、hibernate、spring、ajax。在这样的情况下，适应变化就是最佳的选择。

### **3.2 合理的职责划分** ###

>  *  合理的职责划分，让系统中的对象各司其职，不仅是提高内聚的要求，同时也可以有效地降低耦合。
>  *  比如评审计划BUS、评审表BUS、评审报告BUS都需要通过评审计划DAO去查询一些评审计划的数据，如果它们都去直接调用评审计划DAO，则评审计划BUS、评审表BUS、评审报告BUS三个对象都与评审计划DAO耦合，评审计划DAO一旦变更将与这三个对象都有关。
>  *  在这个实例中，实际上评审计划BUS是信息专家（关于信息专家模式将在后面讨论），评审表BUS和评审报告BUS如果需要获得评审计划的数据，应当向评审计划BUS提出需求，由评审计划BUS提供数据。经过这样的调整，系统的耦合度就降低了。

### **3.3 使用接口而不是继承**  ###

>  *  通过对耦合的分析不难发现，继承就是一种耦合。
>  *  如果子类A继承了父类B，不论是直接或间接的继承，子类A都必将依赖父类B。子类A必须使用在存在父类B的环境中，父类B不存在子类A就不能使用，这样将影响子类A的可移植性。一旦父类B发生任何变更，更改或去掉一个函数名，或者改变一个函数的参数，都将导致子类A不得不变更，甚至重写。
>  *  假如父类B的子类数十上百个，甚至贯穿这个项目各个模块，这样的变更是灾难性的。这种情况最典型的例子是现在使用hibernate和spring设计DAO对象的方式，具体的描述参见写的《如何在 struts + spring + hibernate的框架下构建低耦合高内聚的软件结构》一文。
>  *  总之，“低耦合”给软件项目带来的优点是：易于变更、易于重用

--------------------

## **四. 设计模式专栏**  ##

[https://blog.csdn.net/weixin\_53919192/category\_11798300.html?spm=1001.2014.3001.5482![icon-default.png?t=M4AD][icon-default.png_t_M4AD]https://blog.csdn.net/weixin\_53919192/category\_11798300.html?spm=1001.2014.3001.5482][https_blog.csdn.net_weixin_53919192_category_11798300.html_spm_1001.2014.3001.5482_icon-default.png_t_M4AD_icon-default.png_t_M4AD_https_blog.csdn.net_weixin_53919192_category_11798300.html_spm_1001.2014.3001.5482]

[icon-default.png_t_M4AD]: https://csdnimg.cn/release/blog_editor_html/release2.1.3/ckeditor/plugins/CsdnLink/icons/icon-default.png?t=M4AD
[https_blog.csdn.net_weixin_53919192_category_11798300.html_spm_1001.2014.3001.5482_icon-default.png_t_M4AD_icon-default.png_t_M4AD_https_blog.csdn.net_weixin_53919192_category_11798300.html_spm_1001.2014.3001.5482]: https://blog.csdn.net/weixin_53919192/category_11798300.html?spm=1001.2014.3001.5482