《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模式的使用 當乙個物件中的某個屬性需要改變類屬...