**摘要：**由于最近在做重構的項目，所以對重構又重新進行了一遍學習和整理，對31天重構最早接觸是在2009年 10月份，由于當時沒有訂閱[Sean Chambers](http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx)的blog，所以是在國外的社區上閑逛的時候鏈接過去的。記得當時一口氣看完了整個系列并沒有多少感覺，因為這些基本上項目都在使用，只是我們沒有專門把它標示和整理出來，所以也沒有引起多大的重視。現在突然接手這個重構項目，由于團隊成員技術和經驗參差不齊，所以有必要專門整理一個重構的綱要，當然這個系列也非常適合做新系統的代碼規范參考，只要有代碼的地方，這個重構規范就很有價值。周末也不想出去閑逛，因為在剛到這個美麗的城市，沒有親戚或者朋友，所以才能靜下心來兩天時間寫完這個重構參考規范。同時也感受了Windows Live writer寫文章的快感。當然重構的整體架構得另當別論（整體架構在我的這篇文章有專門的講解（[http://www.cnblogs.com/zenghongliang/archive/2010/06/23/1763438.html](http://www.cnblogs.com/zenghongliang/archive/2010/06/archive/2010/06/archive/2010/06/23/1763438.html)）。大的架構設計好了以后，這些重構細節點就成了東風之后的大火，對整個項目也是至關重要。31天重構這個系列和《代碼大全》、《重構：改善既有代碼的設計》比較起來最大的特點就是比較簡單、淺顯易懂。那么我這些文章也都是學習Sean Chambers的31天重構的筆記整理，所以如果大家對這個筆記有任何異議也可以指出。 具體也可以通過[http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx](http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx)查看原文。 **概念：**本文中的”去除上帝類”是指把一個看似功能很強且很難維護的類，按照職責把自己的屬性或方法分派到各自的類中或分解成功能明確的類，從而去掉上帝類。 **正文：**我們經常可以在一些原來的代碼中見到一些類明確違反了SRP原則（單一原則），這些類通常以“Utils”或“Manager”后綴結尾，但有時這些類也沒有這些特征，它僅僅是多個類多個方法的組合。另一個關于上帝類的特征是通常這些類中的方法被用注釋分隔為不同的分組。那么久而久之，這些類被轉換為那些沒有人愿意進行歸并到合適類的方法的聚集地，對這些類進行重構是將類中的代碼按照職責分派到各自的類中，這樣就解除了上帝類，也減輕了維護的負擔。 ~~~ using System.Collections.Generic;using LosTechies.DaysOfRefactoring.EncapsulateCollection.After;using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer;namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveGodClasses.Before{ public class CustomerService { public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer) { // do work } public bool CustomerIsValid(Customer customer, Order order) { // do work } public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer) { // do work } public void Register(Customer customer) { // do work } public void ForgotPassword(Customer customer) { // do work } }} ~~~ [](http://11011.net/software/vspaste) 我們看到要重構上面的代碼是很簡單的，只要將相關的方法按職責分派到對應的類中即可，帶來的好處就是這會降低代碼的顆粒度并減少未來維護代碼的成本。下面是重構后的代碼，它將上面 的代碼按照職責分為了兩個不同的類。 ~~~ using System.Collections.Generic;using LosTechies.DaysOfRefactoring.EncapsulateCollection.After;using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer;namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveGodClasses.After{ public class CustomerOrderService { public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer) { // do work } public bool CustomerIsValid(Customer customer, Order order) { // do work } public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer) { // do work } } public class CustomerRegistrationService { public void Register(Customer customer) { // do work } public void ForgotPassword(Customer customer) { // do work } }} ~~~ [](http://11011.net/software/vspaste) **總結：**”去除上帝類“是我們經常容易造成的，第一是因為簡便，看到有一個現成的類，大家都會喜歡把代碼往里面寫，最后導致越寫越大，并且聲明功能都有，這樣即降低了可讀性，也造成了維護的負擔。