2.5 Facade
想想我们小时候玩的四驱车,里面的构造很复杂,马达,舵机,电池组等等,而我们控制它却非常简单,只要打开电池开关,他就可以跑。我们其实不用知道它里面是如何工作,只要知道拨动开关它就可以工作就行了,这个开关其实就四驱车给我们的一个友好的组件,使得我们可以很方便的控制它。外观模式其实定义了一个高层接口,该接口为子系统中的一组接口提供一个一致的界面,使得这一子系统更加容易使用。
思想:为子系统中的一组接口提供一个一致的界面,这个接口使得这一子系统更加容易使用。
1.Facade模式对客户屏蔽了子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2.Facade模式实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变
化不会影响到它的客户。
3.如果应用需要,它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。
4. 在外观模式中,通常只需要一个外观类,并且此外观类只有一个实例,换言之它是一个单例类。当然这并不意味着在整个系统里
只能有一个外观类,而仅仅是说对每一个子系
统只有一个外观类。或者说,如果一个系统有好几个子系统的话,每一个子系统有一个外观类,整个系统可以有数个外观类。
5. 外观模式的用意是为子系统提供一个集中化和简化的沟通管道,而不建议向子系统加入新的行为。
6. 外观模式注重的是简化接口,它更多的时候是从架构的层次去看整个系统,而并非单个类的层次。
适用性:
1.为一个复杂子系统提供一个简单接口。
2.提高子系统的独立性。
3.在层次化结构中,可以使用Facade模式定义系统中每一层的入口。
优点:
1. 松散耦合
外观模式松散了客户端与子系统的耦合关系,让子系统内部的模块能更容易扩展和维护。
2. 简单易用
外观模式让子系统更加易用,客户端不再需要了解子系统内部的实现,也不需要跟众多子系统内部的模块进行交互,只需要跟外观
交互就可以了,相当于外观类为外部客户端使用子系统提供了一站式服务。
3. 更好的划分访问层次
通过合理使用Facade,可以帮助我们更好的划分访问的层次。有些方法是对系统外的,有些方法是系统内部使用的。把需要暴露
给外部的功能集中到外观中,这样既方便客户端使用,也很好的隐藏了内部的细节。
缺点:
过多的或者是不太合理的Facade也容易让人迷惑,到底是调用Facade好呢,还是直接调用模块好。
场景:将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互
依赖关系达到最小。达到该目标的途径之一是就是引入一个外观(Facade)对象,它为子系统中较一般的设施提供了一个单一而简
单的界面。将各个子系统整合起来作为Facade,提供给客户端使用。当你要为一个复杂子系统提供一个简单接口时,子系统往往因为
不断演化而变得越来越复,大多数模式使用时都会产生更多更小的类,这使得子系统更具可重用性,也更容易对子系统进行定制,但
这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图,这一视图对大多数用户来说已
经足够,而那些需要更多的可定制性的用户可以越过Facade层。客户程序与抽象类的实现部分之间存在着很大的依赖性。引入
Facade将这个子系统与客户以及其他的子系统分离,可以提高子系统的独立性和可移植性。当你需要构建一个层次结构的子系统
时,使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过Facade进行通讯,从而简化
了它们之间的依赖关系。
实现:以文件系统为例,文件系统是一个独立的系统,它提供一套核心的文件操作。除了文件系统,还有四个子系统,分别是杀毒
子系统(KillVirus),压缩子系统(ZipFile),加密子系统(EncrypeFile)和刻录子系统(BurnCD),这四个子系统相互独立,但又可以做为主
系统功能的一部分。假设客户需要我这个文件系统有两种执行模式,一种是完全模式,一种是简单模式。完全模式,要求杀毒子,压
缩,加密和刻录功能都有。简单模式,要求只要有杀毒,刻录就行了。
第一种设计:
文件系统自己管理所有的子系统,并实现客户的需求。
最开始的话,我们是按上面的结构来设计的,这个文件系统(FileSys)就要自己管理和组织上面的四个子系统。问题是子系统变化比较
多,特别是重构之后,接口也变了,这时也要相应的修改这个文件系统。最麻烦的是,有时一个子系统要分离出好多小类,这对子系
统是好事,但是对FileSys来说,调用越来越复杂和困难了。这种设计的问题是:文件系统和子系统耦合性太高了!
第二种设计:
后来我们独立出一个中间层,由中间层来统一管理这些子系统,并对外提供相对简单的接口,使它们之间减少依赖。
代码实现:
- //杀毒
- class KillVirus
- {
- public:
- void Operation1() { cout<<"杀毒"<<endl; }
- };
- //压缩
- class ZipFile
- {
- public:
- void Operation2() { cout<<"压缩"<<endl; }
- };
- //加密
- class EncryptFile
- {
- public:
- void Operation3() { cout<<"加密"<<endl; }
- };
- //刻录
- class BurnCD
- {
- public:
- void Operation4() { cout<<"刻录"<<endl;}
- };
- //高层接口
- class OperatorWapper
- {
- public:
- //完全功能
- void MethodA()
- {
- KillVirus kill;
- ZipFile zip;
- EncryptFile encrypt;
- BurnCD burn;
- kill.Operation1();
- zip.Operation2();
- encrypt.Operation3();
- burn.Operation4();
- }
- //简单功能
- void MethodB()
- {
- KillVirus kill;
- BurnCD burn;
- kill.Operation1();
- burn.Operation4();
- }
- };
- //测试代码
- int main()
- {
- OperatorWapper op;
- op.MethodA();//完全功能
- op.MethodB();//简单功能
- return 0;
- }
外观模式实现:为子系统中的一组接口提供一个一致的界面, 外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
说明:
1. 在设计初期,应该有意识的将不同层分离,比如常用的三层架构,就是考虑在数据访问层,业务逻辑层与表示层之间,建立Facade,使复杂的子系统提供一个简单的接口,降低耦合性。
2. 在开发阶段,子系统往往因为不断的重构而变的越来越复杂,增加外观Facade可以提供一个简单的接口,减少它们之间的依赖。
重构成本:高。要修改所有直接对子系统的地调用为对Façade层的调用还是有很多事情要做的。不过,现代IDE中,如果我们删除调
用层对子系统的程序集引用,那么所有这些我们需要修改的调用都能标示出来,因为编译不能通过了嘛,因此,重构的风险还不算特
别大,只是工作量着实不小。