結構型設計模式之外觀模式（門面模式，Facade）

先來看模擬一下女同胞們生育險報銷的過程，如下：

–>準媽媽住院生孩子–>醫院繳納費用–>出院時辦理相關證明手續

–>拿著相關證明材料到公司，由公司進行資訊核實並上報

–>社保局將報銷費用返還

以上就是大致的乙個生育險的報銷過程，下面我們通過**來實現下：

public inte***ce ifertilityexpenseprocess

public
class
fertilityexpenseprocess
implements
ifertilityexpenseprocess
@override
public
void
dealwithformalities()
@override
public
void()
@override
public
void
transfer()
}

public
class
main
}

以上是乙個簡單的實現，在整個生育險報銷流程中，順序是不能隨便改變的，且每個需要報銷的媽媽（可憐的上班族）都要經歷這樣的流程，尤其是報銷的流程太過繁瑣，如果是乙個對流程不熟悉的，那麼可能會導致多次到醫院補充相關的證明材料，此時是多麼想有一種方式來自動處理這一繁瑣的流程，下面來實現下：

public
class
expenseprocess
}

public
class
main
}

整個時候我們對流程進行了封裝，想要報銷，只需要呼叫process()方法即可，媽媽們不用再關心具體的流程了。

這也是我們經常會用到的一種編碼方式，當要實現乙個複雜邏輯時，需要對複雜邏輯按職責進行細分成多個方法後，在將多個方法統一封裝到乙個對外的介面中，使得具體的邏輯對使用者是透明的，這也是門面模式的雛形。

門面模式官方的定義：要求乙個子系統的外部與其內部的通訊必須通過乙個統一的物件進行。

在看下面的**：

public
class
expenseprocessfacade
}

public
class
main
}

這裡為什麼要把**expenseprocess放到expenseprocessfacade中呢，對照以上的定義來看，expenseprocess 是屬於子系統內部的，只不過它對生育險報銷邏輯進行了一次封裝而已，如果媽媽們有其他的需求，比如「產後恢復」等等，此時就不適合在往這個類裡面新增更多的邏輯了。

那如果此時要新增其他的邏輯，應該怎麼辦呢，很簡單，首先需要定義好相關的類和實現，以及邏輯封裝類，然後在expenseprocessfacade **引用新新增的類，再對外提供乙個新的介面，呼叫新的邏輯封裝類的方法即可：

public
class
postpartumrecovery
public
void
consulting()
public
void
pay(
)}

public
class
}

public
class
expenseprocessfacade
public
void
processrecovery()
}

public
class
main
}

以上這種寫法，每新新增乙個邏輯，只需要在**expenseprocessfacade **中新增封裝了對應邏輯的類即可，這樣即使以後有改動，也只需要修改對應類介面中的邏輯即可，並不會影響到用的呼叫。

結構型設計模式之外觀模式（門面模式，Facade）

設計模式結構型之外觀模式

外觀模式門面模式結構型

十二設計模式之外觀模式（結構型）

結構型設計模式之外觀模式（門面模式，Facade）

設計模式 結構型之外觀模式

外觀模式 門面模式 結構型

十二 設計模式之外觀模式（結構型）

相關推薦

設計模式結構型之外觀模式

外觀模式門面模式結構型

十二設計模式之外觀模式（結構型）