代碼復用
無論是開發哪種軟件產品，成本和時間都是最重要的。較少的開發時間意味著可以比競爭對手更早進入市場。較低的開發成本意味著能夠留出更多的營銷資金，覆蓋更廣泛的潛在客戶。其中，代碼復用是減少開發成本最常用的方式之一，其目的非常明顯，即：與其反復從頭開發，不如在新對象中重用已有的代碼。這個想法表面看起來很棒，但實際上要讓已有的代碼在全新的代碼中工作，還是需要付出額外努力的。組件間緊密的耦合、對具體類而非接口的依賴和硬編碼的行為都會降低代碼的靈活性，使得復用這些代碼變得更加困難。使用設計模式是增加軟件組件靈活性并使其易于復用的方式之一。但是，這可能也會讓組件變得更加復雜。一般情況下，復用可以分為三個層次。在最底層，可以復用類、類庫、容器，也許還有一些類的“團體（例如容器和迭代器）”。框架位于最高層。它們能幫助你精簡自己的設計，可以明確解決問題所需的抽象概念，然后用類來表示這些概念并定義其關系。例如，JUnit是一個小型框架，也是框架的“Hello,world”，其中定義了Test、TestCase和TestSuite這幾個類及其關系。框架通常比單個類的顆粒度要大。你可以通過在某處構建子類來與框架建立聯系。這些子類信奉“別給我們打電話，我們會給你打電話的。”還有一個中間層次。這是我覺得設計模式所處的位置。設計模式比框架更小且更抽象。它們實際上是對一組類的關系及其互動方式的描述。當你從類轉向模式，并最終到達框架的過程中，復用程度會不斷增加。中間層次的優點在于模式提供的復用方式要比框架的風險小。創建框架是一項投入重大且風險很高的工作，模式則能讓你獨立于具體代碼來復用設計思想和理念。擴展性
需求變化是程序員生命中唯一不變的事情。比如以下幾種場景：- 你在Windows平臺上發布了一款游戲，現在人們想要MacOS的版本。
- 你創建了一個使用方形按鈕的GUI框架，但幾個月后開始流行原型按鈕。
- 你設計了一款優秀的電子商務網站，但僅僅幾個月后，客戶就要求新增電話訂單的功能。
每個軟件開發者都經歷過許多相似的故事，導致它們發生的原因也不少。首先，在完成了第一版的程序后，我們就應該做好了從頭開始優化重寫代碼的準備，因為現在你已經能在很多方面更好的理解問題了，同時在專業水平上也有所提高，所以之前的代碼現在看上去可能會顯得很糟糕。其次，可能是在你掌控之外的某些事情發生了變化，這也是導致許多開發團隊轉變最初想法的原因。比如，每位在網絡應用中使用Flash的開發者都必須重新開發或移植代碼，因為不斷地有瀏覽器停止對Flash格式地支持。最后，可能是需求的改變，之前你的客戶對當前版本的程序感到滿意，但是現在希望對程序進行11個“小小”的改動，使其可完成原始計劃階段中完全沒有提到的功能，新增或改變功能。當然這也有好的一面，如果有人要求你對程序進行修改，至少說明還有人關心它。因此在設計程序架構時，有經驗的開發者都會盡量選擇支持未來任何可能變更的方式。