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