外觀模式及php實現

外觀模式：
　　外觀模式(Facade Pattern)：外部與一個子系統的通信必須通過一個統一的外觀對象進行，為子系統中的一組介面提供一個一致的界面，外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。外觀模式又稱為門面模式，它是一種對象結構型模式。

目的：
　　1、為一個複雜子系統提供簡單的介面
　　2、減少客戶端和子系統的耦合

外觀模式包含如下角色：
　　Facade: 外觀角色
　　SubSystem:子系統角色

UML圖：

代碼實現：

header("Content-type:text/html;Charset=utf-8");

//子系統角色
class SubSystemOne{
   function mothedOne(){
       echo "方法一<br>";
   }
}
class SubSystemTwo{
   function mothedTwo(){
       echo "方法二<br>";
   }
}
class SubSystemThree{
   function mothedThree(){
       echo "方法三<br>";
   }
}

//外觀角色
class Facade{
    private $subSystemOne = null;
    private $subSystemTwo = null;
    private $subSystemThree =null;

    function __construct(){
        $this->subSystemOne =new SubSystemOne();
        $this->subSystemTwo =new SubSystemTwo();
        $this->subSystemThree =new SubSystemThree();
    }

    function mothedA(){
        $this->subSystemOne->mothedOne();
    }
    function mothedB(){
        $this->subSystemTwo->mothedTwo();
    }
    function mothedC(){
        $this->subSystemThree->mothedThree();
    }
    function mothedD(){
        $this->subSystemOne->mothedOne();
        $this->subSystemTwo->mothedTwo();
        $this->subSystemThree->mothedThree();
    }
}

//測試
$facade = new Facade();
$facade->mothedA();
$facade->mothedB();
$facade->mothedC();
$facade->mothedD();
/*
方法一
方法二
方法三
方法一
方法二
方法三
*/

模式分析:
　　根據“單一職責原則”，在軟體中將一個系統劃分為若幹個子系統有利於降低整個系統的複雜性，一個常見的設計目標是使子系統間的通信和相互依賴關係達到最小，而達到該目標的途徑之一就是引入一個外觀對象，它為子系統的訪問提供了一個簡單而單一的入口
　　外觀模式也是“迪米特法則”的體現，通過引入一個新的外觀類可以降低原有系統的複雜度，同時降低客戶類與子系統類的耦合度。 
　　外觀模式要求一個子系統的外部與其內部的通信通過一個統一的外觀對象進行，外觀類將客戶端與子系統的內部複雜性分隔開，使得客戶端只需要與外觀對象打交道，而不需要與子系統內部的很多對象打交道。 
　　外觀模式的目的在於降低系統的複雜程度。
　　外觀模式從很大程度上提高了客戶端使用的便捷性，使得客戶端無須關心子系統的工作細節，通過外觀角色即可調用相關功能。

優點：
　　對客戶屏蔽子系統組件，減少了客戶處理的對象數目並使得子系統使用起來更加容易。通過引入外觀模式，客戶代碼將變得很簡單，與之關聯的對象也很少。
　　實現了子系統與客戶之間的松耦合關係，這使得子系統的組件變化不會影響到調用它的客戶類，只需要調整外觀類即可。
　　降低了大型軟體系統中的編譯依賴性，並簡化了系統在不同平臺之間的移植過程，因為編譯一個子系統一般不需要編譯所有其他的子系統。一個子系統的修改對其他子系統沒有任何影響，而且子系統內部變化也不會影響到外觀對象。
　　只是提供了一個訪問子系統的統一入口，並不影響用戶直接使用子系統類

缺點
　　不能很好地限制客戶使用子系統類，如果對客戶訪問子系統類做太多的限制則減少了可變性和靈活性。
　　在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。

適用環境：
　　當要為一個複雜子系統提供一個簡單介面時可以使用外觀模式。該介面可以滿足大多數用戶的需求，而且用戶也可以越過外觀類直接訪問子系統。
　　客戶程式與多個子系統之間存在很大的依賴性。引入外觀類將子系統與客戶以及其他子系統解耦，可以提高子系統的獨立性和可移植性。
　　在層次化結構中，可以使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯繫，而通過外觀類建立聯繫，降低層之間的耦合度。