设计模式-10-外观模式
外观模式
- 外观模式隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口
属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性。
这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
意图:为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
主要解决:降低访问复杂系统的内部子系统时的复杂度,简化客户端之间的接口。
如何解决:客户端不与系统耦合,外观类与系统耦合。
关键代码:在客户端和复杂系统之间再加一层,这一层将调用顺序、依赖关系等处理好。
优点:
- 减少系统相互依赖
- 提高灵活性
- 提高了安全性。
缺点:
不符合开闭原则,如果要改东西很麻烦,继承重写都不合适。
使用场景:
- 为复杂的模块或子系统提供外界访问的模块
- 子系统相对独立
注意事项:在层次化结构中,可以使用外观模式定义系统中每一层的入口。
案例说明
将创建一个 Shape 接口和实现了 Shape 接口的实体类。下一步是定义一个外观类 ShapeMaker。
ShapeMaker 类使用实体类来代表用户对这些类的调用。FacadePatternDemo 类使用 ShapeMaker 类来显示结果。
1.创建一个接口
1 | public interface Shape { |
2.创建实现接口的实体类
1 | public class Rectangle implements Shape { |
3.创建一个外观类
1 | public class ShapeMaker { |
4.使用该外观类画出各种类型的形状
1 | public class FacadePatternDemo { |
注意事项
- 外观模式对外屏蔽了子系统的细节,因此外观模式降低了客户端对子系统使用的复杂性
- 外观模式对客户端与子系统的耦合关系 - 解耦,让子系统内部的模块更易维护和扩展
- 通过合理的使用外观模式,可以帮我们更好的划分访问的层次
- 当系统需要进行分层设计时,可以考虑使用 Facade 模式
- 在维护一个遗留的大型系统时,可能这个系统已经变得非常难以维护和扩展,此时可以考虑为新系统开发一个Facade 类,来提供遗留系统的比较清晰简单的接口,让新系统与 Facade 类交互,提高复用性
- 不能过多的或者不合理的使用外观模式,使用外观模式好,还是直接调用模块好。要以让系统有层次,利于维护为目的
All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.
Comment