C#面向对象设计模式纵横谈 学习笔记11 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 void BAction2()
    ...{ 
    }
}

public   class  Controller
... {
    public void CAction1()
    ...{ 
    }

    public void CAction2()
    ...{ 
    }
}

如果我们在客户程序中直接使用这几个类，那么就造成了这几个类和客户程序之间的紧耦合，那么我们Facade的动机就是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

Facade模式的意图：

为子系统中的一组接口提供一个一致的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

我们将上面四个类进行重组一下，由一个类来提供接口，这个类的方法就是实现四个类方法的接口

public   class  TankFacade
... {
    Wheel[] wheels = new Wheel[4];
    Engine[] engines = new Engine[4];
    Bodywork bodywork = new Bodywork();
    Controller controller = new Controller();

    public void Start()
    ...{ 
    }

    public void Stop()
    ...{ 
    }

    public void Run()
    ...{ 
    }

    public void Shot()
    ...{ 
    }
}

我们将这四个类封装到TankFacade类里，通过TankFacade类的方法来调用这四个类的方法，当四个类发生变化，我们客户端程序仍然调用的是TankFacade类的方法，不需要重新修改客户端程序的代码。

注意：我们的目标并不是把所有的类都放在Facade类里，通过Facade类来调用其他类的代码。这样理解Facade类是错误的，我们是将有关联的，并且相互作用的类放在Facade类里。

Facade模式的几个要点：

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