設計模式不是為每個人準備的，而是基于業務來選擇設計模式，需要時就能想到它。要明白一點，技術永遠為業務服務，技術只是滿足業務需要的一個工具。我們需要掌握每種設計模式的應用場景、特征、優缺點，以及每種設計模式的關聯關系，這樣就能夠很好地滿足日常業務的需要。 許多設計模式的功能類似，界限不是特別清楚（為了能讓大家更好的理解，每個章節后面都列出了類似功能設計模式之間的對比）。大家不要疑惑，設計模式不是為了特定場景而生的，而是為了讓大家可以更好和更快地開發。 設計模式只是實現了七大設計原則的具體方式，套用太多設計模式只會陷入模式套路陷阱，最后代碼寫的凌亂不堪。 在實際工作中很少會規定必須使用哪種設計模式，這樣只會限制別人。不能為了使用設計模式而去做架構，而是有了做架構的需求后，發現它符合某一類設計模式的結構，在將兩者結合。 設計模式要活學活用，不要生搬硬套。想要游刃有余地使用設計模式，需要打下牢固的程序設計語言基礎、夯實自己的編程思想、積累大量的時間經驗、提高開發能力。目的都是讓程序低耦合，高復用，高內聚，易擴展，易維護。 #### 1\. 需求驅動 不僅僅是功能性需求，需求驅動還包括性能和運行時的需求，如軟件的可維護性和可復用性等方面。設計模式是針對軟件設計的，而軟件設計是針對需求的，一定不要為了使用設計模式而使用設計模式，否則可能會使設計變得復雜，使軟件難以調試和維護。 #### 2\. 分析成功的模式應用項目 對現有的應用實例進行分析是一個很好的學習途徑，應當注意學習已有的項目，而不僅是學習設計模式如何實現，更重要的是注意在什么場合使用設計模式。 #### 3\. 充分了解所使用的開發平臺 設計模式大部分都是針對面向對象的軟件設計，因此在理論上適合任何面向對象的語言，但隨著技術的發展和編程環境的改善，設計模式的實現方式會有很大的差別。在一些平臺下，某些設計模式是自然實現的。 不僅指編程語言，平臺還包括平臺引入的技術。例如，Java EE 引入了反射機制和依賴注入，這些技術的使用使設計模式的實現方式產生了改變。 #### 4\. 在編程中領悟模式 軟件開發是一項實踐工作，最直接的方法就是編程。沒有從來不下棋卻熟悉定式的圍棋高手，也沒有不會編程就能成為架構設計師的先例。掌握設計模式是水到渠成的事情，除了理論只是和實踐積累，可能會“漸悟”或者“頓悟”。 #### 5.避免設計過度 設計模式解決的是設計不足的問題，但同時也要避免設計過度。一定要牢記簡潔原則，要知道設計模式是為了使設計簡單，而不是更復雜。如果引入設計模式使得設計變得復雜，只能說我們把簡單問題復雜化了，問題本身不需要設計模式。 這里需要把握的是需求變化的程度，一定要區分需求的穩定部分和可變部分。一個軟件必然有穩定部分，這個部分就是核心業務邏輯。如果核心業務邏輯發生變化，軟件就沒有存在的必要，核心業務邏輯是我們需要固化的。對于可變的部分，需要判斷可能發生變化的程度來確定設計策略和設計風險。要知道，設計過度與設計不足同樣對項目有害。 > 學習設計模式，死記硬背是沒用的，還要從實踐中理解，本教程后面會結合實例和源碼來講解如何使用設計模式。