http://blog.csdn.net/lwbeyond/article/details/7564162
一. 举例说明
还以我以前做的文件系统(FileSys)为例:
文件系统是一个独立的系统,它提供一套核心的文件操作。
除了文件系统,还有四个子系统,分别是杀毒子系统(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可以提供一个简单的接口,减少它们之间的依赖。
3. 在维护阶段,可能这个系统已经非常难以维护和扩展了,此时你可以为新系统开发一个外观类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,让新系统与Facade对象交互,Facade与遗留代码交互所有复杂的工作。
==========================
不知道大家有没有比较过自己泡茶和去茶馆喝茶的区别,如果是自己泡茶需要自行准备茶叶、茶具和开水,如图1(A)所示,而去茶馆喝茶,最简单的方式就是跟茶馆服务员说想要一杯什么样的茶,是铁观音、碧螺春还是西湖龙井?正因为茶馆有服务员,顾客无须直接和茶叶、茶具、开水等交互,整个泡茶过程由服务员来完成,顾客只需与服务员交互即可,整个过程非常简单省事,如图1(B)所示。图1 两种喝茶方式示意图
在软件开发中,有时候为了完成一项较为复杂的功能,一个客户类需要和多个业务类交互,而这些需要交互的业务类经常会作为一个整体出现,由于涉及到的类比较多,导致使用时代码较为复杂,此时,特别需要一个类似服务员一样的角色,由它来负责和多个业务类进行交互,而客户类只需与该类交互。外观模式通过引入一个新的外观类(Facade)来实现该功能,外观类充当了软件系统中的“服务员”,它为多个业务类的调用提供了一个统一的入口,简化了类与类之间的交互。在外观模式中,那些需要交互的业务类被称为子系统(Subsystem)。如果没有外观类,那么每个客户类需要和多个子系统之间进行复杂的交互,系统的耦合度将很大,如图2(A)所示;而引入外观类之后,客户类只需要直接与外观类交互,客户类与子系统之间原有的复杂引用关系由外观类来实现,从而降低了系统的耦合度,如图2(B)所示。图2 外观模式示意图
外观模式没有一个一般化的类图描述,通常使用如图2(B)所示示意图来表示外观模式。图3所示的类图也可以作为描述外观模式的结构图:图3 外观模式结构图
由图3可知,外观模式包含如下两个角色:
- Facade(外观角色):在客户端可以调用它的方法,在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任;在正常情况下,它将所有从客户端发来的请求委派到相应的子系统去,传递给相应的子系统对象处理。
- SubSystem(子系统角色):在软件系统中可以有一个或者多个子系统角色,每一个子系统可以不是一个单独的类,而是一个类的集合,它实现子系统的功能;每一个子系统都可以被客户端直接调用,或者被外观角色调用,它处理由外观类传过来的请求;子系统并不知道外观的存在,对于子系统而言,外观角色仅仅是另外一个客户端而已。
class SubSystemA
{
public void MethodA()
{
//业务实现代码
}
}
class SubSystemB
{
public void MethodB()
{
//业务实现代码
}
}
class SubSystemC
{
public void MethodC()
{
//业务实现代码
}
}
class Facade
{
private SubSystemA obj1 = new SubSystemA();
private SubSystemB obj2 = new SubSystemB();
private SubSystemC obj3 = new SubSystemC();
public void Method()
{
obj1.MethodA();
obj2.MethodB();
obj3.MethodC();
}
}
class Program
{
static void Main(string[] args)
{
Facade facade = new Facade();
facade.Method();
}
}