设计模式-外观模式

外观模式介绍

外观模式（Facade Pattern），在开发过程中运用频率非常高，无论是做 SDK 还是封装API，我们大多都会用到外观模式，它通过一个外观类使得整个系统的结构只有一个统一的高层接口，这样能降低用户的使用成本。

外观模式定义

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

外观模式使用场景

1. 构建一个有层次结构的子系统时，使用外观模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，则可以让他们通过外观接口进行通信，减少子系统之间的依赖关系。
2. 子系统往往会因为不断的重构演化而变得越来越复杂，大多数的模式使用时也会产生很多很小的类，这给外部调用他们的用户程序带来了使用的困难，我们可以使用外观类提供一个简单的接口，对外隐藏子系统的具体实现并隔离变化。

外观模式 UML 类图

角色介绍：

• Facade：外观类，知道哪些子系统类负责处理请求，将客户端的请求代理给适当的子系统对象。
• Subsystem：子系统类，实现子系统的功能，处理外观类指派的任务，注意子系统类不含有外观类的引用。

外观模式的实现

这里以手机为例，它集合了电话、短信、相机等功能，通过手机就可以完成各种功能，而无需每一个模块都独立出来。通过手机对象完成完成各个模块功能的调用，这就是外观模式。
子系统类（Subsystem）
电话子系统

public interface Phone {
    void dial();

    void hangup();
}

public class PhoneImpl implements Phone {
    @Override
    public void dial() {
        System.out.println("打电话");
    }

    @Override
    public void hangup() {
        System.out.println("挂断");
    }
}

相机子系统

public interface Camera {
    void open();

    void takePicture();

    void close();
}
public class CameraImpl implements Camera {
    @Override
    public void open() {
        System.out.println("打开相机");
    }

    @Override
    public void takePicture() {
        System.out.println("拍照");
    }

    @Override
    public void close() {
        System.out.println("关闭相机");
    }
}

外观类（Facade）
手机统一用户调用接口

public class MobilePhone {
    private Phone mPhone = new PhoneImpl();
    private Camera mCamera = new CameraImpl();

    public void dial() {
        mPhone.dial();
    }

    public void videoChat() {
        System.out.println("视频聊天接通中...");
        mCamera.open();
        mPhone.dial();
        System.out.println("视频聊天已接通");
    }

    public void hangup() {
        mPhone.hangup();
    }

    public void takePicture() {
        mCamera.open();
        mCamera.takePicture();
    }

    public void closeCamera() {
        mCamera.close();
    }
}

运行结果：

打电话
视频聊天接通中...
打开相机
打电话
视频聊天已接通

从上面的代码可以看到，外观模式就是统一接口封装，将子系统的逻辑、交互隐藏，及时具体的子系统发生变化，用户也不会感知到，变化隔离开来，我们的系统也更为灵活。

总结

优点
1.对客户程序隐藏子系统细节，因而减少客户对于子系统的耦合。
2.外观类对子系统的接口封装，使得系统更易于使用。
缺点

1. 外观类没有遵循开闭原则，业务变更时，可能需要直接修改外观类。