设计模式学习笔记（十一）Facade外观（结构型模式）

由系统复杂度谈起

假设我们要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为。其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。

public class Wheel
{
 public void WAction1(){...}
 public void WAction2(){...}
}

public class Engine
{
 public EAction1(){...}
 public EAction2(){...}
}

...

动机（Motivation）

上述情况下组件的客户（调用坦克系统中各组件的客户程序）和组件中各种复杂的子系统有过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合会面临很多变化的挑战。

如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的深化和内部子系统变化之间的依赖相互解耦？

意图（Intent）

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
                      ——《设计模式》GoF

代码：

internal class Wheel
{
 public void WAction1(){...}
 public void WAction2(){...}
}

internal class Engine
{
 public EAction1(){...}
 public EAction2(){...}
}
internal class Controller
{
 public void CAction1(){...}
 public void CAction2(){...}
}

//外部只能使用这个TankFacade类。一个意义是简单，一个意义是解耦

public class TankFacade
{
 Wheel[] wheels = new Wheel[4];
 Engine[] engines = new Engine[4];
 Controler controler = new controler();
 
 
 
 public void Start()
 {
  //方法调用内联的对象…… 
 }
 public void Stop()
 {
 
 }
 public void Shot()
 {
 
 }
 
}

依赖“接口”所指的“接口”是指广义的、类与外界交互的部分，不单单是指C#中的Interface关键字指定的接口。

 

Facade模式的几个要点

1）从客户程序的角度来看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种解耦的效果——内部子系统的任何变化不会影响到Facade接口的变化。
2）Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
3）注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口，Adapter模式注重转换接口，Bridge模式注重分享接口（抽象）与其实现，Decorator模式注重稳定接口的前提下为对象扩展功能。（Adapter模式和Facade模式从代码上看似乎很难区分，但从接口意义上讲，Adapter模式转换前后的接口抽象意义不变，但Facade转换前后的抽象意义一般是不同的。例如坦克与其组件的抽象意义是不同的）