3.11.平行繼承體系（Parallel Inheritance Hierarchies）

3.12.冗贅類（Lazy Class）

如果重構使得類的身價嚴重縮水，不再做那麼多工作。或者，開發者事前規劃了某些變化，並新增一個類來應付這些變化，但變化實際為發生。請刪除這些類。

如果某些子類沒有足夠的工作，試試 Collapse Hierarchy.對於幾乎沒用的元件，你應該以Inline Class對付它們。

3.13.誇誇其談未來性（Speculative Generality）

3.14.令人迷惑的暫時欄位（Temporary Field）

3.15.Message Chains（過度耦合的訊息鏈）

3.16.中間人（Middle Man）

3.17.狎暱關係 (Inappropriate Intimacy）

過分狎暱的類必須拆散。可以採用Move Method和Move Field幫它們劃清界限，以減少狎暱行為。也可以看看是否可以運用 Change Bidirectional Association to Unidirectional讓其中一個類對另一個類斬斷情絲。如果兩個類實在情投意合，可以運用Extract Class把兩者共同點提煉的一個安全地點，讓他們坦蕩的使用這個新類。或者也可以嘗試運用Hide Delegate讓另一個類來為它們傳遞相思情。

繼承往往過度親密，因為子類對超類的瞭解往往超過後者的主觀願望。如果你覺得該讓孩子獨自生活了，請運用Replace Inheritance with Delegation讓它離開繼承體系。

3.18.異曲同工的類（Alternative Classes with Different Interfaces）

3.19.不完美的庫類（Incomplete Library Class）

3.20.純稚的資料類（Data Class）

3.21.被拒絕的遺贈（Refused Bequest）

3.22.過多的註釋（Comments）

如果需要註釋解釋一快程式碼做了什麼，試試Extract Method；如果函式已經提煉出來了，還需要註釋解釋其行為，試試Rename Method；如果你需要註釋說明某些系統的需求規格，試試Introduce Assertion。

當你感覺需要註釋程式碼時，請先嚐試重構，試著讓所有註釋都變得多餘。完成重構之後常常會發現，註釋已經變得多餘，因為程式碼已經清楚說明了一切。

如果不知道該做什麼，這才是註釋的良好運用時機。除了用來記述將來的打算之外，註釋還可以用來標記你並無十足把握的區域。你可以在註釋裡寫下自己“為什麼做某某事”。這類資訊可以幫助將來的修改者，尤其那些健忘的傢伙。