Facade Pattern

外觀模式 (Facade)，這個應該是最容易理解的一個Pattern了，今天就單純地來聊聊這個Pattern吧。

當然這邊所說的Facade只涉及概念，實作的部分在C#、JavaScript、其他各種語言可能略有不同。

回過頭來，在Wiki上面定義的Facade我想還是文言了一點，其實以我的理解，Facade它可以幫助我做兩件事情。

簡化你的系統對外接口

也就是將你所設計、維護的程式碼，重新設計一個容易呼叫、容易理解的對外接口，便於其他人使用，而不需要再去呼叫原先其他較為複雜的方法。也許在系統內，要完成某一個功能，需要呼叫Function A、Function B、Function C；而且每一個方法所需要傳入的參數可能又很複雜。

又或者是類似的方法名稱有很多個，卻又有著細微的差異，容易造成錯誤的呼叫，諸如此類的所有原因，為了簡化你的系統，你很有可能會自己先實作一個方法，而原先的步驟，都放到這個方法內，其實這個就是Facade Pattern。

具體一點的例子，套用Bill叔的OOP課程範例說明，以Json的序列化而言，他的呼叫方法可能不常用的人都記不起來，打幾個關鍵字後Intellinse給出來的幾個又都很像，每次都要思考一下，還可能會用錯。所以為了序列化、反序列化方便使用，自己建立一個單純的Class，裡面就兩個方法，一個序列化，一個反序列化。容易使用又好記，還不會記錯；這邊的目標就是為了避免誤用。

重構Legacy Code，建立防火線

另外一個用法，則是深受Legacy Code困擾下的解法。如何針對遺留代碼做重構、做測試保護、Facade就是一個非常有用的技巧，他將遺留代碼視為一團泥沼，在沒有測試保護的情況下，我想沒有人願意再踏入其中維護，或是修改任何東西吧？

此時就可以將這些遺留代碼先透過Facade Pattern，建立一個對外的介面，讓其他應用程式改呼叫這個新的介面，反覆這樣的行為，這樣一來，就可以逐步消除系統呼叫遺留代碼的部分，中間隔了一層，然後針對這些新介面，撰寫測試保護；接著，再去重構那團混亂不堪的遺留代碼。因為此時已經有了Facade的新類別，也有測試保護，重構他不再是遙不可及的事情。

如果因為實際的情境下，無法讓你重構，最起碼也可以透過Facade Pattern將Legacy Code與其他新寫的Code隔離開來，讓系統至少不要變得更爛。

參考資料：The Facade Pattern