有些開發者為了貪圖簡便，看到一個現成的類，也不管這個類是做什麼的，需要追加功能時，就向這個類裡面添加功能代碼。久而久之，使得一些類變成了“上帝類”。什麼是“上帝類”？上帝類也叫萬能類，意指做了太多“事情”的類。在開發過程中，我們應該保持一個良好的習慣，在類中追加功能時，一定要事先确認類的職責，并控制好類的粒度，這有益于代碼的可讀性、擴充性、維護和修改。
神說：“要有光”，就有了光。——《聖經》。上帝要是會寫程式，他寫的類一定是“上帝類”。程式員不是上帝，不要妄想成為上帝，但程式員可以寫出“上帝類”。上帝是唯一的，上帝的光芒照耀人間，上帝是很愛面子的，他知道程式員寫了“上帝類”，搶了他的風頭，于是他降下神罰要懲戒程式員。——既然你寫了“上帝類”，那麼就将你流放到艱難地修改和痛苦的維護的煉獄中，在地獄之火中永久地熬煉。
你看，上帝也是有脾氣的，你做了什麼他都知道，你不能搶他的風頭，否則你就要付出代價，受到相應的懲罰。為息帝怒，咱們還是老老實實地編寫一些“小類”吧。
有些開發者為了貪圖簡便，看到一個現成的類，也不管這個類是做什麼的，需要追加功能時，就向這個類裡面添加功能代碼。久而久之，使得一些類變成了“上帝類”。什麼是“上帝類”？上帝類也叫萬能類，意指做了太多“事情”的類。在開發基于WebForms的應用程式時，Page頁面的後置代碼中包含了通路資料庫、處理業務邏輯、綁定頁面資料、頁面事件處理等這些事情，這就是上帝類的一個舉證（可能很多人都這麼幹過）。
“存在即合理”——上帝類比較适用于一些較小的、穩定的應用開發場景，即那些業務邏輯不複雜、也不需要太多元護的應用程式。
比如：一些小工具的開發，不需要過多地考慮類的粒度和職責劃分，樓主部落格中用的Windows Live Writer代碼高亮插件就是這麼做的。
上帝類的缺點是顯而易見的，上帝類的顆粒度較大，它缺乏可讀性、可擴充性和可維護性。
上帝類違反了“SRP原則”，上帝類擔任的職責太多了，該做的和不該做的它都做了。
同時也違反了“OCP原則”，上帝類功能之間的耦合性太高了，是以不具備可擴充性，當需求變化時，可能會涉及到大量代碼的修改。
“SRP原則”和“OCP原則”的我就不再贅述了，想了解這兩個原則，請參考該系列的另外兩篇文章：分離職責和提取接口。
下面這個CustomerService類，定義了5個方法：
CalculateOrderDiscount()方法：結合客戶資訊，計算訂單的折扣
CustomerIsValid()方法：結合訂單資訊，判斷客戶是否有效
GatherOrderErrors()方法：結合訂單的商品資訊和客戶資訊，收集訂單錯誤資訊
Register()方法：注冊客戶資訊
ForgotPassword()方法：處理客戶忘記密碼
在業務上，這些方法多少和Customer是有一些關聯的。但這不意味着，隻要是和Customer相關的方法都要放到CustomerService中。
這個類還可以在職責上做一些劃分，粒度可以控制的在細一些。
重構後，我們按職責将<code>CustomerService</code>拆分為了<code>CustomerOrderService</code>和<code>CustomerRegistrationService</code>。
拆分後，我們可以看到：
這兩個類的語義和它們的命名以及定義在其中的方法都是契合的。
類的粒度變小了，代碼的可讀性增強了，并且有利于将來的擴充、維護、修改。
在開發過程中，我們應該保持一個良好的習慣，為類中追加功能時，盡量确認好類的職責，并控制好類的粒度，這有益于代碼的可讀性、擴充性、維護和修改，這樣就不會被上帝發現了。
小酌重構系列目錄彙總
關注keepfool
本文連結：
文章作者：keepfool
文章出處：http://www.cnblogs.com/keepfool/
如果您覺得閱讀本文對您有幫助，請點一右下角的“推薦”按鈕，您的“推薦”将是我最大的寫作動力！歡迎看官們轉載，轉載之後請給出作者和原文連接配接。