1、設計模式:什么是設計模式

設計模式（Designpattern）是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設計經(jīng)驗的總結(jié)。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式于己于他人于系統(tǒng)都是多贏的；設計模式使代碼編寫真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結(jié)構(gòu)一樣。

2、設計模式:什么是設計模式，該如何使用設計模式

設計模式是面向?qū)ο缶幊痰臒衢T話題之一，越來越多的開發(fā)人員認識到設計模式的重要性。采用各種語言實現(xiàn)設計模式的文章也越來越多，但是很多開發(fā)人員發(fā)現(xiàn)很難將設計模式與實際開發(fā)中需要解決的具體問題相聯(lián)系。因為使用設計模式的難點往往不在于模式的實現(xiàn)，而在于很難確定哪種模式可以在現(xiàn)實的應用場景中采用，從而導致了在現(xiàn)實的項目中，面對客戶的壓力，我們總是采用最直截了當?shù)姆椒ń鉀Q問題，來不及多考慮這些方法的優(yōu)劣，即使明知將帶來更大的麻煩也必須如此。有些時候因為選擇了不恰當?shù)脑O計模式，使原本簡單的問題變得復雜化。

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

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

（1）正確理解設計模式

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

（2）編程語言與設計模式的實現(xiàn)

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

（3）需求驅(qū)動

需求驅(qū)動不僅僅是功能性需求，還包括性能需求及運行時的需求，如軟件的可維護性和可復用性等方面。

設計模式是針對軟件設計的，而軟件設計是針對需求的，一定不要為了使用模式而使用模式。在不合適的場合生搬硬套地使用模式反而會使設計應得復雜，使軟件難以調(diào)試和維護。

（4）分析成功的模式應用項目

置之死地而后生可以說是一種解決方案，而不是模式，或者說僅僅給出了模式的實現(xiàn)，而沒有交代使用的場合。項羽采用這個方案把秦軍打敗了，但馬謖卻丟了街亭。

（5）充分了解所使用的開發(fā)平臺。

總的來說，設計模式是針對面向?qū)ο蟮能浖�設計的，因此在理論上適合任何面向?qū)ο蟮恼Z言。但隨著技術的發(fā)展和編程環(huán)境的改善，設計模式的實現(xiàn)方式會有很大的差別。在某些平臺下，某些設計模式是自然實現(xiàn)的，某些模式已經(jīng)被平臺所實現(xiàn)，某些模式存在的上下文已經(jīng)消失。 · · 關注微信公眾號：挪車小黃碼 · 官方免費領�。号曹嚧a，車主雙方虛擬號碼，隱私保護，拒絕騷擾，違章查詢，免費使用！--挪車電話 官網(wǎng)：https://www.nuoche.cc/ · ·

這里的平臺不僅指編程語言，還包括平臺引入的技術。.NET平臺引進了反射、委托，以及屬性等新技術，這些技術的使用使設計模式的實現(xiàn)方式有了很大的改變。例如，工廠方法通過采用反射技術，可以將其中的子類去掉。這實際上已經(jīng)是一個.NET下的新模式，或者說是.NET的方言。

（6）在編程中領悟模式

軟件開發(fā)是一項實踐工作，最直接的方法就是編程。沒有定式很熟卻從來不下棋的圍棋高手，也沒有不會編程就成為架構(gòu)設計師的先例。對設計模式的掌握是水到渠成的事情，你可能是頓悟，也可能是漸悟，但前提是必須有相當?shù)膶嵺`積累。當然，并不是不需要看書學習，但實踐仍然是必須首先要重視的。

認為編程如同寫文章，提高需要有一個過程。在多多編程的同時，需要有一定的技巧。如果希望水平有較大提高，則需要對自己編寫的代碼不斷重構(gòu)。力求**是個很好的習慣，當然前提是項目進度允許。即使項目時間緊張，也需要進行適當?shù)目偨Y(jié)。隔一段時間檢查一下以前的工作，會發(fā)現(xiàn)自己是否已經(jīng)有了提高。

（7）避免設計過度

設計模式解決的是設計不足的問題，但同時也要避免設計過度。一定要牢記簡潔原則(KeepItSimple,Stupid,KISS)，要知道，設計模式是為了使設計簡單，而不是更復雜。如果引入設計模式使設計變得復雜，只能說我們把簡單的問題復雜化了，問題本身不需要設計模式。

這里需要把握的是需求變化的程度，一定要區(qū)分需求的穩(wěn)定篇和可變篇。一個軟件必然有穩(wěn)定的篇，這個篇就是核心業(yè)務邏輯。如果核心業(yè)務邏輯發(fā)生變化，軟件就沒有存在的必要，這個篇的邏輯是我們需要固化的。對于可變的篇，需要判斷可能發(fā)生變化的程度來確定設計策略和設計風險。要知道，設計過度與設計不足同樣對項目有害。

（8）合理看待設計模式的實現(xiàn)實例

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

對模式感興趣的朋友可以從下面的幾個開源項目中學習模式的成功應用。以后可能會把模式在下面幾個開源代碼中的應用的文章與大家共享。