**：
類之間的重構操作：
主要的內容就是分解龐大的類，合併不負責任的類，在類間搬移值域和函式。
1．movemethod
你的程式中，有個函式與其所在的類意外的另乙個類進行更多的交流，呼叫後者，或者背後者呼叫，說明這個函式可能不適合在這個類裡面，適當的時候移動到適當的類裡面。減少類之間的高度耦合。讓類乾淨利索的完成系統交付的任務。看似簡單，逐漸重構直到完善，沒關係，這部分重構充斥在你整個開發過程中，所以你沒有必要為不能恰當的移動函式而苦惱 2．
move field
搬移值域：道理通搬移函式，當你某個值域與其所在的類以外的另乙個類有更多的交流時，考慮搬移這個值域。這個操作很可能就是搬移method
的一部分 3．
extract class
提煉類：就是分解類，將類中的部分值域函式搬移到乙個新類裡面，顯然這個類做個太多的工作，包含不屬於她範圍內，或者類太大需要拆分。乙個類應該很明確的抽象處理一些明確的責任，，如果類中的某些函式經常同事變化彼此相依，那麼就考慮將他們分離出去。寫到這裡感覺類間的設計大部分還是根據經驗開始的時候盡量明確責任，設計合理的類，隨著功能的增加或者需求的變化在開發過程中逐步完善。 4．
inline class
內嵌類：
你的某個class
沒有做太多的事情，可以合併到，經常呼叫這個類的類中 5．
hide delegate
隱藏委託關係：
這部分複雜一些，首先要區分sever
類和client class
看個例子：manager = john.getdepatment().getmanager();
這裡面manager
就是client
類，而john.getdepatment()
返回的部門類
就是server
類，隱藏委託關係就是在johh
類裡面建乙個函式getmanager
（）方法，隱藏對server
類（depatment
類）的呼叫即：
public pserson getmanager()
那客戶端類的呼叫就變成了：manager = john.getmanager()
看了少了什麼就知道隱藏了什麼。
也就是說盡量不要類的巢狀呼叫。
而我一般寫**都是這麼設計：manager = department.getmanger(john).
需要好好理解一下設計思路，向組織靠攏 6．
remove middle man
（移除中間人操作），就是乙個類做了太多的hide delegate
操作，這個server
類完全變成了乙個中間人此時你應該讓客戶直接呼叫delegate
很難說清楚什麼時候hide delegate
什麼時候remove middle man
在系統執行過程中不斷調整，隨系統變化而變化就可以了 7．
introduce foreign method
引用外加函式：
你所使用的server
類需要乙個額外的函式，但是你不能修改這個類，那麼在client
類中（就是呼叫server
類的類中）增加乙個函式，並乙個server class
實體作為第一引用引數，擴充套件server
類的功能，請注意這個新加的函式是寫在那個類裡面了（client
裡面）
8．introduce local extension
引入本地擴充套件：
當原則7
裡面新增加的函式
被另外的多個類呼叫，那麼就要考慮新加乙個類，使他包含這些額外函式。這個本地擴充套件有兩個方法：1.
新加乙個server
類的子，同時為這個子類增加需要的函式2
）其實就是新加乙個類
然後在introduce foreign method
類間的搬移這部分就講完了，養足精力
後面的部分就不容易理解了
重構時機和重構方法之間的對應關係
id 需要重構的訊號 對應的重構方法 1出現了重複 提取或者重組類 提取或者重組函式 方法 用多型處理子類重複 2兩個類耦合太多，太親密 提取或者重組類，提取或者重組函式方法 3出現了 行尺寸極其龐大的類 提取或者重組類 4沒有實際作用的懶惰類 提取或者重組類 5體積龐大的方法函式 提取或者重組函式...
重構 過大的類
在物件導向的設計程式中，有個 單一職責 原則，也就是說，這個類的功能比較單一，只做一件事情，而且引起這個類物件變化也是唯一的。說白了就是乙個類只幹一件事情，而且引起這個發生變化的介面也只有乙個。如果判斷乙個類是過大呢？乙個簡單的辦法就是 這個類中的變數太多了，而且這些變數的含義功能優勢多方面的。出現...
重構 在物件之間搬移特性
1 move method 搬移函式 有個函式與所在類之外的另乙個類進行更多的交流 呼叫或被呼叫 在該函式最常引用的類中建立乙個有著類似行為的新函式。將舊函式變為乙個單純的委託函式，或者將舊函式刪除。2 move field 搬移字段 某個欄位被其所屬類之外的另乙個類頻繁呼叫。3 extract c...