外觀模式
定義
外觀模式(Facade Pattern)：爲子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
外觀模式中，一個子系統的外部與其內部的通信通過一個統一的外觀類進行，外觀類將客戶類與子系統的內部複雜性分隔開，使得客戶類只需要與外觀角色打交道，而不需要與子系統內部的很多對象打交道。
場景
現在有一個複雜的系統，有很多子系統或子模塊構成，並且每個子系統和子模塊都可以單獨停止和啓動，但是部分子系統的啓停會導致另一些子系統的啓停，如果把啓停邏輯寫在客戶端，那麼客戶端的代碼可能相當複雜且不好維護。這時候可以使用外觀模式，給所有子系統的啓停都提供相同的外觀，客戶端只需要關心需要操作的具體子系統是哪一個就好了。
UML類圖
代碼
facade
示例：
public class TestFacade {
@Test
public void test() {
new WebServiceController().start();
new WebServiceController().shutdown();
new KafkaServiceController().start();
new KafkaServiceController().shutdown();
}
/*
MySQL server started...
Web server started...
Web server has been shut down...
MySQL server has been shut down...
Zookeeper server started...
Kafka server started...
Kafka server has been shut down...
Zookeeper server has been shut down...
*/
}
總結
感覺和適配器模式的目的有相似之處：都是用已有的代碼去適配一個統一的方法，達到統一管理或一致外觀的目的，但是基於設計來看的話，適配器模式是一對一的適配，而外觀模式可能是一對多的“適配”。
外觀模式屏蔽了子系統，客戶端使用時感覺不到子系統的存在，客戶端不用管理複雜的子系統，子系統內部變化也不會影響到外觀，即使要爲外觀添加新的子系統，客戶端也是沒有感知的；擴展子系統和外觀的時候也不會影響到已有的子系統和外觀。所以外觀模式特別適合使用在那些需要爲複雜的子系統提供一個統一外觀的場景，比如菜單、統一控制、多源聚合等。
外觀模式並不能直接限制客戶端直接使用子系統，當同類子系統存在多個且沒有關聯的時候，可能還需要客戶端傳入子系統，這跟客戶端直接使用子系統沒有多大區別，所以外觀模式的使用還是有一些不可控。當外觀中需要添加新的子系統時，不可避免地需要修改具體外觀類，這也違背了開閉原則。