既然我稱之為誤導（mislead），自然是有一些感想和思考的。之于前者，我的觀點依舊是“道不遠人”，設計模式就是面向對象分析和設計OOA/D中的“道”。設計模式的最終體現應該是一種思想，一種指導。而這種思想，這種指導，則正是我們在OO系統開發中所必需的。設計模式之所以會被人認為高深，很大的一個原因在于設計模式是一種設計層面上的技術（思想），而設計在目前很多的企業和公司經常被忽視或者輕視了。在我看來，設計模式中描述的各類模式，實在和面向對象的基本思想（封裝、繼承、多態）是如出一轍，只不過設計模式很多情況下會強調怎樣通過OO中的多態、繼承獲得更大的工業級的復用、維護和擴展。原因也很簡單，兩者都是OO的一部分，不曾沖突，而是相得益彰。一個單純的編碼人員需不需要學習掌握設計模式？我們是否可以得享清凈？在我看來，每個從事OO系統開發和設計的從業人員，都應該學習掌握設計模式，不過可能側重點可能可以不一樣：設計人員或更高抽象層次可以更多關注設計模式的使用場景和應用效益，而編碼實現人員則需要更多關注設計模式的實現方法。設計模式的學習過程是一個非常痛苦并且不會短暫（至少我這樣認為）的過程，但是這是必需的。而這個過程中獲得最多的正是對于OO設計的一種潛移默化，這種潛移默化的效果則會直接體現在我們以后的面向對象系統的分析和設計中去。
之于后者，后者這種觀點的存在是很有實際基礎的。誠然，在我們身邊，甚至是自己身上、自己正在經歷的項目開發中，唯一的目標就是系統的運行（work）。我們會給開發的目標按照優先級派一個順序：1）可工作（work）；2）穩定（robust）；3）性能（performance）；4）擴展（expansibility）；5）復用（reuse）。而設計模式更多關注的正是擴展性和復用，似乎更多的時候我們可以完全不必考慮什么設計模式。但是有一點我們是忽略了，那就是用戶的需求變更，而這一點在我們身邊的、自己身上、或是正在體驗著的就是用戶無休止的需求變化。小的變更，可能我們可以充當救火隊長，四處打補丁完事，然而很多情況下用戶簡單的一個需求變化要引起我們設計的變化，那就不是簡單補丁可以完事了。死亡（death）、稅收（tax）和需求變更（requirement variation）被稱之為程序員的3大罩門，因此在系統的設計之初作一些必需的擴展性考慮以及適當的需求變更策略是很有必要的，很多事情并不是像我們第一眼想象的那么簡單。然而過度設計也是在開發中的一個非常忌諱的事情，本來就很復雜的東西，何必要復雜之中讓它更加復雜，濫用技術是不可取的，這個度的控制則真正是很深的學問和經驗了。說了這么多，只是說明設計模式是必要的，即使在小的系統開發之中也是有價值存在的。我手頭正在進行和技術負責的一個不是很大的項目中，不同的模塊沒有能夠很好統一（原因同道中人自然了然于心：）），更多的都是一個類搞定一切。似乎一切也都OK，但是我使用Bridge模式將抽象和實現解耦，通過Decorator模式動態添加需求，模塊設計簡約合理，并且我可以保證在一般的用戶變更可以從容應付。而這一切也不是說要很高深的技術，只是需要一個合理的思想來指導。因此也在另外一個角度說明，設計模式的思想是值得我們去采用的。
然而，說總是讓人覺得煞有介事，但是卻讓人覺得不著實際。之前曾用C++將GoF描述的23種設計模式寫一遍（共享了源碼和解析，可以下載PDF文檔參考），也對設計模式進行了研習和思考的探索，并在經歷的一些項目和開發中使用了其中的一些具體的模式或者思想，因此準備將這些經歷和經驗也記錄下來。再加上分析經典系統源碼的經驗，名字叫做《在開發中體驗設計模式》，也算是給自己的一個任務和要求，我希望自己能夠有足夠的時間和精力來完成。
文章來源于領測軟件測試網 http://www.kjueaiud.com/