近期參與專案研發，調介面時遇一事不爽，比如在調c方法前必須得先調a方法，成功後再調b方法拿到返回結果後，最後才可以調c方法，而且介面呼叫還會隨需求變化而變更，比如可能還得再增加幾個步驟......
門面模式(亦稱外觀模式facade pattern)的思想很好地解決了這一問題，當然，它的優點也不止如此。
場景舉例
投遞信件的過程是：首先寫信的內容 -> 其次寫信封 -> 把信放到信封裡 -> 然後郵遞
介面類：iletterprocess
/**
* @author xuanyin
* */
public inte***ce iletterprocess
(**略)
場景類：client
/**
* @author xuanyin
* */
public class client
}
模式演變
增加一郵局類，提供信件代發業務，只需把信件的必要資訊告之，就代為傳送，即提供以上四個步驟的一體化服務。
郵局類：postoffice
/**
* @author xuanyin
* */
public class postoffice
}
增加郵局類後，在場景類中呼叫時就簡單多了
場景類：client
/**
* @author xuanyin
* */
public class client
}
警察類：police
/**
* @author xuanyin
* */
public class police
}
郵局類：postoffice
/**
* @author xuanyin
* */
public class postoffice
}}
注意事項
一、乙個介面類可以用多個門面
一般情況下，乙個介面類只要有乙個門面物件就足夠了，但下列情況可以有多個：
1.門面物件已龐大到一定的程度：比如超過一定行數的**，雖然都是非常簡單的委託操作，也建議拆分成多個門面。拆分時可按功能拆分，比如乙個資料庫操作，拆分成查詢門面物件，刪除門面物件，更新門面物件等。
2.給介面類提供不同的訪問路徑：我的理解是，比如模組1通過門面物件a可以完整地訪問所有邏輯，但模組2是受限制的，如果仍使用門面物件a，那是無法實現受限的。這時就需要新增門面物件b，提供模組2應得的方法。但在新增門面物件b時，無需重新實現。因在物件導向程式設計中，應盡量保持相同的**只寫一遍，避免以後修改時到處都要修改的杯具發生。如：
/**
* * @author xuanyin
* */
public class facade2
}
門面物件只是提供乙個訪問介面的路徑而已，不應該也不能參與具體的業務邏輯，否則就會產生乙個倒依賴的問題：介面必須依賴門面才能被訪問。如果在門面物件內有業務邏輯，則應建立乙個封裝類，封裝完畢後提供給門面物件。
設計模式 門面模式
一 門面模式概述 門面模式是物件的結構模式，外部與乙個子系統的通訊必須通過乙個統一的門面物件進行。門面模式提供乙個高層次的介面，使得子系統更易於使用。1 門面角色 facade 這是門面模式的核心。它被客戶角色呼叫，因此它熟悉子系統的功能。它內部根據客戶角色已有的需求預定了幾種功能組合。2 子系統角...
設計模式 門面模式
門面模式 外觀模式 將子系統中的一組介面提供乙個一致的介面，外觀模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。1 它對客戶遮蔽子系統元件，因而減少了客戶處理的物件的數目並使得子系統使用起來更加方便。2 它實現了子系統與客戶之間的松耦合關係，而子系統內部的功能元件往往是緊耦合的。3 如果...
《設計模式》 門面模式
提供乙個門面去呼叫系統各個子模組，客戶端呼叫門面，減少客戶端與系統中各個子模組的互動，鬆散耦合，facade知道各個子模組，而各個子模組不應該知道facade的存在 客戶端也可以直接呼叫各個子模組，有外觀也可以不使用 當需要呼叫系統內部多個子模組的時候，為了避免客戶端分別呼叫子模組，提供乙個門面，讓...