1. 程式人生 > >重構 改善既有程式碼設計---第三章 程式碼壞味道

重構 改善既有程式碼設計---第三章 程式碼壞味道

3.1 重複程式碼
程式碼重複會讓整個類變得更大,影響程式碼閱讀。

1.同個類:不同方法中多次出現重複的程式碼或者表示式時,可以使用“提煉方法”的方式將重複程式碼或表示式提煉到方法A中,所有使用到這段程式碼或者表示式的方法通過對A方法的呼叫實現功能
2.兩個互為兄弟的類中含有相同的程式碼或者表示式:將重複程式碼提煉到指定方法A中,再將A方法推入到超類,後兩個子類通過呼叫超類的方法A完成功能
3.不同的類中出現重複程式碼:應將該重複程式碼提煉到獨立的類中,後通過使用新類中定義的方法實現功能

3.2 過長函式
程式碼越長,越難理解。
程式的解釋能力、共享能力、選擇能力,都是由小型函式支援的。
摘抄:
讓小函式容易被理解的真正關鍵在於一個好名字,如果你能給函式起個好名字,讀者可以通過名字瞭解函式的作用,根本不必去看其中寫了什麼,
積極地分解函式,我們遵循一條原則:每當感覺需要以註釋來說明什麼的時候,我們就把需要說明的東西寫進一個獨立的函式中,並以其用途命名。
關鍵不在於函式長度,而在於函式“做什麼”和“如何做”之間的語義距離。
1.函式中有大量的引數和臨時變數:
1)使用replace temp query(以查詢取代臨時變數)來消除這些臨時元素;introduce parameter object(引入引數物件)和preserve whole object(保持物件完整)則可以將過長的引數變得簡潔;如果還是存在大量的臨時變數,也可以使用replace method with method object(以函式物件取代函式)

3.3 過大的類
一個類只做一類事情
3.4 過長引數列
過長的引數列使用時會對不上號,難以理解。
1.使用物件替換過長的引數列,需要的引數只需要從物件中獲取即可,引數的增刪改,不會對使用的函式造成大影響。

3.5 發散式變化
定義:某個類常常會因為不同的原因在不同的方向上發生變化
一個類只做一類事情
3.6霰彈式修改
某種變化,會對多個類中方法進行修改(不能大意,否則會漏掉需要修改的地方,導致系統功能錯誤)
將發生改變的方法移動到一個類中
3.7 程式碼耦合
A類中某函式在進行功能實現時,對B類中多個不同的函式進行呼叫,耦合度過高。
解決:將所有使用B類資料和函式的地方進行提煉,再將該提煉的函式移至B類,A類中方法只需呼叫一次即可。
3.8 資料泥團


多個類中存在同名同意的欄位,將這些欄位整理出來,分別放入不同的類中,然後給它們賦予合適的函式簽名(根據語義和用途對其進行提煉到新類中,物件命名根據用途命名
3.9 少用switch或使用多型
3.10 對於類中無用的屬性或者元件,應將其消除,否則會使系統更難理解和維護
3.11 過度耦合的訊息鏈(一個物件請求另一個物件,再向後者請求另一個物件…)
3.12 同樣的功能,不一樣的函式簽名,合併程式碼。
3.13 註釋:寫明自己為什麼做某事,也可以加入一定的功能實現步驟。

	*減少重複程式碼;一個方法不需要太長;警惕臨時變數對程式的汙染;堅持一個類只做一類事;方法引數列表不應太長;降低程式碼耦合;引數過多時可以使用物件替換;精簡程式碼,避免類中出現無用的引數或元件;註釋不宜過多,但要描述清楚為什麼寫此函式,可以加入一些實現步驟進行描述。以上改變可以使程式碼閱讀者更好的閱讀和理解程式碼。*