我們有時候在應用程式中可能編寫了一些「幽靈」類，「幽靈」類也叫中間類。這些中間類可能什麼事兒都沒做，而只是簡單地呼叫了其他的元件。這些中間類沒有發揮實際的作用，它們增加了應用程式的層級（layer），並且增加了應用程式的複雜性。這時，我們應將這樣的中間類刪除，甚至刪除中間類所處的「中間層」——這就是本文要講的重構策略「移除中間類」。
這個重構策略比較容易理解，下面這幅圖演示了它的重構過程。
通常情況下，無效的中間類可能是因為濫用設計模式而造成的。
如果設計模式使用的恰當，這個重構策略就不適用了，比如用「門面模式」、「介面卡模式」和「**模式」的場景。
下面我以「門面模式」簡單說明一下不適用的場景。
門面模式，是指提供乙個統一的介面去訪問多個子系統的多個不同的介面，它為子系統中的一組介面提供乙個統一的高層介面。使得子系統更容易使用。
通過區分「門面模式」的使用場景，可以判斷是否應該使用「移除中間類」：
1、客戶只需要使用某個複雜系統的子集，或者需要以一種特殊的方式與系統互動時，使用門面模式。這段**定義了3個類，consumer依賴於accountmanager，accountmanager依賴於accountdataprovider。2、當需要跟蹤原系統的使用情況時 ，使用門面模面模式。因為所有對系統的訪問都經過facade,所以可以很容易地監視系統的使用 。
3、 希望封裝和隱藏原系統時。
4、編寫新類的成本小於所有人使用和維護原系統使用所需的成本時
隱藏**
public class consumeraccountmanager類作為中間類，沒有起到任何實際的作用，它只是依葫蘆畫瓢地套用了accountdataprovider做的事情。public consumer(accountmanager accountmanager)
public void get(int id)
}public class accountmanager
public accountmanager(accountdataprovider dataprovider)
public account getaccount(int id)
}public class accountdataprovider
}
移除中間類後，consumer類直接依賴於accountdataprovider類。
隱藏**
public class consumer小酌重構系列目錄彙總public consumer(accountdataprovider dataprovider)
public void get(int id)
}public class accountdataprovider
}
關注keepfool
小酌重構系列 12 去除上帝類
神說 要有光 就有了光。聖經 上帝要是會寫程式，他寫的類一定是 上帝類 程式設計師不是上帝，不要妄想成為上帝，但程式設計師可以寫出 上帝類 上帝是唯一的，上帝的光芒照耀人間，上帝是很愛面子的，他知道程式設計師寫了 上帝類 搶了他的風頭，於是他降下神罰要懲戒程式設計師。既然你寫了 上帝類 那麼就將你流...
小酌重構系列 17 提取工廠類
在程式中建立物件，並設定物件的屬性，是我們長幹的事兒。當建立物件需要大量的重複 時，看起來就不那麼優雅了。從類的職責角度出發，業務類既要實現一定的邏輯，還要負責物件的建立，業務類幹的事兒也忒多了點。物件建立也是 一件事 我們可以將 這件事 從業務 中提取出來，讓專門的類去做 這件事 這個專門的類一般...
小酌重構系列 21 避免雙重否定
在自然語言中，雙重否定表示肯定。但是在程式中，雙重否定會降低 的可讀性，使程式不易理解，容易產生錯覺。人通常是用 正向思維 去理解一件事情的，使用雙重否定的判斷，需要開發者以 逆向思維 的方式去理解它的含義。另外，在寫程式時，符號很容易被疏忽和遺漏，一不小心則會編寫出錯誤的 從而產生bug。所以，在...