设计模式(结构型)之外观模式(Facade Pattern)

PS一句：最终还是选择CSDN来整理发表这几年的知识点，该文章平行迁移到CSDN。因为CSDN也支持MarkDown语法了，牛逼啊！

【工匠若水 http://blog.csdn.net/yanbober】 阅读前一篇《设计模式(结构型)之装饰者模式(Decorator Pattern)》http://blog.csdn.net/yanbober/article/details/45395747

概述

一个客户类需要和多个业务类交互，而这些业务类经常会作为整体出现，由于涉及到的类比较多，导致使用时代码较为复杂。外观模式通过引入一个新的外观类(Facade)来实现该功能，外观类为多个业务类的调用提供统一入口，简化了类与类之间的交互。如果没有外观类，那么每个客户类需要和多个业务类之间进行复杂的交互，系统的耦合度将很大。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。

核心

概念： 为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

重点： 外观模式结构重要核心模块：

外观角色

客户端可以调用它的方法，在外观角色中可以知道相关子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。

子系统角色

在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

使用场景

需要访问一系列复杂的子系统时提供一个简单入口。

客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

程序猿实例

这里还是以苦逼的程序猿为例来说明外观模式。一个Android开发者开发Android程序需要很多工具条件，电脑，软件，网络。如下实现：

package yanbober.github.io;
//子系统角色
class Computer {
    public void thinkpad() {
        System.out.println("Computer is ThinkPad!");
    }
}

class EathNet {
    public void net() {
        System.out.println("Net is CMCC!");
    }
}

class DeveloperTools {
    public void tools() {
        System.out.println("Developer Tool is Android Studio!");
    }
}
//外观角色
class AndroidDeveloperEquipment {
    public void equipment() {
        new Computer().thinkpad();
        new EathNet().net();
        new DeveloperTools().tools();
    }
}

public class Main {
    public static void main(String[] args) {
        AndroidDeveloperEquipment dev = new AndroidDeveloperEquipment();
        dev.equipment();
    }
}

总结一把

外观模式优点：

• 减少客户端所需处理的对象数目，使得子系统使用起来更加容易。
• 实现了子系统与客户端之间的松耦合关系。
• 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

外观模式缺点：

• 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
• 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

【工匠若水 http://blog.csdn.net/yanbober】 继续阅读《待续。。。》