我學習設計模式的一些所想所得

我也隻是一個普通的程式設計人員，這裡隻能談一談我在學習設計模式中的一些想法，不一定正确，歡迎大家談論。我對設計模式的了解是分階段的：

一、這是些什麼亂七八糟的東西？那時候聽到了設計模式的概念，到圖書館借了一本大概名字叫《設計模式初學者入門》之類的書。書裡就把23個設計模式挨個講了一遍，引用一下每個設計模式的定義，給個類圖，配點代碼……然後我硬着頭皮讀完之後，就一個感覺，“脫了褲子放屁”。一個功能，明明很簡單、很直接的就能實作，為什麼要添那麼多的類，繞那麼多的彎？記得當時也就懂了“單例模式”。

二、後來又找其他的書，這時候我讀到了程傑的《大話設計模式》，其中用活字印刷的例子，講解了曹操“對酒當歌，人生幾何”的敢動，我仿佛一下子就開竅了。明白了設計模式，他最重要的目的就是為了應對“變化”。是以回過頭來看，為什麼之前能懂“單例模式”，就因為“單例模式”的目标很清晰，是以很好懂；反之，其他的設計模式，目标比較“複雜”，是以我懂不了。

三、但僅僅知道了設計模式的目标，還是沒有解決我的疑惑。我記得當時我心裡反反複複的一個問題，“有變化，改代碼就行了呀。怎麼改都是改，為什麼就一定要想你（設計模式）說的那樣改呢？”那時候我基本上是單兵作戰，代碼是自己一個人從頭寫到腳，哪裡有問題我就可以改哪裡，完全沒有心理負擔，呵呵。後來工作變動，開始了團隊開發、維護别人的代碼，以及使用第三方組建。我就自然而然的明白了，有些代碼，是你隻能用不能改的！典型的就是人家隻給你一個已經編譯的dll，你怎麼改？坑爹呀！是以，那時候，我最先明白的就是Adapter模式，為什麼要用Adapter？因為接口不一緻，你不使用Adapter就用不了第三方的代碼！

四、如果說上面這個階段是“迫不得已”的使用設計模式，接下來就是我開始主動的思考和使用設計模式了。我有差不多一年的時間都是在維護公司遺留下來的老代碼——足以讓人崩潰的代碼！每一次的bug fix，都不得不小心翼翼、如履薄冰，即使如此，仍然有很多次的改動，都是“按下了葫蘆浮起了瓢”。讓我充分的意識到什麼叫“緊耦合”、“壞味道”，我們會有計劃的做一些重構，在這些過程中，我都會主動的思考，能不能套用某種設計模式（但沒有一次成功，老大不讓，擔不起責任呀——系統太老太大太脆弱，你懂的！呵呵）

五、真正的了解設計模式的核心思想。我認為我目前仍然沒有達到這個程度，雖然可以随口說出一些耳熟能詳的設計原則，“高内聚、低耦合”，“對擴充開放，對修改關閉”，“優先使用聚合”之類的。但了解仍然不深，很多時候覺得這也可那也可，拿不定主意。我覺得這是我代碼寫得太少的原因，需要在更多的實踐中體會提高。

看完這些，你肯定知道，我對學習設計模式是持支援肯定态度的。那麼，下面和同學們交流一下學習設計模式的方法吧。

一、實踐。記得金旭亮老師曾經說過，“沒有寫過10萬行代碼，不要談設計模式”，可能有點誇張，但道理是棒棒的。比如我，如果沒有不得不深入到那些足夠複雜足夠混亂的代碼，身心飽受摧殘，不可能對設計模式的認識有質的提高。因為設計模式的一個重要應用場景，是應付那些複雜的業務邏輯、快速的需求變化，她的價值在這些地方，才能夠清晰的展現出來。“坐而論道”是一種我們都期望的“懶人模式”，但估計很難有效——至少對于我這種資質平庸的人來說吧。

二、明白設計模式的目的。每一個設計模式，一定是要解決一定的問題的；并且解決這些問題是附帶了條件的。比如，需求發生了變更，這是問題。如果沒有其他限制，解決這個問題的辦法很簡單，就是改代碼而已，加上一個if...else而已。但是，我們不能這些改！（了解這一點相當重要，切記切記。當然，你可能會問，為什麼不能這麼改呢？我們下面再說）我們不能修改類裡面的代碼，我們隻能采取一些其他手段，比如繼承、比如封裝原有類，來實作新需求。這時候，設計模式就粉墨登場了。

三、上面所說，為什麼不能直接改類裡面的方法函數，比如直接加if...else？我們可以從兩方面了解。一方面是“被動的”，比如我們是引用的一個編譯了的dll，根本就改不了；或者是團隊開發，别人不允許你改他們寫好的類。另一方面是“主動的”，接前面“團隊開發，别人不允許你改他們寫好的類”，為什麼他們不允許你改呢？是不是他們固執、偷懶，沒有團隊精神？你把官司打到大BOSS那裡，可能會被一頓K。你需要仔細的體會，“類”的概念。類就是一種封裝，封裝就意味着拒絕修改——想一想為什麼會有private關鍵字吧。好了，就不在這裡展開了，不然又要寫一本書了。你隻需首先明白，設計模式，是一種“帶着腳鐐的舞蹈”；然後進一步思考，為什麼需要這些腳鐐即可。（當然，如果你夠牛B，這些最終砸碎這些腳鐐，不在此探讨範疇）

最後，我還是強調“實踐”，如果想要更好的了解第二條、第三條，唯一有效的方法，可能就是實踐了（前提是你已經或多或少的研究過設計模式了）。