前面介绍的适配器模式讲的是如何将一个接口转换成客户所需要的另一个接口,它的目的在于解决接口的不兼容性问题。现在这里有这样一个模式,它的目的在于如何简化接口,它可以将多个类的复杂的一切隐藏在背后,只显露出一个干净美观的外观。
以化妆举例:女生化妆的过程水、乳、霜、隔离、粉底、眉毛、眼妆、口红、腮红、定妆喷雾,卸妆时要卸眼妆、卸口红、卸全脸粉底、洗脸、敷面膜、水、乳、霜。过程好繁琐呀,如果能开发一套程序,能一键上妆,一键卸妆就好了。。。。
一:定义
外观模式(Facade Pattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性。
外观类为包含许多活动部件的复杂子系统提供一个简单的接口。 与直接调用子系统相比, 外观提供的功能可能比较有限, 但它却包含了客户端真正关心的功能。
如果你的程序需要与包含几十种功能的复杂库整合, 但只需使用其中非常少的功能, 那么使用外观模式会非常方便。
二:应用场景
1、当要为一个复杂子系统提供一个简单接口时可以使用外观模式。
2、客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦,可以提高子系统的独立性和
可移植性
三:UML
四:简单代码实现
五:优点
1、引入外观模式,是客户对子系统的使用变得简单了,减少了与子系统的关联对象,实现了子系统与客户之间的松耦合关系。
2、只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类
3、降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程
六:缺点
1、不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性
2、在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”
七:模式总结
1、 外观模式的主要优点就在于减少了客户与子系统之间的关联对象,使用客户对子系统的使用变得简单了,也实现了客户与子
系统之间的松耦合关系。它的缺点就在于违背了“开闭原则”。
2、 如果需要实现一个外观模式,需要将子系统组合进外观中,然后将工作委托给子系统执行。