小酌重構系列 12 去除上帝類

神說：「要有光」，就有了光。——《聖經》。上帝要是會寫程式，他寫的類一定是「上帝類」。程式設計師不是上帝，不要妄想成為上帝，但程式設計師可以寫出「上帝類」。上帝是唯一的，上帝的光芒照耀人間，上帝是很愛面子的，他知道程式設計師寫了「上帝類」，搶了他的風頭，於是他降下神罰要懲戒程式設計師。——既然你寫了「上帝類」，那麼就將你流放到艱難地修改和痛苦的維護的煉獄中，在地獄之火中永久地熬煉。

你看，上帝也是有脾氣的，你做了什麼他都知道，你不能搶他的風頭，否則你就要付出代價，受到相應的懲罰。為息帝怒，咱們還是老老實實地編寫一些「小類」吧。

有些開發者為了貪圖簡便，看到乙個現成的類，也不管這個類是做什麼的，需要追加功能時，就向這個類裡面新增功能**。久而久之，使得一些類變成了「上帝類」。什麼是「上帝類」？上帝類也叫萬能類，意指做了太多「事情」的類。在開發基於webforms的應用程式時，page頁面的後置**中包含了訪問資料庫、處理業務邏輯、繫結頁面資料、頁面事件處理等這些事情，這就是上帝類的乙個舉證（可能很多人都這麼幹過）。

「存在即合理」——上帝模擬較適用於一些較小的、穩定的應用開發場景，即那些業務邏輯不複雜、也不需要太多維護的應用程式。

比如：一些小工具的開發，不需要過多地考慮類的粒度和職責劃分，樓主部落格中用的windows live writer**高亮外掛程式就是這麼做的。

上帝類的缺點是顯而易見的，上帝類的顆粒度較大，它缺乏可讀性、可擴充套件性和可維護性。

上帝類違反了「srp原則」，上帝類擔任的職責太多了，該做的和不該做的它都做了。

同時也違反了「ocp原則」，上帝類功能之間的耦合性太高了，因此不具備可擴充套件性，當需求變化時，可能會涉及到大量**的修改。

下面這個customerservice類，定義了5個方法：

public class customerservice

public bool customerisvalid(customer customer, order order)
public ienumerablegatherordererrors(ienumerableproducts, customer customer)
public void register(customer customer)
public void forgotpassword(customer customer)
}

這個類還可以在職責上做一些劃分，粒度可以控制的在細一些。

重構後，我們按職責將customerservice拆分為了customerorderservice和customerregistrationservice。

public class customerorderservice

public bool customerisvalid(customer customer, order order)
public ienumerablegatherordererrors(ienumerableproducts, customer customer)
}public class customerregistrationservice
public void forgotpassword(customer customer)
}

在開發過程中，我們應該保持乙個良好的習慣，為類中追加功能時，盡量確認好類的職責，並控制好類的粒度，這有益於**的可讀性、擴充套件性、維護和修改，這樣就不會被上帝發現了。

小酌重構系列目錄彙總

關注keepfool

小酌重構系列 17 提取工廠類

在程式中建立物件，並設定物件的屬性，是我們長幹的事兒。當建立物件需要大量的重複 時，看起來就不那麼優雅了。從類的職責角度出發，業務類既要實現一定的邏輯，還要負責物件的建立，業務類幹的事兒也忒多了點。物件建立也是 一件事 我們可以將 這件事 從業務 中提取出來，讓專門的類去做 這件事 這個專門的類一般...

小酌重構系列 13 移除中間類

我們有時候在應用程式中可能編寫了一些 幽靈 類，幽靈 類也叫中間類。這些中間類可能什麼事兒都沒做，而只是簡單地呼叫了其他的元件。這些中間類沒有發揮實際的作用，它們增加了應用程式的層級 layer 並且增加了應用程式的複雜性。這時，我們應將這樣的中間類刪除，甚至刪除中間類所處的 中間層 這就是本文要講...

去除上帝類

我們經常可以在一些原來的 中見到一些類明確違反了srp原則 單一原則 這些類通常以 utils 或 manager 字尾結尾，但有時這些類也沒有這些特徵，它僅僅是多個類多個方法的組合。另乙個關於上帝類的特徵是通常這些類中的方法被用注釋分隔為不同的分組。那麼久而久之，這些類被轉換為那些沒有人願意進行歸...