短期的抄近路，可能會在長期導致問題嚴重複雜化。災難往往是由短期未臻最優的決策，長期積累而引起的。許多專案只關心處理眼前的緊迫需求，卻不顧將來的維護。
1、針對介面進行程式設計，而不要針對實現程式設計；
2、優先使用物件組合，而不是類繼承；
3、考慮設計中什麼應該是可以變化的。這種方法與關注引起重新設計的原因剛好相反。它不是考慮什麼會迫使設計發生改變，而是考慮什麼能夠在不引起重新設計的前提下改變。這時主要關注的就是對變化的概念進行封裝，這是許多設計模式的主題。
特化技術最終總是會產生太深的繼承層次。糟糕的是：繼承層次太深將導致程式難以理解（弱內聚）、存在冗餘、難以測試而且多個概念耦合在一起。
嘗試「考慮設計中什麼應該是可以改變的」、「對變化的概念進行封裝」，並且最重要的是「優先使用物件聚集，而不是類繼承」。根據這種方法，應該這樣做：
1、尋找變化，並將它封裝在乙個單獨的類中；
2、將這個類包含在另乙個類中。
將某個變化的行為從使用它的類中移出來，這種過程與資料庫中的規範化過程非常相似，在後一種過程中，需要將移到自己的表中，使用外來鍵引用它們。
《設計模式解析》摘錄（4）
物件 傳統看法 具有方法的資料 從實現的視角來看待物件，太簡單，太膚淺了 新看法 具有責任的實體。這些責任定義了物件的行為 從概念視角出發 關注動機而非實現，使設計模式中反覆出現的主題，因為將實現隱藏在介面之後，實際上是將物件的實現與使用它們的物件解耦了。封裝封裝不僅僅是資料隱藏 封裝應該被視為 任...
《設計模式解析》摘錄（15）
object pool 模式 關鍵特徵 意圖 在建立物件比較昂貴，或者對於特定型別能夠建立的物件數目有限制時，管理物件的重用。解決方案 在需要乙個 reusable 物件時，client 呼叫 reusablepool 的 acquirereusable 方法。如果池是空的，那麼 acquirere...
《設計模式精解》書評摘錄
我買這本書英文本版。這本書比 設計模式 一書容易理解.本書開頭有些章節很精采.bridge 模式講很好。正在看，感覺對設計模式的講解深入淺出，非常適合我等初窺設計模式門徑的人。我花了一周的空餘時間，讀完了此書 如果讓我讀英文原版，恐怕要2周，而且收穫恐怕也不會像現在一樣深刻 感覺書非常適合剛剛學習 ...