好了，前面所有的都是很簡單的例子，現在開始的是大型重構。
對於大型重構來說，情況復雜多變，耗時也會很長，前面的簡單重構大多是在一個小時內可以完成，但是對於大型重構來說可能需要幾個月，甚至數年。如果是一個運行中的系統，重構起來只能每天一點點去慢慢重構。
（恕我直言，在國內恐怕這樣的公司也很少。所以我們要自己養成隨時重構的習慣，不要挖坑給自己埋最好。沒誰能給你這麼長時間重構，特別當你是個低端程序員的時候。你得相信，你所有偷懶的舉動，都會給你以後的工作帶來麻煩。除非你明天走人了，那麼你的鍋可能就給我背了，等你到了新的公司，你又發現你也成了一個背鍋的。）
1、梳理並分解繼承體系
修改點：某個繼承體系同時承擔兩個責任。如果繼承體系中的某一特定層級上的所有類，其子類名稱都以相同的形容詞開始，那麼這個體系很可能就是承擔著兩項不同的責任。
做法：建立兩個繼承體系，並通過委托關系讓其中一個可以調用另一個。
動機：混亂的繼承體系會導致重復代碼。
好吧，簡單來說，你可以理解為橋接模式。
2、將過程化設計轉為對象設計
修改點：就是出現了C語言式的代碼
做法：將數據記錄變為對象，將大塊的行為分成小塊，並將行為移至相關對象中。
3、將領域和表述/顯示分離
修改點：某些GUI類中包含了業務邏輯
做法：將領域邏輯分離出來，並為它們建立獨立的領域類
4、提煉繼承體系
修改點：你為某個類做了太多工作，其中一部分以大量條件表達式完成
做法：建立一個繼承體系，以一個子類表示一種特殊情況
小總結：
好吧，上面四個點寫得很概括，但是其實包括了很多東西。
越復雜的東西反而講起來越簡單。
就像我說我們來寫個注冊系統吧，多簡單，但是實施起來其實也不簡單。
很多時候我們都不願意去改別人的代碼，因為可能業務就已經很復雜了，再加上可能他也寫得爛。
你唯一必須做的是，至少保證自己的代碼別人維護起來很輕松，與君共勉吧！
