[設計模式] Facade Pattern 外觀模式

 

又是一個已經使用過卻不知道是一種設計模式的設計模式，

最常做的一件事就是把儀器的SDK包裝後給同事使用。

先來看類別圖：

程式碼請參考 Chapter_12.1

以上面的範例為例，

每個SubSystem類別都有各自的方法，

但Client並不會用到所有SubSystem的方法，也不想理解所有的方法，

只希望開發者能夠提供一個快速上手的類別，而這個類別內的所有功能都是他會使用到的。

因此Facade就來達成這個需求，來看看他裡面定義了什麼：

可以看到儘管有四個SubSystem Class，也有共八個 Function ，

但使用者只需要其中的五個 Function 所組成的功能，

因此開發者就能夠利用 Facade 這個類別將這些 Function 進行組合，

使用者很直覺的就可以拿到兩個滿足他需求的 Function (MethodGroupOne & MethodGroupTwo)。

使用者程式碼：

輸出：

應用情境

就像我們跟廠商買了光學探頭，

光學探頭功能非常非常多，SDK可能提供了幾百個Function給我使用，

但我只需要基本的量測與Trigger功能，在開發時限的要求下，

這時候就會希望他寫一個Facade類別給我，加速我開發時程，不過這是不可能的。

這樣我就不需要慢慢地從SDK裡面找出我要使用的Function來使用，

而我也不需要一直跟廠商的應用工程師聯繫說，那個XXX的功能在那裡...?

或者是想保護你的程式碼，只想開放部分功能讓人使用。

或者你是個好心的同事，同事需要的功能你已經寫過了，但你的類別內還包含了其他功能，

同事的需求只占用這個類別的5%，為了幫助他快速上手，你便可以寫個 Facade 給他，

他就能快速使用，不過這是不可能的，吃飽太閒，通常的情況是整包類別丟給他，

跟他說有哪幾個function可以用這樣。

又或者是，你的公司團隊使用到古老的一套系統，裡面寫得非常雜亂，

這時你便可以把團隊分為兩部分，第一個團隊專注於開發 Facade 把老系統包裝起來，

另一個團隊只要專注於使用 Facade 的使用即可。

似乎和範本方法很類似？

如果都是為了在這個pattern上進行功能組合，那麼外觀模式和範本方法有什麼差異?  

儘管兩者很像，但很多細節也是不同的，

範本方法注重在規範繼承的人都要經過這套演算法架構，

且範本方法的產生順序，是先有各種相似的類別，這些類別當中又有些流程是相同的，

才提煉出父類別中的範本方法，藉由繼承來加以規範，

而外觀模式反而是想幫人整理複雜的底層，

讓人"更好呼叫，容易使用"，注重在"整理與分離"，

而不是在於規範架構，儘管他也是先有了各種類別，才去開發 Facade 類別，

但這些類別並不相似，關聯性不高，

主要是想透過Facade這一層來幫使用者整理出可用的介面，以既有的功能當中，

不改變任何既有類別，建立出新的使用方式。