《放着我来-外观模式》

概述

外观模式（Facade）,为子系统中的一组接口提供一个一直的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

类图

[一张图胜过千言万语，可清晰地展现外观模式的结构，以及具体的关系]

优点

1.实现了子系统与客户端之间的松耦合关系。
2.客户端屏蔽了子系统组件，减少了客户端需要处理的对象数目，使得子系统的使用变得容易。

缺点

1.不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统做太多的限制，则减少了可变性和灵活性。
2.如若设计不当，可能会因增加一个子系统类，而对外观类进行修改，违背开闭原则。

何时上场

1.在设计初期阶段，有意识的将不同的两个层分离，在层与层之间建立，提供一个简单的接口，降低耦合度。
2.在开发阶段，子系统需要不断重构演化，增加外观，较少它们之间的依赖。
3.在维护一个遗留的大型系统时，为保留其重要功能，为新系统增加外观，以便于新系统与Façade对象进行交互，Façade与遗留代码进行交互。

独特魅力

完美体现依赖倒转原则和迪米特法则。
可曾还记得依赖倒转原则？——会修电脑不会修收音机
A.高层模块不应该依赖低层模块。两个都应该依赖抽象。
B.抽象不应该依赖细节。细节应该依赖抽象。
可曾熟悉迪米特法则？——无熟人难办事
迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个雷需要调用另一个类的某一个方法的话，可以通过第三者转达这个调用。

照葫芦画瓢

//四个子系统的类，此处仅仅列举一个子类，其余代码类似，小编不再一一列举
//理论
class SubSystemOne
{
    public void MethodOne()
    {
       Console.WriteLine("子系统方法一");
    }
}

//实践
class Stock1
{   
    //卖股票
    public void Sell()
    {
       Console.WriteLine("股票一卖出")
    }
    public void Buy()
    {
        Console.WriteLine("股票一买出")   
    }
 }

//外观类 (它需要了解所有的子系统的方法或属性，进行组合，以备外界调用)
class Facade
{
    SubSystemOne one;
    public Facade()
    {
       one = new SubSystemOne();
    }
    Pulic void MethodA()
    {
       Console.WriteLine("\n方法组A()-----");
       one.MethodOne();
    }
}

//客户端调用
static void Main(string[] args)
{
    Facade facade = new Facade();
    facade.MethodA();
    Console.Read();
}

一言堂

大话设计模式中运用股民炒股将抽象的外观模式转化为具体的阐释，在未使用外观模式之前，股民炒股需要自己时刻关注股票市场信息；在借助外观模式之后，股民只需要向基金公司投资基金，参与股票的具体买卖由基金公司承担。

这样的例子在生活中不乏少见，还记得古时养蚕制衣吗？
细心呵护蚕宝宝，终获取柔软的蚕丝，然后根据自己心中所想，一针一线做成自己梦寐以求的衣服。只有自己想得到，才能做得到。
如今的世界，服装公司早已应运而生。
你只需要告诉服装公司你的需求，他们便可制作出你想要的衣服，不必再费心费力去亲力亲为。只有你想不到，没有你得不到。

外观模式就是与人方便，虽说坐享其成并不是一件好事情，然而也得具体情况具体分析，运用外观模式在软件开发中不劳而获也未尝不可。

总览全局

PS：个人认为外观模式与装饰模式有很大的相似之处，然而具体的区别还尚未明白，仍需上下求索。愿小伙伴们多多献言。