設計模式是面向對象編程的熱門話題之一，越來越多的開發人員認識到設計模式的重要性。采用各種語言實現設計模式的文章也越來越多，但是很多開發人員發現很難將設計模式與實際開發中需要解決的具體問題相聯系。因為使用設計模式的難點往往不在于模式的實現，而在于很難確定哪種模式可以在現實的應用場景中采用，從而導致了在現實的項目中，面對客戶的壓力，我們總是采用最直截了當的方法解決問題，來不及多考慮這些方法的優劣，即使明知將帶來更大的麻煩也必須如此。有些時候因為選擇了不恰當的設計模式，使原本簡單的問題變得復雜化。

??????? 總是有些優秀的設計人員可以在同樣短的時間內做出正確對待的判斷，他們同樣是依靠本能和直覺，只是這種本能是在日常編程開發中一點一滴積累起來的。如同一個劍客在危機時刻的一擊，并不是一時的靈光乍現，而是平時刻苦修煉的結果。

??????? 俗話說，緊靠背棋譜成不了圍棋高手。只在概念上理解設計模式而不實現，同樣成不了架構設計師。在軟件設計時，要有意識地問自己使用還是不使用設計模式，不要匆忙下結論。重視軟件質量的改進，如果有可能，則在項目后期重構代碼。同時注意學習同行的經驗，很多開放源碼項目是值得學習的。

（1）正確理解設計模式
??????? 模式所關注的不僅是重復的解決方案，更主要的是關注重復出現的應用場景和與場景相關的各種作用力。很多使用設計模式失敗的原因，并不是實現設計模式的方法有問題，而是采用的設計模式不適合應用場景。這往往導致設計過度，使軟件應得復雜，進而喪失對使用設計模式的信心。

（2）編程語言與設計模式的實現
?????????盡管設計模式本身并不要求一定用某種語言來實現，但脫離了具體的實現，就無法真正理解設計模式。GOF的《設計模式》是經典之作，但畢竟距現在已經十幾年了。這個期間開發平臺已經進化了多代，很多新技術已經應用到編程中。有些技術可以簡化設計模式的實現，有些技術已經采用了設計模式。因此，學習設計模式必須針對所使用的編程語言和開發平臺。一定要注意，不是將《設計模式》中的例子轉換為C#或者其他語言就等于知道如何實現設計模式了，而是要關注設計模式的精髓，并結合具體的語言特點完成其實現。就.NET而言，很多技術可以簡化設計模式的實現，例如采用反射技術實現工廠和采用委托技術實現模板方法等。

（3）需求驅動
??????? 需求驅動不僅僅是功能性需求，還包括性能需求及運行時的需求，如軟件的可維護性和可復用性等方面。
??????? 設計模式是針對軟件設計的，而軟件設計是針對需求的，一定不要為了使用模式而使用模式。在不合適的場合生搬硬套地使用模式反而會使設計應得復雜，使軟件難以調試和維護。
???
（4）分析成功的模式應用項目
??????? 對現有的應用實例進行分析是學習模式的一個很好的途徑，應當注意學習已有的項目不僅是學習設計模式如何實現，更重要的是注意在什么場合使用設計模式。
??????? “置之死地而后生”可以說是一種解決方案，而不是模式，或者說僅僅給出了模式的實現，而沒有交代使用的場合。項羽采用這個方案把秦軍打敗了，但馬謖卻丟了街亭。

（5）充分了解所使用的開發平臺。
??????? 總的來說，設計模式是針對面向對象的軟件設計的，因此在理論上適合任何面向對象的語言。但隨著技術的發展和編程環境的改善，設計模式的實現方式會有很大的差別。在某些平臺下，某些設計模式是自然實現的，某些模式已經被平臺所實現，某些模式存在的上下文已經消失。
??????? 這里的平臺不僅指編程語言，還包括平臺引入的技術。.NET平臺引進了反射、委托，以及屬性等新技術，這些技術的使用使設計模式的實現方式有了很大的改變。例如，工廠方法通過采用反射技術，可以將其中的子類去掉。這實際上已經是一個.NET下的新模式，或者說是.NET的“方言”。

（6）在編程中領悟模式
??????? 軟件開發是一項實踐工作，最直接的方法就是編程。沒有定式很熟卻從來不下棋的圍棋高手，也沒有不會編程就成為架構設計師的先例。對設計模式的掌握是水到渠成的事情，你可能是“頓悟”，也可能是“漸悟”，但前提是必須有相當的實踐積累。當然，并不是不需要看書學習，但實踐仍然是必須首先要重視的。
??????? 認為編程如同寫文章，提高需要有一個過程。在多多編程的同時，需要有一定的技巧。如果希望水平有較大提高，則需要對自己編寫的代碼不斷重構。力求最優是個很好的習慣，當然前提是項目進度允許。即使項目時間緊張，也需要進行適當的總結。隔一段時間檢查一下以前的工作，會發現自己是否已經有了提高。

（7）避免設計過度
??????? 設計模式解決的是設計不足的問題，但同時也要避免設計過度。一定要牢記簡潔原則(Keep It Simple, Stupid, KISS)，要知道，設計模式是為了使設計簡單，而不是更復雜。如果引入設計模式使設計變得復雜，只能說我們把簡單的問題復雜化了，問題本身不需要設計模式。
??????? 這里需要把握的是需求變化的程度，一定要區分需求的穩定篇和可變篇。一個軟件必然有穩定的篇，這個篇就是核心業務邏輯。如果核心業務邏輯發生變化，軟件就沒有存在的必要，這個篇的邏輯是我們需要固化的。對于可變的篇，需要判斷可能發生變化的程度來確定設計策略和設計風險。要知道，設計過度與設計不足同樣對項目有害。

（8）合理看待設計模式的實現實例
??????? 現在，從各種途徑可以發現各種設計模式的實現實例。需要說明的是，其中很多實例所說明的僅僅是設計模式的解決方案的實現，并沒有分析模式使用的上下文。實際上，這也是最困難的篇——從而導致實例中的設計模式使用從實踐的角度看，往往是過度設計，也就是有小題大做的嫌疑。

??????? 對模式感興趣的朋友可以從下面的幾個開源項目中學習模式的成功應用。以后可能會把模式在下面幾個開源代碼中的應用的文章與大家共享。
??????????????????????????? NUnit:.net：單元測試平臺,采用c#編寫
??????????????????????????? DotNetNoke：vb.net寫的Portal Web
??????????????????????????? Gentle：對象持久化工具,采用C#
??????????????????????????? Log4net：日志記錄工具,采用C#

總結

以上是生活随笔為你收集整理的如何掌握并在实践中自如运用设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。