两个原则解释高内聚和低耦合

高内聚、低耦合是软件设计中很是关键的概念，但解释起来并不那么容易。
个人解释，能够归纳为两个基本原则：层次一致的抽象，以及相互独立的封装。

层次一致的抽象

在Web工程中，咱们很是熟悉的是三层架构：展现层、业务层和持久层。
层次一致和不一致的抽象就像这样：

若是业务层包含了持久层的代码，或者持久的的代码放到了展现层，这即是破坏了代码的抽象层次。
一样的：
若是工具类包含了业务方法成员或字段，这就破坏了类的抽象；
若是查询方法包含了排序算法，这就破坏了方法的抽象；
...
抽象层次也能够更加的往上：
若是在业务服务里，部署了分布式缓存服务，这就破坏了服务的抽象。
若是负载集群里包含的业务集群，这就破坏了集群的抽象。
也就是，系统应该体现出良好的层次性，尽量不出现跨层次调用，并保证同一层的元素是同一抽象层次。
这里举个方法的抽象层次的例子：

public Foo(){
        initServer();
    }
    private void initServer() {
        // do something
         initClient();
    }
    private void initClient() {
        // do something
    }

其中，initServer，initClient两方法从逻辑上讲应该是同一抽象层次，因此让initServer去执行initClient是不恰当的。
恰当的抽象以下，让更上层的构造函数执行initClient。

public Foo(){
        initServer();
        initClient();
    }
    private void initServer() {
        // do something
      }
    private void initClient() {
        // do something
    }

相互独立的封装

那么如何更好的实现抽象，以保证高内聚、低耦合呢？
第二个原则是相互独立的封装。
相互独立的封装和相互不独立的封装就像这样：

相互独立，更通俗的点讲就是一个类、一个方法只作一件事情。
它有两层含义。
首先是与外部的相互独立，好比，类与类之间要逻辑独立，仅经过少许接口实现交互。若是类自己的字段使用得很少，反而过多的使用了另外一个类的字段，那么就要考虑是否是要从新封装两个类。
其次是内部的独立性，类应该是一个对象的抽象，猫类不能带上狗尾巴；一个方法最好只包含一份职责，不要即控制流程，又处理业务。

层次一致的抽象，相互独立的封装，作到这两点，让程序在垂直方向上井井有条，在水平方向上相互独立，这就是理想中高内聚、低耦合的软件架构。

做者

• 做者：初开
• 个人开发者之道：http://dev.chukai.pro