【架构—设计模式】外观模式

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

概述

在软件开发中，有时候为了完成一项较为复杂的功能，一个客户类须要和多个业务类交互，而这些须要交互的业务类常常会做为一个总体出现，因为涉及到的类比较多，致使使用时代码较为复杂。此时，特别须要一个相似服务员同样的角色，由它来负责和多个业务类进行交互，而客户类只需与该类交互。外观模式经过引入一个新的外观类(Facade)来实现该功能，外观类充当了软件系统中的“服务员”，它为多个业务类的调用提供了一个统一的入口，简化了类与类之间的交互。在外观模式中，那些须要交互的业务类被称为子系统(Subsystem)。若是没有外观类，那么每一个客户类须要和多个子系统之间进行复杂的交互，系统的耦合度将很大；而引入外观类以后，客户类只须要直接与外观类交互，客户类与子系统之间原有的复杂引用关系由外观类来实现，从而下降了系统的耦合度。

外观模式中，一个子系统的外部与其内部的通讯经过一个统一的外观类进行，外观类将客户类与子系统的内部复杂性分隔开，使得客户类只须要与外观角色打交道，而不须要与子系统内部的不少对象打交道。

外观模式定义以下：

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

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

外观模式没有一个通常化的类图描述，下面所示的类图能够做为描述外观模式的结构图：

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

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

引入外观模式以后，增长新的子系统或者移除子系统都很是方便，客户类无须进行修改（或者极少的修改），只须要在外观类中增长或移除对子系统的引用便可。从这一点来讲，外观模式在必定程度上并不符合开闭原则，增长新的子系统须要对原有系统进行必定的修改，虽然这个修改工做量不大。

外观模式中所指的子系统是一个广义的概念，它能够是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类一般是一些业务类，实现了一些具体的、独立的业务功能，其典型代码以下：

class SubSystemA
{
    public function MethodA()
    {
        //业务实现代码
    }
}

class SubSystemB
{
    public function MethodB()
    {
        //业务实现代码
    }
}

class SubSystemC
{
    public function MethodC()
    {
        //业务实现代码
    }
}

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

class Facade
{
    private $obj1;
    private $obj2;
    private $obj3;

    public function __construct()
    {
        $this->obj1 = new SubSystemA();
        $this->obj2 = new SubSystemB();
        $this->obj3 = new SubSystemC();
    }

    public function Method()
    {
        $this->obj1->MethodA();
        $this->obj2->MethodB();
        $this->obj3->MethodC();
    }
}

因为在外观类中维持了对子系统对象的引用，客户端能够经过外观类来间接调用子系统对象的业务方法，而无须与子系统对象直接交互。

案例

某软件公司欲开发一个可应用于多个软件的文件加密模块，该模块能够对文件中的数据进行加密并将加密以后的数据存储在一个新文件中，具体的流程包括三个部分，分别是读取源文件、加密、保存加密以后的文件，其中，读取文件和保存文件使用流来实现，加密操做经过求模运算实现。这三个操做相对独立，为了实现代码的独立重用，让设计更符合单一职责原则，这三个操做的业务代码封装在三个不一样的类中。

现使用外观模式设计该文件加密模块。

经过分析，本实例结构图如图所示：

EncryptFacade充当外观类，FileReader、CipherMachine和FileWriter充当子系统类。示例代码以下：

<?php

class FileReader
{
    public function Read(string $fileNameSrc): string
    {
        return file_get_contents($fileNameSrc);
    }
}

class CipherMachine
{
    public function Encrypt(string $plainText): string
    {
        return openssl_encrypt($plainText, 'DES-ECB', '123456');
    }
}

class FileWriter
{
    public function Write(string $encryptStr, string $fileNameDes)
    {
        file_put_contents($fileNameDes, $encryptStr);
    }
}


class EncryptFacade
{
    //维持对其余对象的引用
    private $reader;
    private $cipher;
    private $writer;

    public function __construct()
    {
        $this->reader = new FileReader();
        $this->cipher = new CipherMachine();
        $this->writer = new FileWriter();
    }

    //调用其余对象的业务方法
    public function FileEncrypt(string $fileNameSrc, string $fileNameDes)
    {
        $plainStr = $this->reader->Read($fileNameSrc);
        $encryptStr = $this->cipher->Encrypt($plainStr);
        $this->writer->Write($encryptStr, $fileNameDes);
    }
}

抽象外观类

在标准的外观模式结构图中，若是须要增长、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则，所以能够经过引入抽象外观类来对系统进行改进，在必定程度上能够解决该问题。在引入抽象外观类以后，客户端能够针对抽象外观类进行编程，对于新的业务需求，不须要修改原有外观类，而对应增长一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时经过修改配置文件来达到不修改任何源代码并更换外观类的目的。

若是在应用实例“文件加密模块”中须要更换一个加密类，再也不使用原有的加密类CipherMachine，而改成新加密类NewCipherMachine。若是不增长新的外观类，只能经过修改原有外观类EncryptFacade的源代码来实现加密类的更换，将原有的对CipherMachine类型对象的引用改成对NewCipherMachine类型对象的引用，这违背了开闭原则，所以须要经过增长新的外观类来实现对子系统对象引用的改变。

若是增长一个新的外观类NewEncryptFacade来与FileReader类、FileWriter类以及新增长的NewCipherMachine类进行交互，虽然原有系统类库无须作任何修改，可是由于客户端代码中原来针对EncryptFacade类进行编程，如今须要改成NewEncryptFacade类，所以须要修改客户端源代码。

如何在不修改客户端代码的前提下使用新的外观类呢？解决方法之一是：引入一个抽象外观类，客户端针对抽象外观类编程，而在运行时再肯定具体外观类。更换具体外观类时只需修改配置文件，无须修改源代码，符合开闭原则。

总结

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

外观模式并不给系统增长任何新功能，它仅仅是简化调用接口。在几乎全部的软件中都可以找到外观模式的应用，如绝大多数B/S系统都有一个首页或者导航页面，大部分C/S系统都提供了菜单或者工具栏，在这里，首页和导航页面就是B/S系统的外观角色，而菜单和工具栏就是C/S系统的外观角色，经过它们用户能够快速访问子系统，下降了系统的复杂程度。全部涉及到与多个业务对象交互的场景均可以考虑使用外观模式进行重构。

主要优势

1. 它对客户端屏蔽了子系统组件，减小了客户端所需处理的对象数目，并使得子系统使用起来更加容易。经过引入外观模式，客户端代码将变得很简单，与之关联的对象也不多。
2. 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只须要调整外观类便可。
3. 一个子系统的修改对其余子系统没有任何影响，并且子系统内部变化也不会影响到外观对象。

主要缺点

1. 不能很好地限制客户端直接使用子系统类，若是对客户端访问子系统类作太多的限制则减小了可变性和灵活性。
2. 若是设计不当，增长新的子系统可能须要修改外观类的源代码，违背了开闭原则。

适用场景

1. 当要为访问一系列复杂的子系统提供一个简单入口时可使用外观模式。
2. 客户端程序与多个子系统之间存在很大的依赖性。引入外观类能够将子系统与客户端解耦，从而提升子系统的独立性和可移植性。
3. 在层次化结构中，可使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而经过外观类创建联系，下降层之间的耦合度。