Java设计模式学习记录-外观模式

前言

这次要介绍的是外观模式（也称为门面模式），外观模式也属于结构型模式，其实外观模式还是非常好理解的，简单的来讲就是将多个复杂的业务封装成一个方法，在调用此方法时可以不必关系具体执行了哪些业务，而只关心结果即可。这个场景其实在日常开发中使用的频率还是非常高的，下面来简单了解一下吧。

外观模式

概念介绍

外观模式是隐藏了系统的复杂性，能够为子系统中的一组接口提供一个统一的接口。客户在使用系统时不必和子系统打交道了，降低了客户和子系统间的耦合。

举例

喝茶问题，当纪大烟袋跟和二想喝茶了，这个时候他们就会自己动手，拿茶具，开水，茶叶然后就把茶泡了。过程如下图。

 

这样两个人都要自己操作茶具，开水，茶叶等，但是其实他俩就是想喝茶，才不关心茶是怎么泡出来的。所以这个时候他们俩就去茶馆了，这样也不用自己动手泡茶了，直接告诉茶馆的店小二儿就行了。此时过程就变成了下面这样的了。

下面用代码来实现一下这个过程：

先获得饮用水

public class DrinkableWater {

    public DrinkableWater(){
        System.out.println("可饮用水准备好了");
    }

    //煮水
    public void facadeWater(){
        System.out.println("可饮用水沸腾了");
    }
}

再获得茶叶

public class Tea {

    public Tea(){
        System.out.println("茶叶准备好了。");
    }

    //取茶
    public void facadeTea(){
        System.out.println("可以泡茶了。");
    }

}

然后获得茶杯就可以泡茶了。

public class TeaCup {


    public TeaCup(){
        System.out.println("茶杯准备好了");
    }

    //泡茶
    public void facadeTeaCup(Tea tea){

        tea.facadeTea();
        System.out.println("茶叶泡进茶杯了。");
        System.out.println("等了一会儿，一杯又香又浓的茶冲好了。");
    }
}

店小二泡茶

public class Waiter {

    private DrinkableWater drinkableWater = new DrinkableWater();
    private TeaCup teaCup = new TeaCup();
    private Tea tea = new Tea();

    //获得一杯茶
    public void getTea(){

        drinkableWater.facadeWater();
        teaCup.facadeTeaCup(tea);

    }

}

顾客来喝茶了

public class Customer {

    public static void main(String[] args) {

        //叫店小二
        Waiter waiter = new Waiter();
        //从店小二那获得一杯茶
        waiter.getTea();

    }

}

运行结果

可饮用水准备好了
茶杯准备好了
茶叶准备好了。
可饮用水沸腾了
可以泡茶了。
茶叶泡进茶杯了。
等了一会儿，一杯又香又浓的茶冲好了。

外观模式的分析

 外观模式的抽象结构图如下：

在外观模式中主要包含如下几个角色。

1、门面角色（facade）:这是外观模式的核心。它被客户角色调用，因此它熟悉子系统的功能。它内部根据客户角色已有的需求预定了几种功能组合。

2、子系统角色（SystemA、SystemB、SystemC）:实现了子系统的功能。对子系统角色来说，facade角色与客户角色一样，是未知的，它没有任何facade角色的信息和链接。

3、客户角色（client）：调用facade角色来完成要得到的功能。

在上面的泡茶的例子中，和二和纪大烟袋就是客户角色，茶馆店小二儿就是门面角色，茶具、饮用水、茶叶就是子系统角色。

外观模式的优点 

1、对客户端屏蔽了子系统组件，减少了客户端处理的对象数量，也减少了客户端的代码量。

2、实现了客户端和子系统的松散耦合，使得子系统个变化不会影响到调用它的客户端，只需要改变外观类即可。

3、一个子系统的变化不会影响到另一个子系统，子系统内部变化也不会影响到外观对象。

外观模式的缺点

1、不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。

2、如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

适用场景

当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。

客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

延伸

在上面的例子中，我们定义的门面是一个具体的类，但是当需要增加新的功能的时候，就需要修改门面类了，所以最好的办法是做成抽象门面，也就是将门面类的功能抽象出来，然后又不同的需求的时候，可以做两个具体的门面类。例如：纪大烟袋跟和二去茶馆喝茶是一个门面类，去上街买东西又是另一个门面类。

 

 

 

想了解更多的设计模式请查看Java设计模式学习记录-GoF设计模式概述。

 

 

 

 

 

 

 

 

 

我不慌，世界就不慌。加油吧！