层次一致的抽象

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

image

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

    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
    }

相互独立的封装

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

image

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

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