一天一種設計模式之十一-----外觀模式

一.外觀模式簡介

1. 外觀模式屬於結構型模式。

2. 外觀模式爲子系統中的一組接口提供了一個一致的界面，外觀模式定義了一個高層接口，這個接口使得子系統更加容易使用。

3. 當你要爲一個複雜的系統提供一個簡單的接口時，子系統每每由於不斷演化而變的愈來愈複雜。大多數模式使用時都會產生更多更小的類。這使得子系統更具備可重用性，更容易對子系統進行定製，但這也會給那些不須要定製子系統的用戶帶來一些使用上的困難。

4. 外觀模式爲了解決3的痛點，提供了一個簡單的缺省視圖，這一視圖對大多數用戶來講已經足夠，而那些須要更多的可定製性的用戶能夠越過外觀層。

5. 客戶程序與抽象類的實現部分存在着很大的依賴性，引入外觀模式能夠將這個子系統與客戶以及其餘子系統分離，能夠提升子系統的獨立性和可移植性。

6. 優勢：

1. 引入外觀模式，客戶對子系統的使用變得簡單了。減小了與子系統的關聯對象，實現了子系統與客戶之間的鬆耦合。

2. 只是提供了一個訪問子系統的統一入口，並不影響用戶直接使用子系統類

3. 下降了大型軟件系統中的編譯依賴性，並簡化了系統在不一樣平臺之間的移植過程。

7. 缺點：

1. 不能很好的限制客戶使用子系統類，若是堆客戶訪問子系統作太多的限制則減小了靈活性和可變性。

2. 在不引入抽象外觀類的狀況下，增長新的子系統可能須要修改外觀類或客戶端的源碼，違背了開閉原則。

8. 我的感受，外觀類只不過把具體的業務邏輯模塊化了，這樣的聚合在層次鮮明，耦合自己比較低或者邏輯流程比較統一的業務中值得考慮，但但業務流轉的太複雜有可能致使父系統上面又聚合父系統，這樣層次關係會很亂。因此這種模式不值得在複雜多變的邏輯處理中推薦。
   

二.測試代碼

public class WaiguanMoshiTest {
    public static void main(String[] args) {
        Facade facade=new Facade();
        facade.methodA();
        facade.methodB();
    }
}
interface ServiceA{
    void methodA();
}
interface ServiceB{
    void methodB();
}
interface ServiceC{
    void methodC();
}
class ServiceAimpl implements ServiceA{

    @Override
    public void methodA() {
        System.out.println("服務a");
    }
    
}
class ServiceBimpl implements ServiceB{

    @Override
    public void methodB() {
        System.out.println("服務b");
    }
    
}
class ServiceCimpl implements ServiceC{

    @Override
    public void methodC() {
        System.out.println("服務c");
    }
    
}
class Facade{
    ServiceA serviceA;
    ServiceB serviceB;
    ServiceC serviceC;
    public Facade(){
        serviceA=new ServiceAimpl();
        serviceB=new ServiceBimpl();
        serviceC=new ServiceCimpl();
    }
    public void methodA(){
        serviceA.methodA();
        serviceB.methodB();
    }
    public void methodB(){
        serviceB.methodB();
        serviceC.methodC();
    }
    public void methodC(){
        serviceC.methodC();
        serviceA.methodA();
    }
}