设计模式之外观模式
定义
外观模式(Facade),为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用。 —— [ 百度百科 ]
解释说明
在外观模式下,当客户端需要子系统为其服务时,不再关心子系统的内部结构以及内部运行原理。只需通过向外观角色传达服务指令,由外观角色直接调用子系统的各种服务,最后只返回给客户端一个最终结果。一句话概括:封装交互,简化调用。
代码块
public class Test {
//外管角色
class FacadeClass{
public void ManAndChildrenSay(){
Man man = new Man();
man.say();
Children children = new Children();
children.say();
}
public void ManAndWomenSay(){
Man man = new Man();
man.say();
Woman woman = new Woman();
woman.say();
}
}
//子系统-男人类
class Man{
public void say(){
System.out.println("我是男人,我劈柴");
}
}
//子系统-女人类
class Woman{
public void say(){
System.out.println("我是女人,我烧饭");
}
}
//子系统-小孩类
class Children{
public void say(){
System.out.println("我是小孩,我撒尿");
}
}
public static void main(String[] args) {
//调用男人和小孩服务
FacadeClass facadeClass = new Test().new FacadeClass();
facadeClass.ManAndChildrenSay();
//调用男人和女人服务
facadeClass.ManAndWomenSay();
}
}
代码解读
以上就是完整的外观模式事例代码。在上述代码中,我们将男人类,女人类,小孩类,类比为不同的子系统。当客户端需要子系统的服务的时候,我们将服务传达给外观角色,由外观角色统一调配子系统的各个服务,最总返回给客户端结果。
正是由于存在了外观角色,客户端无需知道各个子系统的对外暴漏的各个服务,也无需知道子系统的存在与否,这样就减轻了客户端的代码压力,充分体现了设计原则中的迪米特原则(最少知道原则)。
外观角色的存在,一方面减轻了客户端的代码压力,另一方面也提高了代码的可维护性,讲使用方和服务提供方很好分层。例如:当子系统对外暴漏的服务需要修改的时候,我们只需修改外观角色内部的实现,而无需修改客户端的任何代码。
总结
优缺点
- 降低耦合
- 实现简单
- 搭建桥梁,划分层次
- 滥用外观模式只会增加系统的复杂度
试用场景
- 为复杂的子系统提供简单已用的外部服务接口时,可以用外观角色封装复杂的服务调用,为客户端提供简洁明了的外部接口。
- 降低客户端与服务端的耦合度时,可以在两者之间创建外观角色,为两边提供通信服务
- 在系统分层设计中,可以试用外观角色作为底层服务的接入口,简化层级之间的调用关系。