門面模式 Facade Pattern

近期參與專案研發，調介面時遇一事不爽，比如在調c方法前必須得先調a方法，成功後再調b方法拿到返回結果後，最後才可以調c方法，而且介面呼叫還會隨需求變化而變更，比如可能還得再增加幾個步驟......

門面模式(亦稱外觀模式facade pattern)的思想很好地解決了這一問題，當然，它的優點也不止如此。

場景舉例

投遞信件的過程是：首先寫信的內容 -> 其次寫信封 -> 把信放到信封裡 -> 然後郵遞

介面類：iletterprocess

/**
* @author xuanyin
*  */
public inte***ce iletterprocess

實現類：letterprocess

(**略)

場景類：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 
}

二、門面不參與介面類內的業務邏輯

門面物件只是提供乙個訪問介面的路徑而已，不應該也不能參與具體的業務邏輯，否則就會產生乙個倒依賴的問題：介面必須依賴門面才能被訪問。如果在門面物件內有業務邏輯，則應建立乙個封裝類，封裝完畢後提供給門面物件。

門面模式 Facade Pattern

設計模式門面模式

設計模式門面模式

《設計模式》門面模式

門面模式 Facade Pattern

設計模式 門面模式

設計模式 門面模式

《設計模式》 門面模式

相關推薦

設計模式門面模式

設計模式門面模式

《設計模式》門面模式