情景描述
大家都写过纸质信件吧 , 写信大致分为四个步骤 : 先写信件的内容 , 然后写信封 , 再把信放到信封中 , 投递到信箱中进行邮递 . 如图所示 :
代码实现也非常的简单 :
#include<iostream>
#include<string>
//#include<vld.h>
using namespace std;
//门面模式
//写信过程接口
class ILetterProcess
{
public:
//首先要写信的内容
virtual void writeContext(string context) = 0 ;
//其次写信封
virtual void fillEnvelope(string address) = 0 ;
//把信放到信封里
virtual void letterInotoEnvelope() = 0 ;
//然后邮递
virtual void sendLetter() = 0 ;
};
//写信过程的实现
class LetterProcessImpl : public ILetterProcess
{
public:
//写信
void writeContext(string context)
{
cout<<"填写信的内容..."+context<<endl;
}
//在信封上填写必要的信息
void fillEnvelope(string address)
{
cout<<"填写收件人地址及姓名..."+address<<endl;
}
//把信放到信封中 , 并封好
void letterInotoEnvelope()
{
cout<<"把信放到信封中..."<<endl;
}
//塞到邮箱中 , 邮递
void sendLetter()
{
cout<<"邮递信件..."<<endl;
}
};
//场景1
int main()
{
//创建一个处理信件的过程
ILetterProcess* letterProcess = new LetterProcessImpl() ;
//开始写信
letterProcess->writeContext("Hello , It's me , do you know who I am ? I'm you dad . I'd like to ...");
//开始写信封
letterProcess->fillEnvelope("Happy Road No.666 , God Province , Heaven");
//把信放到信封里 , 并封装好
letterProcess->letterInotoEnvelope();
//跑到邮局把信塞到邮箱 , 投递
letterProcess->sendLetter();
delete letterProcess;
return 0;
}
运行结果 :
我们回头来看看这个过程 , 它与高内聚的要求相差甚远 , 更不要说迪米特法则 , 接口隔离原则 . 你要知道者4个步骤 , 而且还要知道他们的顺序 , 一旦出错 , 信就不可能邮寄出去 , 这在面向对象的编程中是极度的不合适 , 它根本没有完成一个类所具有的单一职责 .
还有 , 如果信件多了就非常麻烦 , 每封信都要这样运转一遍 , 非得累死 , 更别说要发个广告信了 , 那怎么办? 还好, 现在邮局开发了一个新业务 , 你只要把信件的必要信息告诉我 , 我给你发 , 我来完成这4个过程 , 只要把信件交给我就成了 , 其他的不要管 .
那么就增加一个ModenPostOffice 类 , 负责对一个比较复杂的信件处理过程的封装 , 然后高层模块只要和它有交互就成了 .
//现代化邮局
class ModenPostOffice
{
public:
ModenPostOffice()
{
letterProcess = new LetterProcessImpl();
}
~ModenPostOffice()
{
if(letterProcess != nullptr)
delete letterProcess;
}
//写信 , 封装 , 投递 ,一体化
void sendLetter(string context , string address)
{
//帮你写信
letterProcess->writeContext(context);
//写好信封
letterProcess->fillEnvelope(address);
//把信放到信封中
letterProcess->letterInotoEnvelope();
//邮递信件
letterProcess->sendLetter();
}
private:
ILetterProcess* letterProcess ;
};
这个类是什么意思呢 , 就是说现在有一个Hell Road PotOffice(地狱路邮局)提供了一种新型服务 , 客户只要把信的内容以及收信地址给他们 , 他们就会把信写好 , 封好 , 并发送出去 .这种服务推出后大受欢迎 , 这多简单 , 客户减少了很多工作 .
完成代码如下 :
#include<iostream>
#include<string>
//#include<vld.h>
using namespace std;
//门面模式
#if 0
//写信过程接口
class ILetterProcess
{
public:
//首先要写信的内容
virtual void writeContext(string context) = 0 ;
//其次写信封
virtual void fillEnvelope(string address) = 0 ;
//把信放到信封里
virtual void letterInotoEnvelope() = 0 ;
//然后邮递
virtual void sendLetter() = 0 ;
};
//写信过程的实现
class LetterProcessImpl : public ILetterProcess
{
public:
//写信
void writeContext(string context)
{
cout<<"填写信的内容..."+context<<endl;
}
//在信封上填写必要的信息
void fillEnvelope(string address)
{
cout<<"填写收件人地址及姓名..."+address<<endl;
}
//把信放到信封中 , 并封好
void letterInotoEnvelope()
{
cout<<"把信放到信封中..."<<endl;
}
//塞到邮箱中 , 邮递
void sendLetter()
{
cout<<"邮递信件..."<<endl;
}
};
//现代化邮局
class ModenPostOffice
{
public:
ModenPostOffice()
{
letterProcess = new LetterProcessImpl();
}
~ModenPostOffice()
{
if(letterProcess != nullptr)
delete letterProcess;
}
//写信 , 封装 , 投递 ,一体化
void sendLetter(string context , string address)
{
//帮你写信
letterProcess->writeContext(context);
//写好信封
letterProcess->fillEnvelope(address);
//把信放到信封中
letterProcess->letterInotoEnvelope();
//邮递信件
letterProcess->sendLetter();
}
private:
ILetterProcess* letterProcess ;
};
//场景2
int main()
{
//现代化邮局 , 有这项服务 , 邮局的名称叫Hell Road
ModenPostOffice* hellRoadPostOffice = new ModenPostOffice();
//你只要把信的内容和收件人的地址给他 , 他会帮你完成一系列的工作
//定义一个地址
string address = "Happy Road No.666 , God Province , Heaven";
//新的内容
string context = "Hello , It's me , do you know who I am ? I'm you dad . I'd like to ...";
//你给我发送吧
hellRoadPostOffice->sendLetter(context,address);
delete hellRoadPostOffice;
return 0;
}
#endif
运行结果 :
门面模式的定义
定义 : 门面模式也叫做外观模式 . 要求一个子系统的外部和其内部的通信必须通过一个统一的对象进行 . 门面模式提供一个高层的接口 , 是的子系统易于所使用 .
扩展后的系统类图 :
- Facade门面角色
客户端可以调用这个角色的方法 . 此角色知晓子系统的所有功能和责任 . 一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就说该角色没有实际的业务逻辑,只是一个委托类 . - subsystem子系统角色
可以同时有一个或者多个子系统 .每一个子系统都不是一个单独的类, 而是一个类的集合 . 子系统并不知道门面的存在 . 对于子系统而言,门面仅仅是另外一个客户端而已 .
门面模式的应用
门面模式的优点
-
减少系统的相互依赖
想想看,如果我们不使用门面模式,外界访问直接深入到子系统内部,相互之间是种强耦合关系,你死我就死,你活我才能活,这样的强依赖是系统设计所不能接受的,门面模式的出现就很好地解决了该问题,所有的依赖都是对门面对象的依赖,与子系统无关 . -
提高了灵活性
依赖减少了,灵活性自然提高了 . 不管子系统内部如何变化,只要不影响到面对象,任你自由活动 . -
提高安全性
想让你访问子系统的哪些业务就开通哪些逻辑,不在门面上开通的方法,你休想访问到
门面模式的缺点
门面模式最大的缺点就是不符合开闭原则,对修改关闭,对扩展开放,看看我们那个门面对象吧,它可是重中之重,一旦在系统投产后发现有一个小错误,你怎么解决?完全遵从开闭原则,根本没办法解决。继承?覆写?都顶不上用,唯一能做的一件事就是修改门面角色的代码,这个风险相当大,这就需要大家在设计的时候慎之又慎,多思考几遍才会有好收获 .
门面模式的是使用场景
- 为一个复杂的模块或子系统提供一个供外界访问的接口
- 子系统相对独立一外界对子系统的访问只要黑箱操作即可
比如利息的计算问题,没有深厚的业务知识和扎实的技术水平是不可能开发出该子系统的,但是对于使用该系统的开发人员来说,他需要做的就是输人金额以及存期,其他的都不用关心,返回的结果就是利息,这时候,门面模式是非使用不可了 . - 预防低水平人员带来的风险扩散
比如一个低水平的技术人员参与项目开发,为降低个人代码质量对整体项目的影响风险,一般的做法是 “画地为牢”,只能在指定的子系统中开发,然后再提供面接口进行访问操作 .
门面模式的注意事项
一个子系统可以有多个门面
一般情况下,一个子系统只要有一个门面足够了,在什么情况下一个子系统有多个门面呢?
以下列举了几个 .
- 门面已经庞大到不能忍受的程度
比如一个纯洁的门面 对象已经超过了200行的代码, 虽然都是非常简单的委托操作,也建议拆分成多个门面,否则会给以后的维护和扩展带来不必要的麻烦。那怎么拆分呢?按照功能拆分是一个非常好的原则,比如一个数据库操作的]面可以拆分为查询面、删除门面、更新门面等。 - 子系统可以提供不同访问路径
ClassA、 ClassB、 ClassC是一个子系统的中3个对象,现在有两个不同的高层模块来访问该子系统,模块一可以完整的访问所有业务逻辑,也就是门面对象,它是子系统的信任模块;而模块二属于受限访问对象,只能访问methodB方法,那该如何处理呢?在这种情况下,就需要建立两个门面以供不同的高层模块来访问 , 在原有的源码上增加一个新的门面即可 .
门面不参与子系统内的业务逻辑
参考书籍 :
<<设计模式之禅 第二版>>
<<设计模式>>