门面模式

门面模式

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易用使用

1. UML类图

类图虽然简单，但是代表的意义可能异常复杂，Subsystem Classes是子系统所有类的简称，它可能代表一个类，也可能代表几十个对象的集合

2. 定义

门面模式注重“统一的对象”，也就是提供一个访问子系统的接口，除了这个接口不允许有任何访问子系统的行为发生

• Facade门面角色：客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类
• subsystem子系统角色：可以同时有一个或者多个子系统，每个子系统都不是一个单独的类，而是一个类的集合。子系统可能不知道门面的存在，对于子系统来说，门面仅仅是另外一个客户端而已

3. 通用代码

//子系统
public class ClassA{
  public void doSomethingA(){
    //相关的业务逻辑
  }
}
public class ClassB{
  public void doSomethingB(){
    //相关的业务逻辑
  } 
}
public class ClassC{
  public void doSomethingC(){
    //相关的业务逻辑
  } 
}

//门面对象
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.c.doSomethingC();
  }
}

4. 应用

4.1 优点

• 减少系统的相互依赖：所有的依赖都是对门面对象的依赖，与子系统无关
• 提高了灵活性：依赖减少了，灵活性提高了。不管子系统内部如何变化，只要不影响到门面对象就行。
• 提高安全性：想访问子系统的哪些业务就开通哪些逻辑，不在门面上开通方法，就访问不了

4.2 缺点

不符合开闭原则，出现小错误只能修改门面角色的代码

4.3 使用场景

• 为一个复杂的模块或子系统提供一个供外界访问的接口
• 子系统相对独立——外界对子系统的访问只要黑箱操作即可
• 预防低水平人员带来的风险扩散：比如一个低水平的计划人员参与项目开发，为降低个人代码质量对整体项目的影响风险，一般是只能在指定的子系统中开发，然后再提供门面接口进行访问操作

5. 注意事项

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

• 门面已经庞大到不能忍受的程度了
• 子系统可以提供不同访问路径

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

门面对象知识提供一个访问子系统的一个路径而已，他不应该也不能参与具体的业务逻辑，否则会产生一个倒依赖的问题：子系统必须以来门面才能被访问到