设计模式之禅之设计模式-门面模式
一:门面模式的定义
--->门面模式(Facade Pattern)也叫做外观模式,是一种比较常用的封装模式
--->要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。
--->门面模式注重“统一的对象”,也就是提供一个访问子系统的接口,除了这个接口不允许有任何访问子系统的行为发生
--->这正是我们设计所需要的模式,不改变子系统对外暴露的接口、方法,只改变内部的处理逻辑,其他兄弟模块的调用产生了不同的结果,确实是一个非常棒的设计。这就是门面模式
二:门面模式的角色
● Facade门面角色
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就说该角色没有实际的业务逻辑,只是一个委托类。
● subsystem子系统角色
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。子系统并不知道门面的存在。对于子系统而言,门面仅仅是另外一个客户端而已。
三:门面模式的应用
门面模式有如下优点
● 减少系统的相互依赖
想想看,如果我们不使用门面模式,外界访问直接深入到子系统内部,相互之间是一种强耦合关系,你死我就死,你活我才能活,这样的强依赖是系统设计所不能接受的,门面模式的出现就很好地解决了该问题,所有的依赖都是对门面对象的依赖,与子系统无关。
● 提高了灵活性
依赖减少了,灵活性自然提高了。不管子系统内部如何变化,只要不影响到门面对象,任你自由活动。
● 提高安全性
想让你访问子系统的哪些业务就开通哪些逻辑,不在门面上开通的方法,你休想访问到。
门面模式有如下缺点
● 门面模式最大的缺点就是不符合开闭原则,对修改关闭,对扩展开放,看看我们那个门对象吧,它可是重中之重,一旦在系统投产后发现有一个小错误,你怎么解决?完全遵从开闭原则,根本没办法解决。继承?覆写?都顶不上用,唯一能做的一件事就是修改门面角色的代码,这个风险相当大,这就需要大家在设计的时候慎之又慎,多思考几遍才会有好收获。
门面模式的使用场景
● 为一个复杂的模块或子系统提供一个供外界访问的接口
● 子系统相对独立——外界对子系统的访问只要黑箱操作即可
比如利息的计算问题,没有深厚的业务知识和扎实的技术水平是不可能开发出该子系统的,但是对于使用该系统的开发人员来说,他需要做的就是输入金额以及存期,其他的都不用关心,返回的结果就是利息,这时候,门面模式是非使用不可了。
● 预防低水平人员带来的风险扩散
比如一个低水平的技术人员参与项目开发,为降低个人代码质量对整体项目的影响风险,一般的做法是“画地为牢”,只能在指定的子系统中开发,然后再提供门面接口进行访问操作。
四:门面模式的注意事项
---> 一个子系统可以有多个门面
● 门面已经庞大到不能忍受的程度
比如一个纯洁的门面对象已经超过了200行的代码,虽然都是非常简单的委托操作,也建议拆分成多个门面,否则会给以后的维护和扩展带来不必要的麻烦。那怎么拆分呢?按照功能拆分是一个非常好的原则,比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等。
● 子系统可以提供不同访问路径
如果A角色,B角色外部系统访问门面C,A角色有权限访问门面C所有的方法,但B角色只有访问门面C一部分方法。则需要新建立一个门面D供B角色使用,而D门面只是代理了门面A,A门面给D门面提供B角色的权限。
--->门面不参与子系统内的业务逻辑
门面不参与子系统内的业务逻辑 ,如果门面内依赖的角色有相互调用的关系,则需要将项目调用的角色封装成一个新的角色,聚合到门面中。
五:门面模式的实战
门面模式是一个很好的封装方法,一个子系统比较复杂时,比如算法或者业务比较复杂,就可以封装出一个或多个门面出来,项目的结构简单,而且扩展性非常好。还有,对于一个较大项目,为了避免人员带来的风险,也可以使用门面模式,技术水平比较差的成员,尽量安排独立的模块,然后把他写的程序封装到一个门面里
六:门面模式的案例
【1】写信的业务类
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 package com.yeepay.sxf.template18; 2 /** 3 * 写信的业务类 4 * 隐藏在门面角色里边,不需要暴露太多 5 * @author sxf 6 * 7 */ 8 public interface ILetterProcess { 9 //写信的内容 10 public void writeContext(String context); 11 //写信的地址 12 public void fillEnvelope(String address); 13 //将信装入信封 14 public void letterInotoEnvelope(); 15 //发送信件 16 public void sendLetter(); 17 }
【2】写信的业务类的实现
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 package com.yeepay.sxf.template18; 2 3 public class LetterProcessImpl implements ILetterProcess{ 4 5 @Override 6 public void writeContext(String context) { 7 System.out.println("LetterProcessImpl.writeContext()写信的内容:"+context); 8 } 9 10 @Override 11 public void fillEnvelope(String address) { 12 // TODO Auto-generated method stub 13 System.out.println("LetterProcessImpl.fillEnvelope()写信的邮寄地址:"+address); 14 } 15 16 @Override 17 public void letterInotoEnvelope() { 18 System.out.println("LetterProcessImpl.letterInotoEnvelope()将信装入信封"); 19 } 20 21 @Override 22 public void sendLetter() { 23 System.out.println("LetterProcessImpl.sendLetter()邮寄信"); 24 } 25 26 27 }
【3】写信的业务类的门面角色
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 package com.yeepay.sxf.template18; 2 /** 3 * 写信的门面角色 4 * 一个人想写信,只需要给这个门面提供相应的参数,后续事件不用关心。 5 * @author sxf 6 * 7 */ 8 public class ModenPostOffce { 9 10 private ILetterProcess letterProcess; 11 12 public ModenPostOffce(ILetterProcess letterProcess){ 13 this.letterProcess=letterProcess; 14 } 15 16 public void sendLetter(String context,String address){ 17 //写信 18 letterProcess.writeContext(context); 19 //写地址 20 letterProcess.fillEnvelope(address); 21 //装信封 22 letterProcess.letterInotoEnvelope(); 23 //发送信件 24 letterProcess.sendLetter(); 25 } 26 }
【4】客户端测试
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 package com.yeepay.sxf.template18; 2 /** 3 * 客户端测试 4 * @author sxf 5 * 6 */ 7 public class ClientTest { 8 9 public static void main(String[] args) { 10 //写信的业务类 11 ILetterProcess letterProcess=new LetterProcessImpl(); 12 //写信业务类的门面类 13 ModenPostOffce modenPostOffce=new ModenPostOffce(letterProcess); 14 //一个人员通过门面写信 15 modenPostOffce.sendLetter("dddsdfdf", "cccccccccc"); 16 } 17 }