外观模式

外观模式的图

外观模式使用的条件

在以下情况下可以考虑使用外观模式：
(1)设计初期阶段，应该有意识的将不同层分离，层与层之间建立外观模式。
(2) 开发阶段，子系统越来越复杂，增加外观模式提供一个简单的调用接口。
(3) 维护一个大型遗留系统的时候，可能这个系统已经非常难以维护和扩展，但又包含非常重要的功能，为其开发一个外观类，以便新系统与其交互。

案例

我们来看下面的一个案例：

Facade就像是一个大管家，这种大管家就像是老板的秘书一样，负责老板的各种活动，负责给老板订房间，订机票，给老板订餐。这样来看，房间老板，售票人员，饭店预定处等就是相应的SubSystem类，Boss就是相应的Client端，下面我们来做一下这个简单的案例。

1.外观模式的核心（Facade）---秘书类

public class Secretary {

    public  static void helpBoss(){
        //帮老板订饭店
        Restaurant restaurant = new Restaurant();
        restaurant.bookRestaurant();
        //帮老板订酒店
        HotelServer hotelServer = new HotelServer();
        hotelServer.bookHotel();
        //帮老板订机票
        TicketCerk ticketCerk = new TicketCerk();
        ticketCerk.bookTicket();


    }
}

2.外观模式中的SubSystem类

饭店预定服务人员

public class Restaurant {
   void bookRestaurant(){

       Log.d("testfacade", "已为您预定了房间");
    }
}

酒店预定服务人员

public class HotelServer {

    void bookHotel() {
        Log.d("testfacade", "预定好了房间，还需要特殊服务吗？");


    }
}

机票预定服务人员

public class TicketCerk {

    void bookTicket(){

        Log.d("testfacade", "订机票");

    }
}

3.外观模式中的Client类

public class Boss {
  public   void callSecretary() {
       new Secretary().helpBoss();
    }
}

测试

   private void testFacade() {

        Boss boss = new Boss();
        boss.callSecretary();


    }

结果：

D/testfacade: 以为您预定了大饭店
D/testfacade: 预定好了房间，还需要特殊服务吗？
D/testfacade: 订机票

---

总结:

优点

1. 外观模式是一种比较简单的模式，首先它比较直观，可以看到由一个Facade来统一管理不同的SubSystem类。
2. 通过使用外观模式可以降低不同SubSystem类之间的耦合性

缺点

1. 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码
2. 违背了“开闭原则”。