设计模式——门面模式（外观模式）

门面模式定义

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

Subsystem Classes是子系统所有类的简称，它可能代表一个类，也可能代表几十个对象的集合。

门面模式中的角色

Facade门面角色

客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。

subsystem子系统角色

可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。
假设有三个类是一个子系统的不同逻辑处理模块，对于此子系统的访问需要通过门面进行，代码如下。

public class ClassA {     
	public void doSomethingA(){//业务逻辑} 
} 
public class ClassB {          
	public void doSomethingB(){//业务逻辑} 
} 
public class ClassC {          
	public void doSomethingC(){//业务逻辑}
}
public class Facade {     
	//被委托的对象     
	private ClassA a = new ClassA();     
	private ClassB b = new ClassB();     
	private ClassC c = new ClassC();     
	//提供给外部访问的方法    
	public void methodA(){             
		this.a.doSomethingA();     
	}          
	public void methodB(){
        this.b.doSomethingB();     
    }          
    public void methodC(){             
    	this.c.doSomethingC();     
    } 
}

门面模式中的优点

减少系统间的相互依赖

如果不使用门面模式，外界访问直接深入到子系统内部，相互之间是一种强耦合关系，这样的强依赖是系统设计所不能接受的，门面模式的出现就很好地解决了该问题，所有的依赖都是对门面对象的依赖，与子系统无关。

提高了灵活性

依赖减少了，灵活性自然提高了。不管子系统内部如何变化，只要不影响到门面对象，任你自由活动。

提高安全性

想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，你休想访问到。

门面模式中的缺点

门面模式最大的缺点就是不符合开闭原则（对修改关闭，对扩展开放），看看我们那个门面对象吧，它可是重中之重，一旦在系统投产后发现有一个小错误，你怎么解决？完全遵从开闭原则，根本没办法解决。继承？覆写？都顶不上用，唯一能做的一件事就是修改门面角色的代码，这个风险相当大，这就需要大家在设计的时候慎之又慎。

门面模式的使用场景

• 为每一个复杂的模块或子系统提供一个供外界访问的接口。
• 子系统相对独立——外界对子系统的访问只要黑箱操作即可。
• 预防低水平人员带来的风险扩散，比如：为降低个人代码质量对整体项目的影响风 险，一般的做法是“画地为牢”，只能在指定的子系统中开发，然后再提供门面接口进行访问操作。

门面模式的注意事项

一个子系统可以有多个门面

一个子系统通常只要有一个门面就够了，但有时一个子系统也需要多个门面，例如：

• 门面已经庞大到不能忍受的程度
  比如一个纯洁的门面对象已经超过了200行的代码，虽然都是非常简单的委托操作，也建议拆分成多个门面，否则会给以后的维护和扩展带来不必要的麻烦。那怎么拆分呢？按照功能拆分是一个非常好的原则，比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等。
• 子系统可以提供不同访问的路径
  我们以门面模式的通用源代码为例。ClassA、ClassB、ClassC是一个子系统的中3个对象，现在有两个不同的高层模块来访问该子系统，模块一可以完整的访问所有业务逻辑，也 就是通用代码中的Facade类，它是子系统的信任模块；而模块二属于受限访问对象，只能访 问methodB方法，那该如何处理呢？在这种情况下，就需要建立两个门面以供不同的高层模 块来访问，在原有的通用源码上增加一个新的门面即可。

public class Facade2 {     
	//引用原有的门面     
	private Facade facade = new Facade();     
	//对外提供唯一的访问子系统的方法     
	public void methodB(){             
		this.facade.methodB();     
	} 
}

日志的设计与门面模式

现在市面上的日志工具很多，例如JDK提供的JUL、Apache提供的Log4j、后起之秀LogBack以及后来被重写的Log4j2，各自都有自己的API，且可以独立的实现日志功能。但《阿里巴巴Java开发手册》，其中有一条规范做了『强制』要求：应用中不能直接使用日志工具（Log4j、logBack）的API来记录日志，而要使用日志框架（例如：SLF4j）中的API，使用门面模式的日志门面框架，有利于维护各个类的日志处理方式统一。

说好了以上四种常用的日志框架是给Java应用提供的方便进行记录日志的，那为什么又不让在应用中直接使用其API呢？这里面推崇使用的SLF4J是什么呢？所谓的门面模式又是什么东西呢？
门面模式我们已经知道了，提供一个高层次的接口，让子系统更易用。

就像前面介绍的几种日志框架一样，每一种日志框架都有自己单独的API，要使用对应的框架就要使用其对应的API，这就大大的增加应用程序代码对于日志框架的耦合性。假设有三个人开发一个系统，三个人的开发习惯不一样，用了三种日志框架，每个类里都有日志记录的代码，假设哪天某个框架爆出有漏洞或者老板一拍脑袋要统一日志，就得挨个类去看看然后修改，这太尴尬了。而且用三种日志工具，光日志的配置就得搞三份，也太不容易维护了，别人根本没法接手。

为了解决这个问题，就是在日志框架和应用程序之间架设一个沟通的桥梁，对于应用程序来说，无论底层的日志框架如何变，都不需要有任何感知。只要门面服务做的足够好，随意换另外一个日志框架，应用程序不需要修改任意一行代码，就可以直接上线。

日志门面在应用中屏蔽掉底层日志框架的具体实现。这样的话，即使有一天要更换代码的日志框架，只需要修改jar包，最多再改改日志输出相关的配置文件就可以了。这就解除了应用和日志框架之间的耦合。