Facade 外观（结构型模式）

问题
坦克根据外部环境不一样，可以分别由引擎、控制器、车轮、车身等组合构成。
动机
当客户程序与各子系统有过多的耦合，随着客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
如何简化客户程序和子系统间的交互接口？如何将客户程序的演化和内部的子系统的变化之间依赖相互解耦？
意图
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
代码
public class Wheel
{
   public void WAction1(){ }
   public void WAction2(){ }
}
public class Engine
{
   public void EAction1(){ }
   public void EAction2(){ }
}
public class Bodywork
{
   public void BAction1(){}
}
public class Controler
{
   public void CAction1(){}
}
改进...
internal class Wheel
{
   public void WAction1(){ }
   public void WAction2(){ }
}
internal class Engine
{
   public void EAction1(){ }
   public void EAction2(){ }
}
internal class Bodywork
{
   public void BAction1(){}
}
internal class Controller
{
   public void CAction1(){}
}
public class TankFacade
{
   Wheel[] wheels = new Wheel[10];
   Engine[] engine = new Engine[4];
   Bodywork bodywork = new Bodywork();
   Controller c = new Controller();

   public void Start()
   {
      //组合 Wheel engine bodywork c等
   }
   public void Stop()
   {
   }
   public void Run()
   {
   }
}
UML

要点
从客户程序的角度来看，Facade模式不仅简化了整个组件系统接口，同时对于组件内部与外部客户程序来说，从某种程序上也达到了一种解耦的效果，内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
注意区分Facade模式、Adapter模式，Bridge模式与Decorator模式。
Facade模式注重简化接口与其实现。
Adapter模式注重转换接口。
Bridge模式注重分离接口与实现。
Decorator模式注重稳定接口的前提下为对象扩展功能。