Facade 模式

您打算使用某個程式庫來開發您的應用程式，程式庫中可能有Some、Other與Another等類別，您的應用程式也許會像這樣撰寫來完成某個（些）動作：

class Application {
    void doAction() {
        Some some = new Some();
        Other other = new Other();
        Another another = new Another();
        //..讓這些物件作一些互動以產生結果
    }
}

您的應用程式直接使用了程式庫中所提供的各種API，也就是應用程式直接與程式庫有了高度耦合，這有幾個問題值得討論，將來程式庫異動，您的應用程式中與該程式庫相關部份，都要一一找出修改，如果未來有更換程式庫的可能性，這種設計方式顯然地屆時必須作出大幅修改。

您可以檢視應用程式使用這些程式庫的方式，釐出一個入口（Facade）介面，讓對程式庫的依賴實現在對介面的實作上，例如：

interface Service {
    void doAction();
}

class ActionService implements Service {
    public void doAction() {
        Some some = new Some();
        Other other = new Other();
        Another another = new Another();
        //..作一些互動以產生結果
    }
}

而應用程式僅依賴在入口介面上：

class Application {
    private Service service;
    Application(Service service) {
        this.service = service;
    }
    void doAction() {
        service.doAction();
    }
}

應用程式不需要再知曉程式庫各種API的存在，因而不會對程式庫產生耦合，如果您從另一個角度來想，ActionService若是由熟悉程式庫的開發人員所撰寫，提供給另一個撰寫Application的開發人員所使用，則後者並不用一定得知曉程式庫如何使用，有利於分工合作，將來就算開發 ActionService的開發人員改寫或重新實作了另一個Service類別，撰寫Application的開發人員也無需修改寫它的程式。

如果使用Python示範類似的概念：

class ActionService:
def doAction(self):
some = Some()
other = Other()
another = Another()
# 作一些互動以產生結果

class Application:
def __init__(self, service):
self.service = service
def doAction(self):
service.doAction()

這是Facade模式的例子，Facade模式可以簡化程式庫的使用、隱藏所依賴的程式庫、降低對程式庫的耦合、有利於分工合作。Facade模式的結構如下：

Facade模式隱藏了各個元件之間的合作行為，以及元件本身的操作與設定細節，固而必失去了一些直接操作元件的方便性，所以對於喜歡追求與操作細節的程式設計人員而言，不會很喜歡透過Facade來操作背後的元件，所以您的Facade介面設計，通常要在元件依賴性及元件的支接操作性之間作個平衡。