Java教程

【Java设计模式】Java设计模式之(二十二)外观模式(Facade Pattern)

本文主要是介绍【Java设计模式】Java设计模式之(二十二)外观模式(Facade Pattern),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

这种类型的设计模式属于结构型模式。

一、组合模式介绍

1.1 含义

外观模式(Facade Pattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性。

这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

在日常编码工作中,我们都在有意无意的大量使用外观模式。只要是上层模块需要调度多个子系统(2个以上的类对象),我们都会自觉地创建一个新的类封装这些子系统,提供精简的接口,让上层模块可以更加容易地间接调用这些子系统的功能。

例如现阶段各种第三方SDK、开源类库,很多都会使用外观模式。

1.2 适用场景

① 为复杂的模块或子系统提供外界访问的模块或者接口。

② 子系统相对独立,外界对子系统的访问只要黑箱操作即可。

③ 预防低水平人员带来的风险。

1.3 主要解决

降低访问复杂系统的内部子系统时的复杂度,简化客户端之间的接口。

关键代码:在客户端和复杂系统之间再加一层,这一层将调用顺序、依赖关系等处理好。

1.4 应用实例

① JAVA 的三层开发模式;

② 基金(用户只和基金打交道,实际操作为基金经理人与股票和其它投资品打交道);

③ 去医院看病,可能要去挂号、门诊、划价、取药,让患者或患者家属觉得很复杂,如果有提供接待人员,只让接待人员来处理,就很方便。

④ 最原始的写信,先写信的内容,然后写信封,然后把信放到信封中,封好,投递到信箱中进行邮递;

1.5 优缺点

外观(Facade)模式是“迪米特法则”的典型应用,其优点有:

① 减少系统相互依赖,降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类。

② 提高灵活性,对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易。

③ 提高了安全性,降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程,因为编译一个子系统不会影响其他的子系统,也不会影响外观对象。

缺点:

① 不符合开闭原则,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”,继承重写都不合适。

② 不能很好地限制客户使用子系统类,很容易带来未知风险。

注意事项:在层次化结构中,可以使用外观模式定义系统中每一层的入口。

二、组合模式实现

所有设计模式的代码实现例子都可在码云上查看哦,感兴趣的可以查看哈,码云地址:https://gitee.com/no8g/java-design-patterns

2.1 类图

2.2 角色分析

外观(Facade)角色:为多个子系统对外提供一个共同的接口。

子系统(Sub System)角色:实现系统的部分功能,客户可以通过外观角色访问它。

客户(Client)角色:通过一个外观角色访问各个子系统的功能。

外观(Facade)模式的结构比较简单,主要是定义了一个高层接口。它包含了对各个子系统的引用,客户端可以通过它访问各个子系统的功能。

2.3 代码实现


三、源码分析

暂无,后续再更新!


完结!

这篇关于【Java设计模式】Java设计模式之(二十二)外观模式(Facade Pattern)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!