深入浅出-外观模式
外观模式是一种使用频率非常高的结构型设计模式，它通过引入一个外观角色来简化客户端 与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦 合度，且客户端调用非常方便。
外观模式概述 ：
不知道大家有没有比较过自己泡茶和去茶馆喝茶的区别，如果是自己泡茶需要自行准备茶 叶、茶具和开水，如图1(A)所示，而去茶馆喝茶，最简单的方式就是跟茶馆服务员说想要一杯 什么样的茶，是铁观音、碧螺春还是西湖龙井？正因为茶馆有服务员，顾客无须直接和茶 叶、茶具、开水等交互，整个泡茶过程由服务员来完成，顾客只需与服务员交互即可，整个 过程非常简单省事，如图
在软件开发中，有时候为了完成一项较为复杂的功能，一个客户类需要和多个业务类交互， 而这些需要交互的业务类经常会作为一个整体出现，由于涉及到的类比较多，导致使用时代 码较为复杂，此时，特别需要一个类似服务员一样的角色，由它来负责和多个业务类进行交 互，而客户类只需与该类交互。外观模式通过引入一个新的外观类(Facade)来实现该功能，外 观类充当了软件系统中的“服务员”，它为多个业务类的调用提供了一个统一的入口，简化了类 与类之间的交互。在外观模式中，那些需要交互的业务类被称为子系统(Subsystem)。如果没 有外观类，那么每个客户类需要和多个子系统之间进行复杂的交互，系统的耦合度将很大， 如图2(A)所示；而引入外观类之后，客户类只需要直接与外观类交互，客户类与子系统之间原 有的复杂引用关系由外观类来实现，从而降低了系统的耦合度，如图2(B)所示。
外观模式中，一个子系统的外部与其内部的通信通过一个统一的外观类进行，外观类将客户 类与子系统的内部复杂性分隔开，使得客户类只需要与外观角色打交道，而不需要与子系统 内部的很多对象打交道。
外观模式定义如下： 外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义 了一个高层接口，这个接口使得这一子系统更加容易使用。 Facade Pattern: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
外观模式又称为门面模式，它是一种对象结构型模式。外观模式是迪米特法则的一种具体实 现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦 合度。
外观模式没有一个一般化的类图描述，外观模式的结构图：
外观模式包含如下两个角色：
(1) Facade（外观角色）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个 或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应 的子系统去，传递给相应的子系统对象处理。
(2) 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();
}
}
|
举个栗子：
实现一个能够画图形的功能 三角形、方形、圆形
我们将创建一个 Shape 接口和实现了 Shape 接口的实体类。下一步是定义一个外观类 ShapeMaker。
ShapeMaker 类使用实体类来代表用户对这些类的调用。FacadePatternDemo，我们的演示类使用 ShapeMaker 类来显示结果。
创建一个接口。
//Shape.java
public interface Shape {
void draw();
}
|
创建实现接口的实体类。
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}
|
public class Square implements Shape { @Override public void draw() { System.out.println("Square::draw()"); } }
|
public class Circle implements Shape { @Override public void draw() { System.out.println("Circle::draw()"); } }
|
创建一个外观类。
public class ShapeMaker { private Shape circle; private Shape rectangle; private Shape square; public ShapeMaker() { circle = new Circle(); rectangle = new Rectangle(); square = new Square(); } public void drawCircle(){ circle.draw(); } public void drawRectangle(){ rectangle.draw(); } public void drawSquare(){ square.draw(); } }
|
使用该外观类画出各种类型的形状。
public class FacadePatternDemo { public static void main(String[] args) { ShapeMaker shapeMaker = new ShapeMaker(); shapeMaker.drawCircle(); shapeMaker.drawRectangle(); shapeMaker.drawSquare(); } }
|
执行程序，输出结果：
Circle::draw()
Rectangle::draw()
Square::draw()
外观模式效果与适用场景
外观模式是一种使用频率非常高的设计模式，它通过引入一个外观角色来简化客户端与子系 统之间的交互，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降 低，且客户端调用非常方便。外观模式并不给系统增加任何新功能，它仅仅是简化调用接 口。在几乎所有的软件中都能够找到外观模式的应用，如绝大多数B/S系统都有一个首页或者 导航页面，大部分C/S系统都提供了菜单或者工具栏，在这里，首页和导航页面就是B/S系统 的外观角色，而菜单和工具栏就是C/S系统的外观角色，通过它们用户可以快速访问子系统， 降低了系统的复杂程度。所有涉及到与多个业务对象交互的场景都可以考虑使用外观模式进 行重构。
模式优点
外观模式的主要优点如下：
(1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起 来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。
(2) 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客 户端，只需要调整外观类即可。
(3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对 象。
5.2 模式缺点
外观模式的主要缺点如下：
(1) 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减 少了可变性和灵活 性。
(2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。
5.3 模式适用场景
在以下情况下可以考虑使用外观模式：
(1) 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
(2) 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。
(3) 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联 系，而通过外观类建立联系，降低层之间的耦合度。