這兩天在看broadview的.net與設計模式一書。發現這本書的觀點很有道理，雖然今天剛把singtelon模式做了乙個總結，但是從學習設計模式的路上往回倒一步，先寫乙個學習設計模式應該注意的地方。
我覺得要注意的主要有以下幾點：
1.不要把設計模式當作解決方案，儘管gof的設計模式中更加偏重於解決方案。正是因為很多人把設計模式侷限在解決方案這個概念內，所以才導致設計模式的濫用和設計過度。
2.先提乙個概念，什麼叫設計模式的應用場景呢？在這裡我們可以認為是已經設計完成的類和介面之間的關係。只有在相關上下文和各種關切完全符合時，設計模式中的解決方案才是最優的。所以在使用設計模式之前，一定要認真分析問題所處的場景，看是否和設計模式的使用場合相符。如果不是很相符的話，那麼這個設計模式儘管也可能可以解決這個問題，但是很可能導致系統複雜，後期測試困難等問題。
3.設計模式的精髓之一是將可變部分封裝為物件，帶來的好處是系統更加靈活，易於維護，但是也增加了大量物件。所以在應用某個設計模式之前這個也是我們需要考慮的。如果增加的物件超出了我們可以控制的範圍，那麼好的，放棄這個設計模式的使用。
4.設計模式不能提高開發速度或者說是形象開發速度。在很多情況下即使我們選擇了正確的設計模式也會是我們開發的速度降低，但是這個降低是相對的。從整個專案的生命週期來看，合理的使用設計模式可以讓我們的程式結構更加健壯，更低的耦合和更高的內聚。其實這樣的話，看起來我們的開始進度慢了，實際上很多在測試和維護階段會遇到的問題已經在開發階段被我們避免了。
5.設計模式不是萬能的。這是我們必須承認的，不管任何一種東西都不是萬能的。就像物件導向三大特性的繼承特性，雖然這是乙個很好的特性，但是如果類之間繼承的層次太深，那麼最底層的子類肯定是十分龐大的。所以我們有時候說組合是比繼承更好的設計方法。在設計模式中，我們要注意當你的專案遇到以下問題時候，就需要考慮**重構：
（1）：**的後期單元測試很麻煩，這裡可能就是因為設計模式的應用導致物件過於多導致的。
（2）：**有大量重複。
（3）：如果需求的變動總是導致很多**的變動，那麼你這個設計模式的使用肯定是失敗的，或許說失敗太打擊人了可以用不成功來敷衍下自己。但是在這個時候你一定要注意了。因為設計模式的目的就是程式結構的健壯，專案構架的更加合理，但你的系統因為需求的變動總是在改變**，那麼好了你可以考慮換個設計模式或者乾脆就別用了。在這裡我們還可以再提下我們上面提到的，在使用設計模式的時候一定要注意語境。
（4）：隱藏的依賴過多。在這裡肯定導致系統過於複雜了。後期的測試你會發現你要瘋掉了。
（5）：繼承的層次太多。肯定是不行的，越來越龐大的子類。
上面是自己好久的理解，雖然設計模式的23中只是看了一點。因為設計模式這個課題自己很早就想看，只是那時候忙於acm實在是沒時間啊，接下好好學習下設計模式。突然想到一句話，設計模式之於物件導向程式設計就像資料結構之於結構化的程式設計。前寫結構話的**太多了，要慢慢改過來啊。
想了好多，這估計是自己寫的最長的一篇自己一字一字敲上去的隨筆，如果大家看到有什麼錯誤希望指出來，大家一起學習...
設計模式學習總結
之前一直是面向過程程式設計，前段時間因為某些原因需要更好的去理解一下物件導向思想精髓，在別人的推薦下看了 大話設計模式 這本書。通過對29個模式的學習，不僅僅了解了設計模式是個什麼回事，也稍微加深了一點對物件導向 object oriented 技術。物件導向技術關注的是物件，物件的優點在於，可以定...
設計模式 學習總結
設計模式是解決問題的方案，學習現有的設計模式可以做到經驗復用。擁有設計模式詞彙，在溝通時就能用更少的詞彙來討論，並且不需要了解底層細節。確保乙個類只有乙個例項，並提供該例項的全域性訪問點。實現 使用乙個私有建構函式 乙個私有靜態變數以及乙個公有靜態函式。1 懶漢式 執行緒不安全 public cla...
設計模式學習總結
乙個月帶著讀看完了設計模式，其中有一些模式真的是被坑著了，比如composite組合模式如果不用葉節點，真說不出有什麼特性。再比如備忘錄模式，我覺得這個模式的核心是打包傳遞資料，而不是用來備忘。好了，先寫乙個總結，以後慢慢消化 每個模式如果細說肯定不是三言兩語可以概括的，但是需要簡略概括，才能快速理...