设计模式之外观模式-与单一职责的PK（Facade）

问题

在我的电脑城里，为了提高效率，专门设有销售人员，收银人员，组装人员，打包人员等等。客户进来购买电脑的时候，先找销售人员，确定好组装配件，销售人员将单子给到客户，让客户拿着单子到收银人员买单，再让客户拿着收银单到组装人员那里去做配件组装。。。听起来很流畅，效率很高。但是呢，客户不高兴了，说：把你们老板给我叫出来，对着我就是一顿骂：你这老板怎么回事，我就买个电脑，你让我从这跑到那，再跑到那，累都累死了，你就这么对待上帝的嘛。我这么一想，确实是不行啊，怎么能让顾客来回跑呢。那我就使用外观模式来解决客户问题啊！

简介

外观模式如何解决此问题呢？其实生活中有非常典型的例子就是银行，银行的柜台人员就是外观，客户所有的需求都通过柜台，柜台人员执行诸多操作后，完成客户需求，而客户完全不关心执行过程。

学习外观模式时，我的第一反应其实是外观模式完全是给SDK量身定做的。了解Android开发的同学应该知道，一个Android应用一般都会使用很多开源库或商业SDK，而SDK基本上都会有一个manager类，提供初始化方法及若干个使用的方法，使用者通过manager类使用SDK的功能，而其内部实现使用者几乎完全不需要知道。所以说SDK的设计理念完全贴合外观模式。

使用场景：使用者只需要使用复杂系统的若干功能，而不关心内部实现逻辑

实现方式：增加外观类，负责使用者和复杂系统之间所有的交互

解决问题：杜绝使用者直接调用子系统的操作，减少复杂性

实现

先定义顾客

public class Custom {
    public void buy(String demand, int amount) {
        //分配接待经理给到顾客，并且帮顾客购买电脑
        Manager manager = new Manager();
        manager.buy(demand, amount);
    }
}

定义接待经理

public class Manager {

    public void buy(String demand, int amount) {
        System.out.println(demand);
        Cashier cashier = new Cashier();
        cashier.collectMoney(amount);
        Salesman salesman = new Salesman();
        salesman.sale();
        Packer packer = new Packer();
        packer.pack();
        System.out.println("manager get the computer and give to custom");
    }
}

定义其他相关人员

public class Cashier {

    public void collectMoney(int amount) {
        System.out.println("cashier collect money " + amount + "and tell the manager");
    }
}

public class Salesman {

    public void sale() {
        System.out.println("salesman give computer parts to manager");
    }
}

public class Packer {

    public void pack() {
        System.out.println("packer pack the computer and give to manager");
    }
}

执行类

    public static void main(String[] args) {
        Custom custom = new Custom();
        custom.buy("i want to get a computer to play games", 10000);
    }

执行结果

i want to get a computer to play games
cashier collect money 10000and tell the manager
salesman give computer parts to manager
packer pack the computer and give to manager
manager get the computer and give to custom

简化了了购买流程，可以看到顾客只需要和接待经理交互即可，对于顾客来说简单清晰。

总结

外观模式非常容易理解，并且优势也是显而易见。但是呢，需要提出一个问题就是，在现实中，有银行柜台人员作为外观去处理顾客所有诉求，也有医院需要病人进行挂号，问诊，付费，取药等等一系列步骤，却没有采用外观模式。为何呢？我觉得主要是因为外观模式其实是违反了单一职责原则，外观类将所有子系统的操作封装成统一出口给到调用者，大概率会出现外观类逐渐膨胀复杂的情况。

采用外观模式，还是不违反单一职责，我觉得取决于两点，一是复杂系统的应用场景，二是对于使用者的友好性。第一点来说：复杂系统希望对于使用者来说是一个黑盒（SDK等），使其关注于使用，而不是实现。第二点就是：该系统希望给到使用者最有好的使用体验。在以上两种情况来说，是可以牺牲单一职责原则，而使用外观模式的。就卖电脑举例来说，我当然是希望接待经理辛苦一点，而给到顾客最舒服的购物体验，以此提高顾客的回头率，银行也是如此。而对于医院来说，为了管理效率（单一职责），我可以稍微牺牲病人的看病体验，因为这并不会影响医院的病人数量。（私立医院除外，私立医院类似银行）