十三、外观模式—— 简化接口 #和设计模式一起旅行#

我不想成为上帝或英雄，只想成为一棵树，为岁月而生长，不伤害任何人。 ——米沃什

故事背景

在英国体验了康桥的魅力，我挥一挥衣袖，不带走一片云彩，但是英国的天空没有留下我的痕迹，但我曾去过。哈哈！

从英国到法国，在浪漫的巴黎，我和设计模式MM感受到这个城市别样的风景，很是吸引人，我们决定在这里待一段时间在走。

于是去政府部门办理一些手续，本来以为会花费很多时间的，因为之前办理总是要去很多个办公室才能搞定，没想到，这次很快，在大厅的窗口就一次性办理好了。

设计模式MM说：这个套路很像一种设计模式-外观模式。

这个设计模式主要用于在一个大的系统有多个子系统的时候，多个子系统肯定要互相通信，但是每个子系统又不能将内部的过多数据暴露给其他系统，不然就没有必要划分子系统了。

就如之前要去办理一个业务，要去A办公室（A系统）去填报，填好表在去B办公室（B系统）盖章，然后去C办公室（C系统）打印，然后将表交给D办公室（D系统）等等的操作，每一个人都要进行这个繁琐的流程。现在只需要去一个窗口登记个人信息，就ok了！

两种办理业务的简单图示

在软件开发中，有时候为了完成一项较为复杂的功能，一个客户类需要和多个业务类交互，而这些需要交互的业务类经常会作为一个整体出现，由于涉及的类比较多，导致使用时候代码较为复杂，此时特别需要一个类似“业务办理窗口”这样的一个角色。由它来负责和多个系统进行交互，而客户端只需要与该类交互即可。

外观模式示意图

故事主角

外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层的接口，让客户端更容易使用。

外观模式

外观模式又称为门面模式，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。

外观模式包含两个角色：

Facade（外观角色）：客户端可以调用它的方法，在外观角色中科院知道相关的子系统的功能和责任。
subSystem(子系统角色)：可以有一个或者多个子系统，每个子系统实现各自个功能，子系统被外观角色调用。

简单代码表示：

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 Test
{
    public static void main(string[] args)
    {
        Facade facade = new Facade();
        facade.Method();
    }
}

武功修炼

public class OfficeA{

    public void doWork(){
        System.out.println("--办公室A-填表-----");
    }

}
public class OfficeB {

    public void doWork(){
        System.out.println("--办公室B-盖章-----");
    }

}

public class OfficeC {


    public void doWork(){
        System.out.println("--办公室C--复印----");
    }
}

public class OfficeD {

    public void doWork(){
        System.out.println("--办公室D--交表----");
    }
}

public class OfficeFacade {

    private OfficeA officeA = new OfficeA();
    private OfficeB officeB = new OfficeB();
    private OfficeC officeC = new OfficeC();
    private OfficeD officeD = new OfficeD();

    public void doWork(){
        officeA.doWork();
        officeB.doWork();
        officeC.doWork();
        officeD.doWork();
    }

}
public class Client {

    public static void main(String[] args) {
        //客户只需要面对门面的窗口即可，不需要关注子系统是如何工作的
        OfficeFacade facade = new OfficeFacade();
        facade.doWork();
    }
}
--办公室A-填表-----
--办公室B-盖章-----
--办公室C--复印----
--办公室D--交表----

上面的示例代码是很简单的，只是为了说明这个模式的，真实的系统设计比这个负责的多。

外观模式是一种使用频率非常高的结构型设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦合度，且客户端调用非常方便。

只要细心观察，会发现很多框架中使用了改设计模式，在Spring中，在Tomcat中都能发现此设计模式的身影。

总结

优点：

使客户端代码变得简单，屏蔽关联对象/组件。
子系统与客户端之间的松耦合关系，客户端，只需要调整外观类即可。

缺点：

设计不当，在增加新的子系统的时候需要修改外观类的代码，违反开闭原则。
不能很好的限制客户端直接使用子系统。

适用场景：

当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

Next 期待下一篇吧！下一篇讲讲迭代器！

参考

史上最全设计模式导学
《Head First 设计模式》
《图解设计模式》

如果您觉得这篇博文对你有帮助，请点赞或者喜欢，让更多的人看到，谢谢！

如果帅气（美丽）、睿智（聪颖），和我一样简单善良的你看到本篇博文中存在问题，请指出，我虚心接受你让我成长的批评，谢谢阅读！
祝你今天开心愉快！

欢迎访问我的csdn博客，我们一同成长！

不管做什么，只要坚持下去就会看到不一样！在路上，不卑不亢!

博客首页 : http://blog.csdn.net/u010648555