设计模式--外观模式

设计模式 结构型模式

目录

本文的结构如下：

• 什么是外观模式
• 模式的结构
• 代码示例
• 优点和缺点
• 适用环境
• 模式应用
• 模式扩展
• 补充

一、前言

话说某天空气质量回到秦汉，月色如水倾泻，温度适宜，微风袭人，我在院子树下架起圆木桌，摆上雕花凳，桌上依次摆放红烧肘子，烧牛肉，剁椒鱼头，烤羊排，炸猛男......美人在怀，饮一口小酒，复又夹起一块牛肉放入口中，这滋味，岂不快哉？

快你个头啊，赶紧起来给我码代码。

恍惚中听到一声怒吼，我从好梦中惊醒。啊，没有酒，没有肉，没有美人，只有汉城4点钟的太阳，油腻的中年组长大叔和屏幕前没有吃完的老坛酸菜面，泪哭。

咳咳，回到正题，我们接着讲美食。美食适合享用，不宜动手操弄，如果自己动手，要做好一道美食，需要的事物很多，碗，锅，水，调味品，食材等等，需要这些东西经过一些列交互才能得到最后的美食。

美食做法实在太过累人，可是还是想吃怎么办呢？

找妈妈啊，一句：“妈，我想吃肉。”然后可以逛知乎，刷微博，打游戏，在手机上进行了一轮复杂操作，就听妈妈喊一声：“吃饭了。”于是乎，一只手握着手机改看小说，一只手夹肉，嘴里嘟囔道：“妈，你做的红烧肉太好吃了。”

咳咳，这次真的回到正题。

刚才“饿了找妈妈”的例子其实就是在说外观模式。在软件开发中，有时候某个客户类（“我”）可能会与多个业务类（“水，调味品，食材”）交互，而这些需要交互的业务类经常会作为一个整体出现，由于涉及到的类比较多，导致使用时代码较为复杂，此时，特别需要一个类似“妈妈”一样的角色，由它来负责和多个业务类进行交互，而客户类只需与该类交互。外观模式通过引入一个新的外观类(Facade)来实现该功能，外观类充当了软件系统中的“妈妈”，它为多个业务类的调用提供了一个统一的入口，简化了类与类之间的交互。在外观模式中，那些需要交互的业务类被称为子系统(Subsystem)。如果没有外观类，那么每个客户类需要和多个子系统之间进行复杂的交互，系统的耦合度将很大，而引入外观类之后，客户类只需要直接与外观类交互，客户类与子系统之间原有的复杂引用关系由外观类来实现，从而降低了系统的耦合度。

插一句，不得不说，妈妈其实就像个服务员，不停服务自己的丈夫和孩子，还经常受到埋怨，太辛苦了。

二、什么是外观模式

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

外观模式又称为门面模式，它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。

三、模式的结构

外观模式包含如下两个角色：

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

四、代码示例

4.1、就以“饿了找妈妈”为例，在不使用外观模式前，是这样设计的：

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Material {
    public void prepare(){
        System.out.println("从菜市场买回食材，并清洗");
    }
}
/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Pan {
    public void wash(){
        System.out.println("炒菜前要先洗锅");
    }
}
/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Flavouring {
    public void add(){
        System.out.println("依次放入各种调味品");
    }
}

我进行制作美食：

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Client {
    public static void main(String[] args) {
        Material material = new Material();
        Pan pan = new Pan();
        Flavouring flavouring = new Flavouring();
        System.out.println("肚子饿了");
        material.prepare();
        pan.wash();
        flavouring.add();
        System.out.println("出锅，可以吃饭了");
    }
}

结果：
肚子饿了
从菜市场买回食材，并清洗
炒菜前要先洗锅
依次放入各种调味品
出锅，可以吃饭了

4.2、使用外观模式

/**
 * Created by w1992wishes on 2017/11/9.
 */
public class Mom {
    Material material;
    Pan pan;
    Flavouring flavouring;
    public Mom(){
        this.material = new Material();
        this.pan = pan = new Pan();
        this.flavouring = new Flavouring();
    }
    public void makeDish(){
        material.prepare();
        pan.wash();
        flavouring.add();
    }
}

妈妈制作美食：

public class Client {
    public static void main(String[] args) {
        Mom mom = new Mom();
        System.out.println("肚子饿了");
        mom.makeDish();
        System.out.println("出锅，可以吃饭了");
    }
}

五、优点和缺点

5.1、优点

• 对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。
• 实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
• 降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
• 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

5.2、缺点

• 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
• 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

六、适用环境

在以下情况下可以使用外观模式：

• 当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求，而且用户也可以越过外观类直接访问子系统。
• 客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦，可以提高子系统的独立性和可移植性。
• 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

七、模式应用

八、模式扩展

• 一个系统可以有多个外观类：在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。
• 不要试图通过外观类为子系统增加新行为：不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
• 外观模式与迪米特法则：外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少，使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
• 抽象外观类的引入：在标准的外观模式结构图中，如果需要增加、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则，因此可以通过引入抽象外观类来对系统进行改进，在一定程度上可以解决该问题。在引入抽象外观类之后，客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的。

九、补充--与适配器模式的区别

• 外观模式的实现核心主要是——由外观类去保存各个子系统的引用，实现由一个统一的外观类去包装多个子系统类，然后客户端只需要引用这个外观类，然后由外观类来调用各个子系统中的方法。
• 这样的实现方式非常类似适配器模式，然而外观模式与适配器模式不同的是：适配器模式是将一个对象包装起来以改变其接口，而外观是将一群对象 ”包装“起来以简化其接口。它们的意图是不一样的，适配器是将接口转换为不同接口，而外观模式是提供一个统一的接口来简化接口。