设计模式之禅之设计模式-门面模式

一:门面模式的定义
        --->门面模式(Facade Pattern)也叫做外观模式,是一种比较常用的封装模式
        --->要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。
        --->门面模式注重“统一的对象”,也就是提供一个访问子系统的接口,除了这个接口不允许有任何访问子系统的行为发生
        --->这正是我们设计所需要的模式,不改变子系统对外暴露的接口、方法,只改变内部的处理逻辑,其他兄弟模块的调用产生了不同的结果,确实是一个非常棒的设计。这就是门面模式

二:门面模式的角色
        ● Facade门面角色
                客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就说该角色没有实际的业务逻辑,只是一个委托类。
        ● subsystem子系统角色
                可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。子系统并不知道门面的存在。对于子系统而言,门面仅仅是另外一个客户端而已。

三:门面模式的应用

门面模式有如下优点
        ● 减少系统的相互依赖
                想想看,如果我们不使用门面模式,外界访问直接深入到子系统内部,相互之间是一种强耦合关系,你死我就死,你活我才能活,这样的强依赖是系统设计所不能接受的,门面模式的出现就很好地解决了该问题,所有的依赖都是对门面对象的依赖,与子系统无关。
        ● 提高了灵活性
                依赖减少了,灵活性自然提高了。不管子系统内部如何变化,只要不影响到门面对象,任你自由活动。
        ● 提高安全性
                想让你访问子系统的哪些业务就开通哪些逻辑,不在门面上开通的方法,你休想访问到。

门面模式有如下缺点
           ● 门面模式最大的缺点就是不符合开闭原则,对修改关闭,对扩展开放,看看我们那个门对象吧,它可是重中之重,一旦在系统投产后发现有一个小错误,你怎么解决?完全遵从开闭原则,根本没办法解决。继承?覆写?都顶不上用,唯一能做的一件事就是修改门面角色的代码,这个风险相当大,这就需要大家在设计的时候慎之又慎,多思考几遍才会有好收获。

门面模式的使用场景
        ● 为一个复杂的模块或子系统提供一个供外界访问的接口
        ● 子系统相对独立——外界对子系统的访问只要黑箱操作即可
                比如利息的计算问题,没有深厚的业务知识和扎实的技术水平是不可能开发出该子系统的,但是对于使用该系统的开发人员来说,他需要做的就是输入金额以及存期,其他的都不用关心,返回的结果就是利息,这时候,门面模式是非使用不可了。
        ● 预防低水平人员带来的风险扩散
                比如一个低水平的技术人员参与项目开发,为降低个人代码质量对整体项目的影响风险,一般的做法是“画地为牢”,只能在指定的子系统中开发,然后再提供门面接口进行访问操作。

四:门面模式的注意事项
       ---> 一个子系统可以有多个门面
                ● 门面已经庞大到不能忍受的程度
                        比如一个纯洁的门面对象已经超过了200行的代码,虽然都是非常简单的委托操作,也建议拆分成多个门面,否则会给以后的维护和扩展带来不必要的麻烦。那怎么拆分呢?按照功能拆分是一个非常好的原则,比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等。
                ● 子系统可以提供不同访问路径
                        如果A角色,B角色外部系统访问门面C,A角色有权限访问门面C所有的方法,但B角色只有访问门面C一部分方法。则需要新建立一个门面D供B角色使用,而D门面只是代理了门面A,A门面给D门面提供B角色的权限。
        --->门面不参与子系统内的业务逻辑
                门面不参与子系统内的业务逻辑 ,如果门面内依赖的角色有相互调用的关系,则需要将项目调用的角色封装成一个新的角色,聚合到门面中。

五:门面模式的实战        
        门面模式是一个很好的封装方法,一个子系统比较复杂时,比如算法或者业务比较复杂,就可以封装出一个或多个门面出来,项目的结构简单,而且扩展性非常好。还有,对于一个较大项目,为了避免人员带来的风险,也可以使用门面模式,技术水平比较差的成员,尽量安排独立的模块,然后把他写的程序封装到一个门面里

六:门面模式的案例
【1】写信的业务类

 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】写信的业务类的实现

 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】写信的业务类的门面角色

 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】客户端测试

 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 }

时间: 2024-10-07 16:13:16

设计模式之禅之设计模式-门面模式的相关文章

《设计模式之禅》之门面模式

一.门面模式的定义 门面模式也叫外观模式,是一种比较常用的封装模式,其定义如下:要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行.门面模式提供一个高层次的接口,使得子系统更易于使用. 1.Facade门面角色 客户端可以调用这个角色的方法.此角色知晓子系统的所有功能和责任.一般情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去,也就是说该角色没有实际的业务逻辑,只是一个委托类. 2.subsystem子系统角色 可以同时有一个或者多个子系统.每一个子系统都不是一个单独的类,

设计模式之(五)----门面模式【Facade Pattern】

大家都都写过纸质的信件吧,比如给女朋友写情书什么的,写信 的过程大家都还记得吧,先写信的内容,然后写信封,然后把信放到信封中,封好,投递到信箱中进行邮 递,这个过程还是比较简单的,虽然简单,这四个步骤都是要跑的呀,信多了还是麻烦,比如到了情人节, 为了大海捞针,给十个女孩子发情书,都要这样跑一遍,你不要累死,更别说你要发个广告信啥的,一下 子发 1 千万封邮件,那不就完蛋了?那怎么办呢?还好,现在邮局开发了一个新业务,你只要把信件的必 要信息高速我,我给你发,我来做这四个过程,你就不要管了,只要

设计模式之禅之设计模式-桥梁模式

一:桥梁模式定义        --->桥梁模式(Bridge Pattern)也叫做桥接模式,是一个比较简单的模式        --->将抽象和实现解耦,使得两者可以独立地变化. 二:桥梁模式角色 ● Abstraction——抽象化角色        它的主要职责是定义出该角色的行为,同时保存一个对实现化角色的引用,该角色一般是抽象类.● Implementor——实现化角色        它是接口或者抽象类,定义角色必需的行为和属性.● RefinedAbstraction——修正抽象

设计模式之禅之设计模式-访问者模式

一:访问者模式定义        --->封装一些作用于某种数据结构中的各元素的操作,它可以在不改变数据结构的前提下定义作用于这些元素的新的操作. 二:访问者模式角色● Visitor——抽象访问者        抽象类或者接口,声明访问者可以访问哪些元素,具体到程序中就是visit方法的参数定义哪些对象是可以被访问的.● ConcreteVisitor——具体访问者        它影响访问者访问到一个类后该怎么干,要做什么事情.● Element——抽象元素        接口或者抽象类,声

设计模式之禅之设计模式-装饰者模式

一:装饰模式的定义        --->动态地给一个对象添加一些额外的职责.就增加功能来说,装饰模式相比生成子类更为灵活.        --->如果大家还记得代理模式,那么很容易看懂这个类图,装饰类的作用也就是一个特殊的代理类.        --->在装饰模式中,必然有一个最基本.最核心.最原始的接口或抽象类充当Component抽象构件 二:装饰模式的角色        ● Component抽象构件                Component是一个接口或者是抽象类,就是定

设计模式之禅之设计模式-命令模式

一:命令模式的定义        --->命令模式是一个高内聚的模式        --->将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能.        --->命令模式的角色                ● Receive接收者角色==>该角色就是干活的角色,命令传递到这里是应该被执行的                ● Command命令角色==>需要执行的所有命令都在这里声明         

设计模式之禅之设计模式-策略模式

一:策略模式的定义        --->是一种比较简单的模式,也叫做政策模式        --->定义一组算法,将每个算法都封装起来,并且使它们之间可以互换 二:策略模式的三个角色 ● Context封装角色        --->它也叫做上下文角色,起承上启下封装作用,屏蔽高层模块对策略.算法的直接访问,封装可能存在的变化.● Strategy抽象策略角色        --->策略.算法家族的抽象,通常为接口,定义每个策略或算法必须具有的方法和属性● ConcreteStr

设计模式之禅之设计模式-责任链模式

一:责任链模式的定义        --->使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系.将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止.        --->责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请求,并返回相应的结果        --->一般会有一个封装类对责任模式进行封装,也就是替代Client类,直接返回链中的第一个处理者,具体链的设置不需要高层次模块关系,这样,更简化了高层次模块的调用,减

设计模式之禅之设计模式-享元模式

一:享元模式定义        --->享元模式(Flyweight Pattern)是池技术的重要实现方式        --->使用共享对象可有效地支持大量的细粒度的对象        --->要求细粒度对象,那么不可避免地使得对象数量多且性质相近,那我们就将些对象的信息分为两个部分:内部状态(intrinsic)与外部状态(extrinsic).                ● 内部状态                        内部状态是对象可共享出来的信息,存储在享元对象