如何理解低耦合AND高内聚?[转]

 1、高内聚

        首先我们来看看内聚的含义：软件含义上的内聚其实是从化学中的分子的内聚演变过来的，化学中的分子间的作用力,作用力强则表现为内聚程度高。在软件中内聚程度的高低，标识着软件设计的好坏。

        我们在进行架构设计时的内聚高低是指，设计某个模块或者关注点时，模块或关注点内部的一系列相关功能的相关程度的高低。

        例如：下单模块：

         

一般情况下，下单模块都会有如下的信息，订单的信息，产品的信息及谁下的单(买家信息)。这是基本的，那么我们设计的时候就要把相关的功能内聚到一起。当然这是从大功能(下单管理)上来说，当然这些模块还可以再细化分成产品、订单、会员等子模块。

        例如我们在设计数据库操作辅助类提供的方法有：

         

通过这样的方式，那么这个组件只负责数据库操作。这样带来的好处也是显而易见的。高内聚提供了更好的可维护性和可复用性。而低内聚的模块则表名模块直接的依赖程度高，那么一旦修改了该模块依赖的对象则无法使用该模块，必须也进行相应的修改才可以继续使用。

        低内聚的模块设计的坏处有：首先模块的功能不单一，模块的职责不明确，比较松散，更有甚者是完成不相关的功能。这样的设计往往是不可取的。可以通过重构来完善。

        下面我们来说下高内聚的简单解释：什么样的模块算是高内聚，并且能够在系统中很好的使用。

        

        那么我们在设计的过程中如何去完成高内聚呢？

        

        以上基本上讲述了高内聚的好处，并且阐述了如何实现高内聚的步骤和原则。下面我们来说说可能高内聚带来的坏处。

        高内聚有时候也不是说所有的情况都采用这样的原则，当然高内聚还是要适度的，下面来举例说明：例如内聚性要求强的话就像windows32中系统提供的api，里面的函数太多了，都放在一个dll中，那么每个函数完成一个功能。这样强大的功能，会比较复杂，所以并不是完全的高内聚越高越好，还是要看实际的需要。当然维护起来也不是特别的方便。

      2、低耦合

         首先我们来看看低耦合的定义：低耦合是用来度量模块与模块直接的依赖关系。耦合当然也可以这样简单的理解，我想懂电脑的应该都知道，cpu与主板之间的关系，cpu如果是特殊的cpu必须使用特殊的主板来支持，那么如果说这个cpu不唯一依赖唯一主板，那么就认为这个cpu与主板的关系是低耦合的关系。

         下面我们来举例说明低耦合的设计与高耦合的设计：

           

这是一个简单的低耦合的设计，电器与插座之间是低耦合的关系，就算我替换了不同的插座，电器依然可以正常的工作。因此简单的描述如下，就是a模块与b模块存在依赖关系，那么当b发生改变时，a模块仍然可以正常工作，那么就认为a与b是低耦合的。

         

         1、笔记本接音响可以正常的使用。

                 2、笔记本接专配耳机正常的使用。       

         对应一般的音响来说，笔记本是通用的，音响和笔记本直接的关系是低耦合的，但是笔记本和耳机却是高耦合的，只有专配的耳机才能和笔记本互联使用，而不

是通用的，所以说笔记本和专配耳机存在着较强的依赖关系。当然最简单的方式就是笔记本提供统一的耳机接口，可以满足一般性的需求。

         下面我们将来分析如何构建低耦合的设计。

         

        总结

          上面我们已经讲解了低耦合和高内聚的二个原则，通过这2个原则我们知道，满足这2个原则是衡量一个架构设计好坏的一个参考标准。下面我们将来讲解通过功能分离的方式来满足上面的2个原则。

 

       1、如何按功能进行模块化的分离。

       我们在将一个系统进行功能划分时，首先我们先把功能职责划分成独立的单元。

       例如现在有个b2c系统，那么我们按照b2c的需求，如下分析：

        

我们这里简单的分析下b2c应该具有的功能模块，当然这些模块的划分中，有些模块还可以继续的分离，当然我这里只是实例分析出来。

      2、对分离出来的模块化进行抽象，例如我们以支付为例。

           

这里通过支付接口向外提供服务。那么外界模块不关心支付系统模块的变化，只需要调用接口即可，如果具体的支付方式，比如支付宝的方式发生改变，在调用支付服务的模块中也不需要做任何的修改就可以正常的提供服务。显然这样的方式是不错的实现方式。

 

       通常情况下我们在系统分离式只是以接口的方式提供服务，供其他的模块进行使用。在模块内部有大量的信息是不要向外部暴露的，所以模块在设计时访问域的定义就要划分好，防止因为访问域的定义而对模块的信息造成破坏。

       下面我们来看下功能分离在不同的设计理念下都是什么样的表现：

       

       上面只是实体性的分析了功能分离的好处及应用的广度，当然我们在后续会结合实例来讲解如何来实现这样的软件设计模式。当然这只是软件的架构设计，那么如

果细化到具体的实现呢？我们如何去设计每个功能点呢？这就是下章我们要讲解的内容了，那么本文先列出二种常见的方式。

        

        下篇我们将针对设计原则中的实现方式，进行详细的剖析与具体实现进行举例讲解，希望大家多提意见。