设计模式17-Facade
本文最后更新于:3 years ago
外观模式
外观模式(Facade Pattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于 结构型模式 ,它向现有的系统添加一个接口,来隐藏系统的复杂性。
这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
如果想了解外观模式的具体的介绍,菜鸟教程介绍得比较详细↓
菜鸟教程-外观模式
结构图
优缺点
优点:
1、减少系统相互依赖。
2、提高灵活性。
3、提高了安全性。
缺点:
不符合开闭原则,如果要改东西很麻烦,继承重写都不合适。
使用场景
1、为复杂的模块或子系统提供外界访问的模块。
2、子系统相对独立。
3、预防低水平人员带来的风险。
实现代码
外观模式是向外的,我们知道,一个比较完整的系统,内部是非常复杂的,这种对象之间拥有非常复杂的关系
如果不能合理的处理这些对象之间的关系,那这个系统注定是失败的
这就是我们为什么需要学习设计系统的原因了
而这次我们要介绍的外观模式就是如何解决调用者和系统之间的关系
在这个模式中,调用者不需要知道系统内部是如何复杂,系统只需要一个”接待员”来满足调用者的需求即可
如下图所示:
但是注意Facade和Proxy是不一样的,
Facade: 用于隐藏调用的复杂性
Proxy: 放在服务器端保护被访问的对象
好理解一点就是,Proxy模式你是不能够直接调用它代理的对象的,只能通过代理来调用
而Facade模式则是你可以通过”接待员”来访问,也是可以自己直接去访问
对于用户来讲,Facade是一定可见的,Proxy是不可见的
如果不理解,可以再去仔细看看Proxy模式
介绍的比较清楚了,代码就简单实现一下
简单的需求,一个字母接口,ABC三个类实现这个接口,然后实现接口中method方法
实现完成后,由外观类Facade来为多个类对外提供一个共同的接口
代码如下:
1 |
|
输出结果如下:
1 |
|
Facade用的场景比较多,但这个模式也是比较好理解的,与接下来要介绍的的Mediator模式思想很相似,所以这里就简单介绍一下
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!