設計模式一直飽受爭議，很多人對設計模式推崇備至，但也有很多人認為設計模式誤導了程式設計者，見（《解密「設計模式」》）。
一、這是些什麼亂七八糟的東西？那時候聽到了設計模式的概念，到圖書館借了一本大概名字叫《設計模式初學者入門》之類的書。書裡就把23個設計模式 挨個講了一遍，引用一下每個設計模式的定義，給個類圖，配點**……然後我硬著頭皮讀完之後，就乙個感覺，「脫了褲子放屁」。乙個功能，明明很簡單、很直 接的就能實現，為什麼要添那麼多的類，繞那麼多的彎？記得當時也就懂了「單例模式」。
二、後來又找其他的書，這時候我讀到了程杰的《大話設計模式》，其中用活字印刷的例子，講解了曹操「對酒當歌，人生幾何」的敢動，我彷彿一下子就開 竅了。明白了設計模式，他最重要的目的就是為了應對「變化」。所以回過頭來看，為什麼之前能懂「單例模式」，就因為「單例模式」的目標很清晰，所以很好 懂；反之，其他的設計模式，目標比較「複雜」，所以我懂不了。
三、但僅僅知道了設計模式的目標，還是沒有解決我的疑惑。我記得當時我心裡反反覆覆的乙個問題，「有變化，改**就行了呀。怎麼改都是改，為什麼就 一定要想你（設計模式）說的那樣改呢？」那時候我基本上是單兵作戰，**是自己乙個人從頭寫到腳，**有問題我就可以改**，完全沒有心理負擔，呵呵。後 來工作變動，開始了團隊開發、維護別人的**，以及使用第三方組建。我就自然而然的明白了，有些**，是你只能用不能改的！典型的就是人家只給你乙個已經 編譯的dll，你怎麼改？坑爹呀！所以，那時候，我最先明白的就是adapter模式，為什麼要用adapter？因為介面不一致，你不使用 adapter就用不了第三方的**！
四、如果說上面這個階段是「迫不得已」的使用設計模式，接下來就是我開始主動的思考和使用設計模式了。我有差不多一年的時間都是在維護公司遺留下來 的老**——足以讓人崩潰的**！每一次的bug fix，都不得不小心翼翼、如履薄冰，即使如此，仍然有很多次的改動，都是「按下了葫蘆浮起了瓢」。讓我充分的意識到什麼叫「緊耦合」、「壞味道」，我們 會有計畫的做一些重構，在這些過程中，我都會主動的思考，能不能套用某種設計模式（但沒有一次成功，老大不讓，擔不起責任呀——系統太老太大太脆弱，你懂 的！呵呵）
五、真正的理解設計模式的核心思想。我認為我目前仍然沒有達到這個程度，雖然可以隨口說出一些耳熟能詳的設計原則，「高內聚、低耦合」，「對擴充套件開 放，對修改關閉」，「優先使用聚合」之類的。但理解仍然不深，很多時候覺得這也可那也可，拿不定主意。我覺得這是我**寫得太少的原因，需要在更多的實踐 中體會提高。
看完這些，你肯定知道，我對學習設計模式是持支援肯定態度的。那麼，下面和同學們交流一下學習設計模式的方法吧。
一、實踐。記得金旭亮老師曾經說過，「沒有寫過10萬行**，不要談設計模式」，可能有點誇張，但道理是棒棒的。比如我，如果沒有不得不深入到那些 足夠複雜足夠混亂的**，身心飽受摧殘，不可能對設計模式的認識有質的提高。因為設計模式的乙個重要應用場景，是應付那些複雜的業務邏輯、快速的需求變 化，她的價值在這些地方，才能夠清晰的體現出來。「坐而論道」是一種我們都期望的「懶人模式」，但估計很難有效——至少對於我這種資質平庸的人來說吧。
二、明白設計模式的目的。每乙個設計模式，一定是要解決一定的問題的；並且解決這些問題是附帶了條件的。比如，需求發生了變更，這是問題。如果沒有 其他約束，解決這個問題的辦法很簡單，就是改**而已，加上乙個if...else而已。但是，我們不能這些改！（理解這一點相當重要，切記切記。當然， 你可能會問，為什麼不能這麼改呢？我們下面再說）我們不能修改類裡面的**，我們只能採取一些其他手段，比如繼承、比如封裝原有類，來實現新需求。這時 候，設計模式就粉墨登場了。
三、上面所說，為什麼不能直接改類裡面的方法函式，比如直接加if...else？我們可以從兩方面理解。一方面是「被動的」，比如我們是引用的一 個編譯了的dll，根本就改不了；或者是團隊開發，別人不允許你改他們寫好的類。另一方面是「主動的」，接前面「團隊開發，別人不允許你改他們寫好的 類」，為什麼他們不允許你改呢？是不是他們固執、偷懶，沒有團隊精神？你把官司打到大boss那裡，可能會被一頓k。你需要仔細的體會，「類」的概念。類 就是一種封裝，封裝就意味著拒絕修改——想一想為什麼會有private關鍵字吧。好了，就不在這裡展開了，不然又要寫一本書了。你只需首先明白，設計模式，是一種「帶著腳鐐的舞蹈」；然後進一步思考，為什麼需要這些腳鐐即可。（當然，如果你夠牛b，這些最終砸碎這些腳鐐，不在此**範疇）
最後，我還是強調「實踐」，如果想要更好的理解第二條、第三條，唯一有效的方法，可能就是實踐了（前提是你已經或多或少的研究過設計模式了）。
學習設計模式 原型設計模式
先想一下既然要建立新的例項，為什麼不直接使用 new 而要設計出乙個原型模式進行例項的複製呢？這是因為 有的時候，我們也會在不指定類名的前提下生成例項，例如像圖形編輯器中拖動現有的模型工具製作圖形的例項，這種是非常典型的生成例項的過程太過複雜，很難根據類來生成例項場景，因此需要根據現有的例項來生成新...
設計模式學習
知道設計模式已經很久了，但是一直沒有認真的去系統的學習，這幾天才開始逐漸的學習起來。下面是我學習設計模式的一些心得。要想成為一名優秀的軟體設計師或軟體架構設計師，了解一些設計模式是很有必要的。我認為學習設計模式的思路如下 一 基本概念 理解物件導向 理解重用等概念性的東西 1.什麼是物件導向？2.物...
設計模式學習
所有的設計模式都是為了解決變化的問題，通過一定的模式來應對變化，變化應對的原則是開放封閉原則，對修改封閉，對擴充套件開放。為了應對變化，就會新增相應的層次，層次越多，的顆粒就越小，那麼 就越複雜。所以設計時考慮變化和複雜之間的取捨，為了應對變化 需要使用模式，但是又不可以一味應用模式，導致 太複雜。...