【设计模式】外观模式
外观模式介绍
也叫门面模式,主要解决的是降低调用方的使用接口的复杂逻辑组合。有时候也会被用在中间件层,将服务中的通用性的复杂逻辑进行中间件层包装,让使用方可以只关心业务开发。可增强代码的隔离性,以及复用性。
对于外观模式的使用通常是用在复杂或多个接口进行包装统一对外提供服务上。
说的通俗一点就是:外观模式就是将一些复杂类的众多可供调用的方法或接口进行高度的整合或集成,将其放到一个外部类中,并让其业务方进行调用和使用。
就和上面电话购物一样,调用者只需要知道电话号码即可,其余的交给电话导购员,由她们去确认需要那些货物,如何找到货物,如何发货等细节问题。这里的电话导购员其实就是货物的外观。
外观模式结构
1、外观 提供一种访问特定子系统功能的便捷方式,其了解如何重定向客户端请求,知晓如何操作一切活动部件。
2、创建附加外观 类可以避免多种不相关的功能误解单一外观,使其变成又一个复杂结构。
3、复杂子系统 由数十个不同对象构成。如果要使用这些子系统模块,那么就必须掌握其实现和关联细节,比如正确的调用顺序等。
4、客户端 使用外观代替对子系统对象的直接调用。
需要一个指向复杂子系统的直接接口,且该接口的功能有限,则可以使用外观模式。
实现方式
考虑能否在现有子系统的基础上提供一个更简单的借口。如果该接口能让客户端代码独立于众多子系统类,那么你的方向就是正确的。
在一个新的外观类中声明并实现该接口。外观应将客户端代码的调用重定向到子系统中的相应对象处。如果客户端代码没有对子系统进行初始化,也没有对其后续生命周期进行管理,那么外观必须完成此类工作。
如果要充分发挥这一模式的优势,你必须确保所有客户端代码仅通过外观来与子系统进行交互。此后客户端代码将不会受到任何由子系统代码修改而造成的影响,比如子系统升级后,你只需修改外观中的代码即可。
如果外观过于臃肿,你可以考虑将其部分行为抽取为一个新的专用外观类。
外观模式虽然降低了程序的整体复杂度,但它同时也有助于将不需要的依赖移动到同一位置。
Demo
子系统模块
外观类
客户端
具体代码的流程图
比较来看外观模式还是比较简单也很好理解的一种设计模式,在平常的调用第三方控件或接口的时候经常使用到这种模式,只是我们没有留心观察。它说的简单点就是将一个复杂的系统,对其进行提炼需要的模块或方法,将其整合为一个类的方法中供外部进行调用即可(有时候这个类需要管理其复杂模块或系统的完整生命周期),这样子使用者不需要知道内部类具体要干些什么,他只需要调用这个外部暴露的方法就可以。
小寄语
人生短暂,我不想去追求自己看不见的,我只想抓住我能看的见的。
我是阿辉,感谢您的阅读,如果对你有帮助,麻烦点赞、转发 谢谢。
版权声明: 本文为 InfoQ 作者【Andy阿辉】的原创文章。
原文链接:【http://xie.infoq.cn/article/a0cfd4569b811c6ed793b0974】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论