外观模式(结构型)
外观模式又名门面模式
-
是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。
-
该模式对外有一个统一的接口,外部应用程序不用关心内部子系统的具体的细节,这样就大大降低了应用程序的复杂度,并提高了程序的可维护性。
-
还有一点需要大家知道,外观(Facade)模式是"迪米特法则"的典型应用。
-
我们可以来看一下下面这张图。
先看上图左边部分,大矩形表示一个子系统,子系统里面有很多很多的类,对于访问者来说,只有了解了子系统里面的实现之后,他才能更好的去使用子系统,这是在没有使用外观模式的情况下对子系统的一个访问,很明显,这增加了访问者访问的难度。
再来看上图右边部分,这是在使用外观模式的情况下对子系统的一个访问,此时,对于访问者来说,他并不需要去关注这个子系统里面是如何实现的,而是只需要去调用对外提供的统一的接口就可以正常的去访问它了,以大大地降低了访问者使用子系统类的一个成本,其实,这也是外观模式的一个好处。
结构
- facade: 外观,外表
理解了外观模式的概念之后,接下来,我们来看一下外观模式所包含的角色。
外观(Facade)模式包含以下主要角色:
外观(Facade)角色:为多个子系统对外提供一个共同的接口
子系统(Sub System)角色:实现系统的部分功能,客户可以通过外观角色访问它。
- 这样,对于访问者来说,他并不需要去关注子系统,而只需要关注外观角色就行,因为我们到时候是要通过外观角色去使用子系统里面的那些对象的。
外观模式案例
小明的爷爷已经60岁了,一个人在家生活:每次都需要打开灯、打开电视、打开空调;睡觉时关闭灯、关闭电视、关闭空调;操作起来都比较麻烦。所以小明给爷爷买了一个智能音箱,可以通过语音直接控制这些智能家电的开启和关闭。
阅读完上面的描述,我们知道智能音箱代表的就是外观角色,客户只需要和这个智能音箱进行交互即可。
下面我们再来看一下这张类图。
从以上类图中
-
有一个电灯类(即Light),它里面有两个方法,一个是开启电灯(即on方法),一个是关闭电灯(即off方法);
-
也有一个电视类(即TV),它里面也有两个方法,一个是开启电视(即on方法),一个是关闭电视(即off方法);
-
还有一个空调类(即AirCondition),它里面也是有两个方法,一个是开启空调(即on方法),一个是关闭空调(即off方法)。
-
重要的是SmartAppliancesFacade类,它是一个外观类,它里面聚合了Light、TV、AirCondition等等这些类;
-
除此之外,它里面还提供了一个无参构造及say方法,通过该say方法,我们就可以通过语音直接控制这些智能家电的开启和关闭了;
-
最后,它里面还提供了两个方法,一个是用来一键开启所有智能家电的(即on方法),一个是用来一键关闭所有智能家电的(即off方法)注意了,这俩方法都是私有的,因为这俩方法都只在say方法里面被调用。
代码实现
package com.meimeixia.pattern.facade;
public class Light {
// 开灯
public void on() { //虽然与外观类中的方法重名,但并不是继承重写哈,因为这里并没有继承只是单纯的重名而已
System.out.println("打开电灯......");
}
// 关灯
public void off() {
System.out.println("关闭电灯......");
}
}
package com.meimeixia.pattern.facade;
public class TV {
public void on() {
System.out.println("打开电视机......");
}
public void off() {
System.out.println("关闭电视机......");
}
}
package com.meimeixia.pattern.facade;
public class AirCondition {//空调
public void on() {
System.out.println("打开空调......");
}
public void off() {
System.out.println("关闭空调......");
}
}
再接着,创建智能音箱类,这里我们不妨起名为SmartAppliancesFacade。
注意了,该类就是外观类,用户主要就是和该类对象进行交互。
package com.meimeixia.pattern.facade;
/**
* 外观类,用户主要和该类对象进行交互
* @author liayun
* @create 2021-07-31 19:24
*/
public class SmartAppliancesFacade {
// 聚合电灯对象、电视机对象、空调对象
private Light light;
private TV tv;
private AirCondition airCondition;
/*
* 以上只是声明了三个成员变量,但是它们都还未赋值具体的对象,所以我们可以在SmartAppliancesFacade类
* 中定义一个如下的无参的构造方法,在该无参构造里面为它们赋值
*/
public SmartAppliancesFacade() {
light = new Light();
tv = new TV();
airCondition = new AirCondition();
}
// 通过语音控制
public void say(String message) {
if (message.contains("打开")) { // 若用户说的语言里面包含了打开这样的一个字眼,则调用on方法一键打开所有智能家电
on();
} else if (message.contains("关闭")) { // 若用户说的语言里面包含了关闭这样的一个字眼,则调用off方法一键关闭所有智能家电
off();
} else {
System.out.println("我还听不懂你说的!!!");
}
}
// 一键打开功能
private void on() {
light.on();
tv.on();
airCondition.on();
}
// 一键关闭功能
private void off() {
light.off();
tv.off();
airCondition.off();
}
}
客户端调用测试
package com.meimeixia.pattern.facade;
public class Client {
public static void main(String[] args) {
// 创建智能音箱对象
SmartAppliancesFacade facade = new SmartAppliancesFacade();
// 控制家电
facade.say("打开家电"); // 早上起来时,喊一声"打开家电",那么所有的家电都会打开
System.out.println("==========================");
facade.say("关闭家电"); // 晚上睡觉时,喊一声"关闭家电",那么所有的家电都会关闭
}
}
优缺点
优点
1、降低了子系统与客户端之间的耦合度(很显然,这是由外观类来降低的),使得子系统的变化不会影响调用它的客户端
2、对客户屏蔽了子系统组件,减少了客户处理的对象数目(如果客户直接去访问这些子系统的话,那么就可能要去访问不同的子系统里面的多个对象了,这还是比较麻烦的),并使得子系统使用起来更加容易
缺点
外观模式是不符合开闭原则的,所以修改起来很麻烦。
比如说子系统里面发生了一个改变的话,那么我们就得去修改该子系统了,虽然客户端我们是不需要修改的,而且可能我们还需要去修改外观类里面的代码。
使用场景
1、对分层结构系统构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
如果系统有分层结构(即高层调用底层)的话,那么我们在去调用的时候,直接去依赖具体的一个公共接口即可(不是指interface声明的接口),而不是再依赖具体的实现了,这样,可以使得后期代码的扩展性更好一些,当然也可以简化系统之间的依赖关系
2、当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问。
这也说明以后我们在去设计咱们的软件时,一定要满足这一点。其实在使用别人写的框架时,你会发现框架底层做了很多很多的封装,使用起该框架来就会特别特别简单了,这个就是人家写的框架的一个好处
3、当客户端与多个子系统之间存在很大的联系时,引入外观模式可将它们分离,从而提高子系统的独立性和可移植性。
我们使用外观模式,可以降低(或者消除)客户端和多个子系统之间的一个耦合,这样,当我们去修改客户端代码时,就不用再去修改子系统里面的代码了,因为此时客户端和子系统是没有任何关系的。同理,当我们去修改子系统里面的代码时,客户端代码也就不需要再进行修改了
在tomcat中的
使用Tomcat作为web容器时,接收浏览器发送过来的请求:
Tomcat会将请求信息封装成ServletRequest对象,如下图①处对象。
ServletRequest是一个接口,它还有一个子接口HttpServletRequest,而我们知道doPost方法里面的request对象肯定是一个HttpServletRequest接口的子实现类对象
那该request对象到底是哪个类的对象呢?
可以直接将该request对象打印出来
这样,你就可以看到它到底是哪个类的对象了。该request对象其实是一个名为RequestFacade的类的对象,而该类就使用到了外观模式
大家先看一下下面这张类图。
可以看到,最顶层是一个叫ServletRequest的接口,它下面有一个子接口,即HttpServletRequest,而该HttpServletRequest接口又有一个叫RequestFacade的子实现类。并且,在RequestFacade类中,还聚合了Request类的对象,注意,Request类也是HttpServletRequest接口的一个子实现类
那么问题来了,RequestFacade类怎么使用外观模式的呢?
其实,RequestFacade类就是外观类,它代表外观角色,而Request类属于子系统角色,我们只需要去和RequestFacade类的对象进行交互就行了,并不需要再直接去和Request类的对象进行交互了
为什么在此处使用外观模式呢?
定义RequestFacade类,让其分别实现ServletRequest和HttpServletRequest这俩接口,同时又在其里面定义了一个私有成员变量(Request类型的变量),很显然,RequestFacade类里面方法的实现会调用Request成员变量里面的方法,也就是说RequestFacade类里面的方法其本质上还是使用Request类中的方法。然后,我们在去使用的时候,**Tomcat会将RequestFacade对象上转为ServletRequest(或者HttpServletRequest)(就是面向接口编程)**并传给Servlet里面的service方法,这样即使在Servlet中被下转为RequestFacade,咱们也不能访问私有成员变量对象(即Request对象)中的方法,因为该私有成员变量对象(即Request对象)是受保护的,是不能直接去使用的。
- 可见,现在是既用了Request对象里面的方法,又能防止其中方法被外界不合理的访问(这是因为Request对象里面的一些方法是想对外进行一个屏蔽的)