高内聚，低耦合

高内聚：

  内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该元素就具有高内聚性，反之则为低内聚性。

  其实结合OOP的思想，高内聚应该是更加趋向于接口化，工厂模式可以很容易体现这种思想。即方法调用，只要通过相应的接口，即可得到不同的实现。无需修改接口对应类的内容及实现方式。

举例理解：

  这就好像，如果我是一个项目经理，我的职责是监控和协调我的项目各个阶段的工作。当我的项目进入需求分析阶段，我会请求需求分析员来完成；当我的项目 进入开发阶段，我会请求软件开发人员来完成；当我的项目需要测试的时候，我会请求测试人员。如果我参与了开发，我就不是一个高内聚的元素，因为 开发不是我的职责。简单说，各司其职

那么高内聚的好处是什么呢？

1.可读性

如果一段程序条理非常清晰，每个类通过名称或说明都能清楚明白它的意义，类的每个属性、函数也都是易于理解 的它所应当完成的任务和行为，这段程序的可读性必然提高。

2.复用性

在软件开发中，最低等级的复用是代码拷贝，然后是函数的复用、对象的复用、组件 的复用。代码复用也使我们的代码在复用的过程中不断精化、不断健壮、提高代码质量。

3.可维护性和易变更性

高内聚的软件，每个系统、模块、类的任务都高度相关，就使每一次的变更涉及的范围缩小到最小。比如评审表发生了变更，只会 与评审表对象有关，我们不会去更改其它的对象。如果我们能做到这一点，我们的系统当然是可维护性好、易变更性好的系统。

低耦合 :

         低耦合是用来度量模块与模块直接的依赖关系。模块之间不要过度依赖其他模块 

举例：

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

比如现在的mvc模型，就将页面和业务逻辑分离，如果需要改页面，那么业务逻辑不会有影响，如果需要修改业务逻辑，那么页面不会受到影响。

但是：

1. 低耦合是有一定代价的，因为低耦合是以增加资源消耗和代码复杂度来实现的，所以我们努力降低耦合，只是在那些可能变更的地方。

2. 高内聚，低耦合本身就有一定的矛盾，我们只有把握住度，选择恰当的方法 

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