23.4 門面模式的注意事項 23.4.1 一個子系統可以有多個門面 一般情況下，一個子系統只要有一個門面足夠了，在什么情況下一個子系統有多個門面呢？以下列舉了幾個。 ● 門面已經龐大到不能忍受的程度 比如一個純潔的門面對象已經超過了200行的代碼，雖然都是非常簡單的委托操作，也建議拆分成多個門面，否則會給以后的維護和擴展帶來不必要的麻煩。那怎么拆分呢？按照功能拆分是一個非常好的原則，比如一個數據庫操作的門面可以拆分為查詢門面、刪除門面、更新門面等。 ● 子系統可以提供不同訪問路徑 我們以門面模式的通用源代碼為例。ClassA、ClassB、ClassC是一個子系統的中3個對象，現在有兩個不同的高層模塊來訪問該子系統，模塊一可以完整的訪問所有業務邏輯，也就是通用代碼中的Facade類，它是子系統的信任模塊；而模塊二屬于受限訪問對象，只能訪問methodB方法，那該如何處理呢？在這種情況下，就需要建立兩個門面以供不同的高層模塊來訪問，在原有的通用源碼上增加一個新的門面即可，如代碼清單23-10所示。 代碼清單23-10 新增門面 public?class?Facade2?{ ?????//引用原有的門面 ?????private?Facade?facade?=?new?Facade(); ?????//對外提供唯一的訪問子系統的方法 ?????public?void?methodB(){ ?????????????this.facade.methodB(); ?????} } 增加的門面非常簡單，委托給了已經存在的門面對象Facade進行處理，為什么要使用委托而不再編寫一個委托到子系統的方法呢？那是因為在面向對象的編程中，盡量保持相同的代碼只編寫一遍，避免以后到處修改相似代碼的悲劇。 23.4.2 門面不參與子系統內的業務邏輯 我們這節的標題是什么意思呢？我們舉一個例子來說明，還是以通用源代碼為例。我們把門面上的methodC上的邏輯修改一下，它必須先調用ClassA的doSomethingA方法，然后再調用ClassC的doSomethingC方法，如代碼清單23-11所示。 代碼清單23-11 修改門面 public?class?Facade?{ ?????//被委托的對象 ?????private?ClassA?a?=?new?ClassA(); ?????private?ClassB?b?=?new?ClassB(); ?????private?ClassC?c?=?new?ClassC(); ?????//提供給外部訪問的方法 ?????public?void?methodA(){ ?????????????this.a.doSomethingA(); ?????} ????? ?????public?void?methodB(){ ?????????????this.b.doSomethingB(); ?????} ????? ?????public?void?methodC(){ ?????????????this.a.doSomethingA(); ?????????????this.c.doSomethingC(); ?????} } 還是非常簡單，只是在methodC方法中增加了doSomethingA()方法的調用，可以這樣做嗎？我相信大部分讀者都說可以這樣做，而且已經在實際系統開發中這樣使用了，我今天告訴各位，這樣設計是非常不靠譜的，為什么呢？因為你已經讓門面對象參與了業務邏輯，門面對象只是提供一個訪問子系統的一個路徑而已，它不應該也不能參與具體的業務邏輯，否則就會產生一個倒依賴的問題：子系統必須依賴門面才能被訪問，這是設計上一個嚴重錯誤，不僅違反了單一職責原則，同時也破壞了系統的封裝性。 說了這么多，那對于這種情況該怎么處理呢？建立一個封裝類，封裝完畢后提供給門面對象。我們先建立一個封裝類，如代碼清單23-12所示。 代碼清單23-12 封裝類 public?class?Context?{ ?????//委托處理 ?????private?ClassA?a?=?new?ClassA(); ?????private?ClassC?c?=?new?ClassC(); ?????//復雜的計算 ?????public?void?complexMethod(){ ?????????????this.a.doSomethingA(); ?????????????this.c.doSomethingC(); ?????} } 該封裝類的作用就是產生一個業務規則complexMethod，并且它的生存環境是在子系統內，僅僅依賴兩個相關的對象，門面對象通過對它的訪問完成一個復雜的業務邏輯，如代碼清單23-13所示。 代碼清單23-13 門面類 public?class?Facade?{ ?????//被委托的對象 ?????private?ClassA?a?=?new?ClassA(); ?????private?ClassB?b?=?new?ClassB(); ?????private?Context?context?=?new?Context(); ?????//提供給外部訪問的方法 ?????public?void?methodA(){ ?????????????this.a.doSomethingA(); ?????} ????? ?????public?void?methodB(){ ?????????????this.b.doSomethingB(); ?????} ????? ?????public?void?methodC(){ ?????????????this.context.complexMethod(); ?????} } 通過這樣一次封裝后，門面對象又不參與業務邏輯了，在門面模式中，門面角色應該是穩定，它不應該經常變化，一個系統一旦投入運行它就不應該被改變，它是一個系統對外的接口，你變來變去還怎么保證其他模塊的穩定運行呢？但是，業務邏輯是會經常變化的，我們已經把它的變化封裝在子系統內部，無論你如何變化，對外界的訪問者來說，都還是同一個門面，同樣的方法——這才是架構師最希望看到的結構。