外观模式
1.什么是外观模式
我们去银行取钱，每个窗口都有个银行工作人员为大家服务。我们在取钱的过程中，只需要和窗口工作人员沟通就可以了，我们把银行卡给工作人员，输入密码就会给你取钱。在这个过程中，我们来分析下角色：
外部调用系统:银行取钱的人
复杂系统：银行系统
在复杂系统中，内部子系统：验钞机，打印机，保险箱等等
image.png
为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
外观模式又称为门面模式，它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。
2.UML结构图
image.png
外观模式包含如下两个角色：
-
Facade（外观角色）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。
-
SubSystem（子系统角色）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。
外观模式中所指的子系统是一个广义的概念，它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类，实现了一些具体的、独立的业务功能，
其典型代码:
//外观类
public class Facade{
//被委托的对象
SubSystemA a;
SubSystemB b；
SubSystemC c;
SubSystemD d;
public Facade(){
a=new SubSystemA();
b=new SubSystemB();
c=new SubSystemC();
}
//提供给外部访问的方法
public void methodA(){
this.a.doSomethingA();
}
public void methodB(){
this.b.doSomethingB();
}
public void methodC(){
this.c.doSomethingC();
}
}
//SubSystem子系统角色
public class SubSystemA{
public void doSomethingA(){
System.out.println("子系统方法A");
}
}
public class SubSystemB{
public void doSomethingB(){
System.out.println("子系统方法B");
}
}
public class SubSystemC{
public void doSomethingC(){
System.out.println("子系统方法C");
}
}
//客户端
Facade facade=new Facade();
facade.methodA();
facade.methodB();
3.使用场景
-
客户端不需要知道系统内部的复杂联系，整个系统只提供一个接待员即可.
-
为一个复杂的模块或子系统提供一个外界访问的接口
-
子系统相对独立，外界对子系统的访问只需要黑箱操作即可。
4.模式扩展
-
一个系统可以有多个外观类：在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。
-
不要试图通过外观类为子系统增加新行为：不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
-
外观模式与迪米特法则：外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少，使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
-
抽象外观类的引入：在标准的外观模式结构图中，如果需要增加、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则，因此可以通过引入抽象外观类来对系统进行改进，在一定程度上可以解决该问题。在引入抽象外观类之后，客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的。
