外观模式 - 结构型模式

个人理解：    

模式类型：
    Facade 外观模式 - 结构型模式，也称之为门面模式。

意图(Motivate):

    为子系统中的一组接口提供一个一致的接口， Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
    Provide a unified interface to a set of interface in a subsystem.Facade defines a higher-lever interface that make the subsystem easier to use.

概述:
    在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？
    外观模式中，一个子系统的外部与其内部的通信通过一个统一的外观类进行，外观类将客户类与子系统的内部复杂性分隔开，使得客户类只需要与外观角色打交道，而不需要与子系统内部的很多对象打交道。
    引入一个抽象外观类，客户端针对抽象外观类编程，而在运行时再确定具体外观类
    Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

    Wrap a complicated subsystem with a simpler interface.

角色：
    (1) Facade（外观角色）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。
    (2) SubSystem（子系统角色）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

模式的应用场景：
    1 ．为一个复杂子系统提供一个简单接口。
    2 ．提高子系统的独立性。
    3 ．在层次化结构中，可以使用 Facade 模式定义系统中每一层的入口。

结构图:


模式的优缺点：
     外观模式的主要优点如下：
   (1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。
   (2) 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。
   (3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
    外观模式的主要缺点如下：
   (1) 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活 性。
   (2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

 
模式的应用实例：


模式比较：
    注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口，Adapter模式注重转换 接口，Bridge模式注重分离接口（抽象）与其实现，Decorator模式注重稳定接口的前提下为对象扩展功能。

要点：
    从客户程序的角度来看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。
    Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facdae很多时候更是一种架构。
    
    外观模式的主要目的在于降低系统的复杂程度，在面向对象软件系统中，类与类之间的关系越多，不能表示系统设计得越好，反而表示系统中类之间的耦合度太大，这样的系统在维护和修改时都缺乏灵活性，因为一个类的改动会导致多个类发生变化，而外观模式的引入在很大程度上降低了类与类之间的耦合关系。引入外观模式之后，增加新的子系统或者移除子系统都非常方便，客户类无须进行修改（或者极少的修改），只需要在外观类中增加或移除对子系统的引用即可。从这一点来说，外观模式在一定程度上并不符合开闭原则，增加新的子系统需要对原有系统进行一定的修改，虽然这个修改工作量不大。
    外观模式中所指的子系统是一个广义的概念，它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类，实现了一些具体的、独立的业务功能。
    
代码（其实读UML图要比代码还要一目了然）:
   

class SubSystemA  
    {  
        public void MethodA()  
        {  
            //业务实现代码  
        }  
    }  
      
    class SubSystemB  
    {  
        public void MethodB()  
        {  
            //业务实现代码  
         }  
    }  
      
    class SubSystemC  
    {  
        public void MethodC()  
        {  
            //业务实现代码  
        }  
    }  


      //在引入外观类之后，与子系统业务类之间的交互统一由外观类来完成，在外观类中通常存在如下代码：

    class Facade  
    {  
        private SubSystemA obj1 = new SubSystemA();  
        private SubSystemB obj2 = new SubSystemB();  
        private SubSystemC obj3 = new SubSystemC();  
      
        public void Method()  
        {  
            obj1.MethodA();  
            obj2.MethodB();  
            obj3.MethodC();  
        }  
    } 

      //由于在外观类中维持了对子系统对象的引用，客户端可以通过外观类来间接调用子系统对象的业务方法，而无须与子系统对象直接交互。引入外观类后，客户端代码变得非常简单，典型代码如下：

    class Program  
    {  
        static void Main(string[] args)  
        {  
            Facade facade = new Facade();  
            facade.Method();  
        }  
    }  

所有模式：

     创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
    行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
    补充模式：空对象模式

参考/转自：
    http://blog.csdn.net/lovelion/article/details/8258121
    http://blog.csdn.net/lovelion/article/details/8259789
    http://blog.csdn.net/cjjky/article/details/7570632
    http://sourcemaking.com/design_patterns/fa%C3%A7ade

转载请注明：http://blog.csdn.net/paincupid/article/details/44164411