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

前言

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

外观模式

概念介绍

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

举例

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

 

这样两我的都要本身操做茶具，开水，茶叶等，可是其实他俩就是想喝茶，才不关心茶是怎么泡出来的。因此这个时候他们俩就去茶馆了，这样也不用本身动手泡茶了，直接告诉茶馆的店小二儿就好了。此时过程就变成了下面这样的了。

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

先得到饮用水

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();

    }

}

运行结果

可饮用水准备好了
茶杯准备好了
茶叶准备好了。
可饮用水沸腾了
能够泡茶了。
茶叶泡进茶杯了。
等了一下子，一杯又香又浓的茶冲好了。

外观模式的分析

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

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

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

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

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

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

外观模式的优势 

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

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

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

外观模式的缺点

一、不能很好地限制客户端直接使用子系统类，若是对客户端访问子系统类作太多的限制则减小了可变性和灵活性。

二、若是设计不当，增长新的子系统可能须要修改外观类的源代码，违背了开闭原则。

适用场景

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

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

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

延伸

在上面的例子中，咱们定义的门面是一个具体的类，可是当须要增长新的功能的时候，就须要修改门面类了，因此最好的办法是作成抽象门面，也就是将门面类的功能抽象出来，而后又不一样的需求的时候，能够作两个具体的门面类。例如：纪大烟袋跟和二去茶馆喝茶是一个门面类，去上街买东西又是另外一个门面类。

 

 

 

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

 

 

 

 

 

 

 

 

 

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