门面模式

转载请注明出处!!!http://blog.csdn.net/zhonghuan1992

         所有配套代码均在github上:https://github.com/ZHONGHuanGit/DesignPattern

 

 

 

跟着ZHONGHuan学习设计模式

门面模式

 

 

 

 

 

       GOF95是这样描述门面模式的,外部与子系统进行通信必须通过一个统一的门面(Facade)对象进行,这就是门面模式

      

       我们暂时先不说门面模式,先从一个例子开始入手。(以下内容来自《java与模式》一书,因为例子不错,就用这个了)。这个例子是关于医院的(例子图片和内容取自这里,http://www.cnblogs.com/java-my-life/archive/2012/05/02/2478101.html)。

    现代的软件系统都是比较复杂的,设计师处理复杂系统的一个常见方法便是将其“分而治之”,把一个系统划分为几个较小的子系统。如果把医院作为一个子系统,按照部门职能,这个系统可以划分为挂号、门诊、划价、化验、收费、取药等。看病的病人要与这些部门打交道,就如同一个子系统的客户端与一个子系统的各个类打交道一样,不是一件容易的事情。

  首先病人必须先挂号,然后门诊。如果医生要求化验,病人必须首先划价,然后缴费,才可以到化验部门做化验。化验后再回到门诊室。如图:

门面模式_第1张图片

     上图描述的是病人在医院里的体验,图中的方框代表医院。

  解决这种不便的方法便是引进门面模式,医院可以设置一个接待员的位置,由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是门面模式的体现,病人只接触接待员,由接待员与各个部门打交道。个人觉得未来我们的医院就应当省去那些烦人的工作,多余的工作是不用做的。我觉得以前的社会需要挂号理解,现在真的可以不用挂好了吧,你在电脑上写,不更方便么,而且字大家还看得懂,大部分医生的字,不敢恭维。

门面模式_第2张图片

       下面看下门面模式的结构,从结构和代码中体会门面模式。

门面模式的结构

  门面模式没有一个一般化的类图描述,最好的描述方法实际上就是以一个例子说明。

门面模式_第3张图片

       由于门面模式的结构图过于抽象,因此把它稍稍具体点。假设子系统内有三个模块,分别是ModuleA、ModuleB和ModuleC,它们分别有一个示例方法,那么此时示例的整体结构图如下:

门面模式_第4张图片

       在这个对象图中,出现了两个角色:

  ●  门面(Facade)角色 :客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去。

  ●  子系统(SubSystem)角色 :可以同时有一个或者多个子系统。每个子系统都不是一个单独的类,而是一个类的集合(如上面的子系统就是由ModuleAModuleBModuleC三个类组合而成)。每个子系统都可以被客户端直接调用,或者被门面角色调用。子系统并不知道门面的存在,对于子系统而言,门面仅仅是另外一个客户端而已。

 

代码的实现

class ModuleA {
    //示意方法
    public void doFirst(){
        System.out.println("完成第一步");
    }
}

class ModuleB {
    //示意方法
    public void doSecond(){
        System.out.println("KO第二步");
    }
}

class ModuleC{
	public void doThird(){
		System.out.println("第三步,杀了");
	}
}
//门面类角色
class Facade {
    //示意方法,满足客户端需要的功能
    public void doSth(){
        ModuleA a = new ModuleA();
        a.doFirst();
        ModuleB b = new ModuleB();
        b.doSecond();
        ModuleC c = new ModuleC();
        c.doThird();
		System.out.println("测试结束");
    }
}
//客户端角色
public class Client{
	public static void  main(String[] args){
		Facade tem = new Facade();
		tem.doSth();
	}
}


        Facade类其实相当于A、B、C模块的外观界面,有了这个Facade类,那么客户端就不需要亲自调用子系统中的A、B、C模块了,也不需要知道系统内部的实现细节,甚至都不需要知道A、B、C模块的存在,客户端只需要跟Facade类交互就好了,从而更好地实现了客户端和子系统中A、B、C模块的解耦,让客户端更容易地使用系统。

       同理,如果ABC等是一个子系统,可以给它们也设置一个门面类,屏蔽内部的细节。

       就是说一个系统可以有几个门面,对外一个大门面,内部还有一些门面,

门面模式的优点

  ●  松散耦合

  门面模式松散了客户端与子系统的耦合关系,让子系统内部的模块能更容易扩展和维护。

  ●  简单易用

  门面模式让子系统更加易用,客户端不再需要了解子系统内部的实现,也不需要跟众多子系统内部的模块进行交互,只需要跟门面类交互就可以了。

  ●  更好的划分访问层次

  通过合理使用Facade,可以帮助我们更好地划分访问的层次。有些方法是对系统外的,有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中,这样既方便客户端使用,也很好地隐藏了内部的细节。

 

门面模式和迪米特法则

       还记得迪米特法则吗?忘了可以回顾一下(http://blog.csdn.net/zhonghuan1992/article/details/38358183,),迪米特法则说,不要和陌生人说话,只要可能,朋友还是少点好,而门面模式就是这样的,因为你只和一个门面Façade打过交道。把你需要打交道的朋友数量降低到最少,使得你和系统内部对象交互被门面取代。所以门面模式很好的达到了迪米特法则的要求。

 

 

 

 

 

你可能感兴趣的:(设计模式,Pattern,Facade,门面模式)