《refactoring improving the design of existing code》--martin fowler
chapter-1
例子1:根據不同型別電影,租期長短,計算**,並輸出。寫到乙個方法了。
可能變化:增加/改變輸出樣式,電影型別分類可能會變,計費標準會變。
只有優秀的人才能寫出人易讀的**。機器永遠會理解。
方法/變數名稱,是**清晰的關鍵。
方法應該放在,它使用的資料所屬物件內,這樣依賴低。
2,乙個電影可以在生命週期內修改分類,乙個物件卻不能修復所屬類。
不能建立電影子類,但可以建立**子類。replace type with state/strategy,
把type相關行為移到state/strategy內部。
模式取決於:state:代表電影的某個狀態,strategy代表計費策略。反映對結構的想法。
物件導向:思考物件的職責。
重構隨時隨地。
事不過三,三則重構。
重構可以取代預先設計。
switch少用,switch意味著重複。
間接層/方法:價值大於代價(易讀復用)才有必要存在。
重複是萬惡之源
chapter-6
6.1 extract method 以它「做什麼」命令,不是怎麼做。
6.4 replace temp with query 。臨時變數盡量用final修飾。
double getprice()
6.5 introduce explaining variable 解釋性變數
boolean ismacos = platform.indexof("mac") > -1;
if( ismacos && isiebrower)
chapter-7
如果乙個類承擔太多責任,考慮extract class,如果太雞肋,考慮inline class
chapter-8
狀態碼不變、且行為相同,不用抽取。比如性別男女。
不變、行為不同,抽取子類。
可變,生命週期內可變、或其他原因不能繼承,使用state/stratege模式
chapter-9簡化方法呼叫
查詢、修改方法分離。gettotalandsetsum()-->gettotal(),setsum();
引數超過4個時,使用物件封裝引數。
工廠方法:根據型別碼,提供一組類的,物件構造方式。介面簡單統一。
如果有向下轉型的**,首先考慮是否可以用模板類代替。
組合:子類不需要父類的很多操作和介面。介面不能反映子類的功能,意圖混淆。
繼承:需要使用受delegation的類的所有方法,則改為繼承。
類內部field自我封裝:直接使用變數,直到它帶來麻煩為止,自我封裝是方便子類覆蓋。
replace data value with object 把**號碼抽取成物件,因為有格式化,抽取區號,登方法
new customer(1).store(),new customer(2).store(),store()
多個order對應同乙個customer,應該只物件改為引用物件,使用工廠
引用物件回提高難度
陣列,集合,只應用於一組類似物件,如果不是使用包裝物件替換,replace array with object
比如:乙個元素是名字,第二個是分數,就應該封裝為物件。
《重構》讀書筆記
再次看重構這本書,用了十幾分鐘,看完了原來斷斷續續用了差不多一周看完的第一章 沒有增加什麼新知識 僅對state stategy模式增加了點熟悉度 可見許久前學習第一章還是比較深入的,呵呵。還記得當時看得還是有點費力的。站的高度不同了,視角變化了,所以看得也快,看得也更精深。首先覺得第一章寫的真不賴...
重構讀書筆記
年前參加了軟體重構的培訓,就像老師所說,幾天的培訓不會有實質的變化,主要的目的是出發更深層次的思考和不斷的實踐,1,duplicated code,重複 是最常見,醜陋的壞味道,有以下一些解決辦法 extract method pull up method template method 這個準則最...
重構 讀書筆記
1.重構的基本原則 新增新功能和重構是兩類工作。重構時,盡量不要新增新功能,除非發現了原來程式的錯誤。其實即使發現原來的錯誤,也應該把錯誤暫時記下來,待重構完成後,再修改原來的錯誤。重構就是不修改程式對外的表現形式,哪怕原來是錯誤的。2.重構時state模式的使用 當乙個物件中的某個屬性需要改變類屬...