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

高内聚、低耦合是软件设计中非常关键的概念,但解释起来并不那么容易。
我的解释,可以概括为两个基本原则:层次一致的抽象,以及相互独立的封装。

层次一致的抽象

在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
    }

相互独立的封装

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

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

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

Comments
Write a Comment