原來不經(jīng)常逛技術(shù)論壇，最近閑著看的比較多一點，看到了相當(dāng)?shù)膬?nèi)容是在討論設(shè)計模式的東西。今天，也閑侃一下
1、設(shè)計模式的角色是什么？ 工具而已，而且不是一個很高級的工具，更不是一個全能的工具。什么時候決定使用設(shè)計模式呢，有需求，是你決定好了要干什么，接著才考慮怎么去實現(xiàn)它，讓設(shè)計模式幫你去實現(xiàn)！！！舉個例子，例如你要做的系統(tǒng)中的某個模塊，基于的數(shù)據(jù)來自于xml文件，思考之后，你需要基于xml文件去建立你的業(yè)務(wù)模型對象。那怎么合理的來封裝這種實現(xiàn)呢？ 這個時候，你可能自然地去選擇用Composite模塊去封裝這種樹狀類型體系。 那你接著會看到，這個樹形對象的構(gòu)造挺繁瑣的，你不希望用戶去完成這些工作，那么你可能會想到去封裝這種實例化過程，各種創(chuàng)建型模式選擇之后，你可能選擇了工廠模式。 數(shù)據(jù)有了，你可能接下來去實現(xiàn)核心的業(yè)務(wù)行為了，相當(dāng)多的業(yè)務(wù)行為是基于前面你封裝的樹性對象結(jié)構(gòu)之上。 你寫的行為多了之后，你可能覺得數(shù)據(jù)結(jié)構(gòu)本身和這么多行為沾粘在了一起，你可能想，干脆將它們分開算了（雖然這樣有點打破封裝），怎么很好的分開呢？ 這個時候你可能自然的去用了vistor模式...
2、如何去大致評估設(shè)計模式是否被正確使用了呢？ 個人的經(jīng)驗是從需求、設(shè)計原則、設(shè)計模式本身兩個層面來判斷。所謂需求來判斷，就是你使用這個設(shè)計模式是否在解決實際需求，是否是為了設(shè)計模式而設(shè)計模式。例如你可能用某個模式是為了以后更容易擴展，那么你看了，你的這種需求是真的存在的嗎？哪怕真的存在，需求有那么大嗎？ 所謂的基于設(shè)計原則判斷，則是從技術(shù)角度在宏觀上做個評審～_～。例如直覺告訴你抽象層面的東西和實現(xiàn)層面的東西耦合在一塊了，例如你設(shè)計了一個狂大的接口等等... 設(shè)計模式的不恰當(dāng)使用，會使得代碼變得更加不優(yōu)雅，也會增加很多不必要的復(fù)雜度。 所謂從設(shè)計模式本身來判斷，則是以技術(shù)視角去審核一下你用這個模式的場景和模式本身使用的創(chuàng)建是否有差異，基本上每個模式的使用都會引來一些對應(yīng)的副作用，那么你要看一下這種副作用恰恰是你所不能接受的...
3、如果你是單純的在設(shè)計階段，設(shè)計模式能幫助你什么呢？ 個人經(jīng)驗，無論是處在那個設(shè)計階段，對設(shè)計模式有較好的理解會有助你設(shè)計的時候思考問題，甚至更好的幫助你將業(yè)務(wù)需求轉(zhuǎn)換為技術(shù)需求，并合理的處理這些技術(shù)需求，進(jìn)一步轉(zhuǎn)為具體的設(shè)計方案。但是要注意是有助于，絕對不是基于設(shè)計模式。 例如做概要設(shè)計的時候，精力還是集中在模塊劃分、模塊提供的主要服務(wù)、模塊之間的交互方式等。 進(jìn)行詳細(xì)設(shè)計的時候，設(shè)計模式扮演的角色才會稍微更重一點。設(shè)計階段滿腦子設(shè)計模式，你可能會有兩個下場：一是過度設(shè)計，而是錯誤設(shè)計。
4、設(shè)計模式和重構(gòu)？ 設(shè)計模式基本上可以理解為是一個代碼級別的設(shè)計工具，同時也是重構(gòu)時候的較為高級的手段。具體的，建議有時間可以看一下《重構(gòu)與模式》，可能會有點體會。重構(gòu)在一定程度上可以修正設(shè)計不足（個人覺得僅僅是一定程度），也能修理掉過度設(shè)計。
5、設(shè)計模式在學(xué)習(xí)過程中處于什么階段？ 個人覺得基本上是如下路線：基礎(chǔ)知識、具體開發(fā)語言、語言層面技巧、設(shè)計模式、設(shè)計原則....(俺就是一個寫代碼的，再往下實在是不會了，更高層次的方法論沒有接觸過^_^) 學(xué)習(xí)的手段可以分為：經(jīng)典書籍、實踐經(jīng)驗、高手教誨等等。 國內(nèi)作者寫的書有時間可以撒兩眼（不是說高手少，而是高手一般可能不會去寫書，丟不起那人^_^），沒時間就算了，要讀就讀經(jīng)典。 實踐經(jīng)驗是無論如何無法取代的，保證認(rèn)真地態(tài)度去寫代碼，寫的時候瞎想想，見到好的代碼模仿模仿。 高手教誨就不用說了，如果你的團隊中有經(jīng)驗老練的高手，那你非常幸運，成天不恥下問吧。 基礎(chǔ)不扎實，會導(dǎo)致典型的就設(shè)計模式而設(shè)計模式，這種人論壇上還很多的。 沒接觸設(shè)計模式的時候，你感覺寫代碼很流利；接觸一些后，你肯定會覺得自己滿腦子設(shè)計模式，不會寫代碼了，寫的時候老想著是否該用這個模式或者該用那個模式...；再過一段時間，基于設(shè)計模式的使用經(jīng)驗和理解增多，你有會比較流利，你會有點自豪，覺得你是和大部分在不同層面上寫代碼； 再過一段時間，你可能會接觸一些設(shè)計原則的東西，你有麻煩了，又覺得肯能不怎么會寫代碼了，因為你腦子里想著很多松耦合、基于接口、開閉等等東西，老懷疑你設(shè)計模式用的對嗎，要不干脆不用了....； 再過一段時間，應(yīng)該會恢復(fù)了，你可能又會有點自豪了，你會覺得你用模式是在設(shè)計原則指導(dǎo)之下使用的，而且這個時候你會覺得設(shè)計模式可以用的很活，多個模式之間的配合等等也是很自然的事情，因為這個時候你腦子想的更多的是設(shè)計模式對應(yīng)的場景和副作用等等，而不是之前滿腦子設(shè)計模式相關(guān)的實現(xiàn)細(xì)節(jié)了
6、設(shè)計模式真的能成為寫代碼的人之間的交流語言？ 如果能這樣，你可能在一個素質(zhì)很高的團隊，羨慕你，實在是羨慕你！！！ 一般別抱這種幻想，也別去強迫其他人使用設(shè)計模式，否則你可能會挨罵^_^。我的感覺是與其讓我遇到一個連設(shè)計模式都沒有聽說過的人，也不希望遇到一個滿口設(shè)計模式去不會真正用設(shè)計模式的人，那是很折磨人的^_^
7、。。。。
8、。。。。
本博客中的所有文章、隨筆除了標(biāo)題中含有引用或者轉(zhuǎn)載字樣的，其他均為原創(chuàng)。轉(zhuǎn)載請注明出處，謝謝！