頭幾天閑著，睡覺前就重新翻了一下之前看過的一本書《設計模式解析》（原來看的是英文版，這次看的是中文版的，翻譯的有點...看起來挺累～_～。大家如果看，還是選原版的吧）。總覺得看到兩位作者（Alan Shalloway; James R.Trott ）好像試圖推薦一種自己的方法論：基于模式進行分析和設計。想來想去，有點自己的想法，寫出來，歡迎討論。
【設計模式是一個工具】
首先說明，本人設計經驗不是很多，而且一般也只是局限于模塊級的，所以，以下內容全部是亂彈琴了。
設計模式是一個工具，而且僅僅是個工具。為什么這么說呢？個人覺得，我們一般進行設計的時候，最關鍵的三點應該是：需求分析結果、基本的OO設計原則和特定領域的經驗（例如行業解決方案等）。例如我舉這么一個例子，開閉原則（對擴展開放、對修改關閉）大家應該是很熟了，所以經常我們在設計一個模型層次的時候，這個時候腦子中哪來的什么設計模式啊，我們可能只想著將抽象層面的概念暴露出來，把實現層面的東西盡量隱藏在模塊內部，而且也希望用戶來擴展這種模型。所以很自然的做了模型的分層，上層是抽象層接口，對外暴露，同時暴露的還有一些公共抽象基類，供其他人擴展模型使用；下層是擴展實現，不需要對外暴露。
到這里，相當于我們設計的模塊的模型已經基本固定了，現在就是如何實現這種設計初衷了。這個時候想到一個重要的工具，那就是設計模式。例如我們的模型分為了抽象接口層和實現層，我們如何支持既聯系又獨立變化呢？Bridge。 例如我們的模型看起來是樹狀的，怎么來封裝呢？Composite。 例如我們的模型之上可能又很多操作需要支持，我們想把這種操作和數據模型本身做松耦合拆分？Visitor。我們想把模型的構建和模型類類型定義做拆分，因為我們可能覺得用戶來構造這種數據模型節點可能很負責？Factory、Builder。...我想這類的問題有很多，無非就是在具體實現設計，用設計模式做個工具而已。而我們前面的需求分析、基本OO原則進行模塊整體處理等等，都是設計模式層面之上的東西。
說到這里，我一直覺得設計模式就是個工具，而且是個后期實現設計的工具，不是前期主導設計的工具。
【基于模式進行分析和思考】
主要有如下幾個疑問：
1、設計模式的過早引入，會不會導致開發者過多的關注于實現了呢？？？我們知道，如果進行模塊級別或者更高級別的代碼框架編寫，腦子里過早過多的闖入了實現細節，那不是會導致基于實現細節的思考來寫抽象層面的框架代碼？？？這樣，代碼還有核心的框架嗎？？？
2、無容置疑，設計模式含有使用場景的經典濃縮，我們的需求肯定和這些場景有重疊的地方。但是，我們在整體考慮一個模塊層面的設計的時候，應該更多的是由基本設計原則來確定，希望這個模塊長成什么樣子，而不是去這個模塊怎么長成這個樣子。這可能類似于一個女的去整容，她對自己的需求整理的半天，同時又不想違反基本規則挑戰審美極限，最終去定下來：胸不要太大，胸形漂亮點，想明星***。接著醫生進來了，用一些工具或者藥物幫她實現了。 哈哈 ^_^
3、讓設計模式更早一點的進入分析和設計，是不是需要對相應人員要求太高呢？既能借鑒設計模式中的場景來幫助思考，又能避免過于面向實現細節來設計。當然，高手是狂多的～_～
4、是否很容易造成設計模式的過度使用呢？導致代碼框架在設計模式不自然的用法的基礎之上機械堆砌起來的，對同事提出了很大的挑戰呢....同時，也有可能將很大一部分注意力轉移到了如何使用設計模式上了，帶著有色眼睛去看需求，滿眼都是設計模式...
PS：以上說的很多是個人一些疑問，絕對沒有貶低設計模式的意思。歡迎高手前來討論 ~_~
本博客中的所有文章、隨筆除了標題中含有引用或者轉載字樣的，其他均為原創。轉載請注明出處，謝謝！