在现实生活中,常常存在办事较复杂的例子,如办房产证或注册一家公司,有时要同多个部门联系,这时要是有一个综合部门能解决一切手续问题就好了。
软件设计也是这样,当一个系统的功能越来越强,子系统会越来越多,客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变,客户端也要跟着改变,这违背了“开闭原则”,也违背了“迪米特法则”,所以有必要为多个子系统提供一个统一的接口,从而降低系统的耦合度,这就是外观模式的目标。
下图给出了客户去当地房产局办理房产证过户要遇到的相关部门
外观(Facade)模式的定义:是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口,外部应用程序不用关心内部子系统的具体的细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性。
外观(Facade)模式的结构比较简单,主要是定义了一个高层接口。它包含了对各个子系统的引用,客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。
外观(Facade)模式包含以下主要角色。
外观(Facade)模式是“迪米特法则”的典型应用,它有以下主要优点。
外观(Facade)模式的主要缺点如下。
通常在以下情况下可以考虑使用外观模式。
示例:
1,子系统角色,由若干个类组成
public class SubClass1 {
public void method1(){
System.out.println("这是子系统类1中的方法1");
}
public void method2(){
System.out.println("这是子系统类1中的方法2");
}
}
public class SubClass2 {
public void method1(){
System.out.println("这是子系统类2中的方法1");
}
public void method2(){
System.out.println("这是子系统类2中的方法2");
}
}
public class SubClass3 {
public void method1(){
System.out.println("这是子系统类3中的方法1");
}
public void method2(){
System.out.println("这是子系统类3中的方法2");
}
}
2,外观角色类
public class FacadeClass {
public void FacadeMethod(){
SubClass1 s1 = new SubClass1();
s1.method1();
SubClass2 s2 = new SubClass2();
s2.method1();
SubClass3 s3 = new SubClass3();
s3.method1();
}
}
3,客户端测试方法
public class ClientClass {
public static void main(String[] args) {
FacadeClass fc = new FacadeClass();
fc.FacadeMethod();
}
}
Facade类其实相当于子系统中SubClass类的外观界面,有了这个Facade类,那么客户端就不需要亲自调用子系统中的那些具体实现的子类了,也不需要知道系统内部的实现细节,甚至都不需要知道这些子类的存在,客户端只需要跟Facade类交互就好了,从而更好地实现了客户端和子系统中具体类的解耦,让客户端更容易地使用系统。
同时,这样定义一个Facade类可以有效地屏蔽内部的细节,免得客户端去调用Module类时,发现一些不需要它知道的方法。如上代码,我的所有子类中的方法二都是方法一调用的方法,是配合方法一的,他们不需要被客户端调用,而且具有一定的保密性,这样使用外观模式时就可以不被客户端知道
在外观模式中,当增加或移除子系统时需要修改外观类,这违背了“开闭原则”。如果引入抽象外观类,则在一定程度上解决了该问题,其结构图如图所示。
本文由 清水河恶霸 创作,如果您觉得本文不错,请随意赞赏
采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名
原文链接:http://ql.magic-seven.top/2020/09/03/设计模式系列18外观模式.html
最后更新:2020-09-03 09:37:23
Update your browser to view this website correctly. Update my browser now