23.4 门面模式的注意事项

发表于 更新于 分类于 ， ， Waline： 本文字数： 2.3k 阅读时长 ≈ 2 分钟

23.4 门面模式的注意事项

23.4.1 一个子系统可以有多个门面

一般情况下，一个子系统只要有一个门面足够了，在什么情况下一个子系统有多个门面呢？以下列举了几个。

  • 门面已经庞大到不能忍受的程度

比如一个纯洁的门面对象已经超过了200行的代码，虽然都是非常简单的委托操作，也建议拆分成多个门面，否则会给以后的维护和扩展带来不必要的麻烦。那怎么拆分呢？按照功能拆分是一个非常好的原则，比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等。

  • 子系统可以提供不同访问路径

我们以门面模式的通用源代码为例。ClassA、ClassB、ClassC是一个子系统的中3个对象，现在有两个不同的高层模块来访问该子系统，模块一可以完整的访问所有业务逻辑，也就是通用代码中的Facade类，它是子系统的信任模块；而模块二属于受限访问对象，只能访问methodB方法，那该如何处理呢？在这种情况下，就需要建立两个门面以供不同的高层模块来访问，在原有的通用源码上增加一个新的门面即可，如代码清单23-10所示。

代码清单23-10 新增门面

1
2
3
4
5
6
7
8
public class Facade2 {
    //引用原有的门面
    private Facade facade = new Facade();
    //对外提供唯一的访问子系统的方法
    public void methodB(){
        this.facade.methodB();
    }
}

增加的门面非常简单，委托给了已经存在的门面对象Facade进行处理，为什么要使用委托而不再编写一个委托到子系统的方法呢？那是因为在面向对象的编程中，尽量保持相同的代码只编写一遍，避免以后到处修改相似代码的悲剧。

23.4.2 门面不参与子系统内的业务逻辑

我们这节的标题是什么意思呢？我们举一个例子来说明，还是以通用源代码为例。我们把门面上的methodC上的逻辑修改一下，它必须先调用ClassA的doSomethingA方法，然后再调用ClassC的doSomethingC方法，如代码清单23-11所示。

代码清单23-11 修改门面

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Facade {
    //被委托的对象
    private ClassA a = new ClassA();
    private ClassB b = new ClassB();
    private ClassC c = new ClassC();
    //提供给外部访问的方法
    public void methodA(){
        this.a.doSomethingA();
    }
    public void methodB(){
        this.b.doSomethingB();
    }
    public void methodC(){
        this.a.doSomethingA();
        this.c.doSomethingC();
    }
}

还是非常简单，只是在methodC方法中增加了doSomethingA()方法的调用，可以这样做吗？我相信大部分读者都说可以这样做，而且已经在实际系统开发中这样使用了，我今天告诉各位，这样设计是非常不靠谱的，为什么呢？因为你已经让门面对象参与了业务逻辑，门面对象只是提供一个访问子系统的一个路径而已，它不应该也不能参与具体的业务逻辑，否则就会产生一个倒依赖的问题：子系统必须依赖门面才能被访问，这是设计上一个严重错误，不仅违反了单一职责原则，同时也破坏了系统的封装性。

说了这么多，那对于这种情况该怎么处理呢？建立一个封装类，封装完毕后提供给门面对象。我们先建立一个封装类，如代码清单23-12所示。

代码清单23-12 封装类

1
2
3
4
5
6
7
8
9
10
public class Context {
    //委托处理
    private ClassA a = new ClassA();
    private ClassC c = new ClassC();
    //复杂的计算
    public void complexMethod(){
        this.a.doSomethingA();
        this.c.doSomethingC();
    }
}

该封装类的作用就是产生一个业务规则complexMethod，并且它的生存环境是在子系统内，仅仅依赖两个相关的对象，门面对象通过对它的访问完成一个复杂的业务逻辑，如代码清单23-13所示。

代码清单23-13 门面类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Facade {
    //被委托的对象
    private ClassA a = new ClassA();
    private ClassB b = new ClassB();
    private Context context = new Context();
    //提供给外部访问的方法
    public void methodA(){
        this.a.doSomethingA();
    }
    public void methodB(){
        this.b.doSomethingB();
    }
    public void methodC(){
        this.context.complexMethod();
    }
}

通过这样一次封装后，门面对象又不参与业务逻辑了，在门面模式中，门面角色应该是稳定，它不应该经常变化，一个系统一旦投入运行它就不应该被改变，它是一个系统对外的接口，你变来变去还怎么保证其他模块的稳定运行呢？但是，业务逻辑是会经常变化的，我们已经把它的变化封装在子系统内部，无论你如何变化，对外界的访问者来说，都还是同一个门面，同样的方法——这才是架构师最希望看到的结构。