一) 濫用模式
在 head first 設計模式中有這樣一段對話：
最少知識原則：只和你的密友交談。
問：還有另外乙個原則叫做 law of demeter，它和最少知識原則之間有什麼關係？
答：其實這兩個名詞指的是同乙個原則。我們傾向於使用最少知識原則來稱呼它是因為以下兩個原因：
1)這個名字更直接。
2)法則給人感覺是強制。
事實上，沒有任何原則是law，所有的原則都應該在有幫助的時候才遵守。所有的設計都不免需要折中（在抽象和速度之間取捨，在空間和時間之間平衡。。。）。雖然原則提供了方針，但在採用原則之前，必須全盤考慮所有的因素。
中國有句老話：「過猶不及」。從作者上面的話看來，只有在欠當的使用使用設計模式才更有威力。
那麼在什麼時候才應該使用設計模式那？看來好像是個不太容易回答的問題。也許這個問題隨著設計經驗的深入，對設計模式認識的深入，才會有更明晰的結果吧。
熟知「三十六計」的人應該還是有不少的，但是能夠運用自如的人也許並不不在多數。 也許只有那些真正領悟了「三十六計」精髓的人們，那些多學多用，熟能生巧的人們才能使用得得心應手吧？
二) 設計模式和直接了當之間的矛盾
問：採用最少知識原則有什麼缺點嘛？
答：是的。雖然這個原則減少了物件之間的依賴，研究顯示這回減少軟體的維護成本，但是採用這個原則也會導致更多的「包裝」類被製造出來，一處理和其他元件的溝通，這可能會導致複雜度和開發時間的增加，並降低執行時的效能。
設計模式為了提高**的可重用性和易於維護，其中的很多原則：想了很多方法，增加了很多馬甲來「隔離變與不變」，「對擴充套件開放，對修改關閉」，「最少知識原則」等等。
採用設計模式後，在閱讀**時會感覺左拐右拐，為了做某件事情，貌似增加了很多無用功，婆婆媽媽，扭扭捏捏的，不是直接拼刺刀那麼爽快淋漓。
我以前常用c語言，基本上是面向過程程式設計。剛開始接觸和閱讀c++, 遵循oo程式設計思想的**時。總覺得**的呼叫流程不夠直接，因為c++的「多型」特性，很多呼叫流程在**上看起來沒有c語言那麼明晰(當然在c語言中照樣可以使用到一些設計模式思想)，讓人在閱讀**時覺得很不爽，摸不著頭鬧，o(∩_∩)o哈哈~
但當你閱讀了設計模式後，認識改觀了很多。
濫用單例設計模式的害處
大多數做軟體設計的人都學習過設計模式，而看過 設計模式 那本書的人一定對單例模式有印象。在眾多 的設計模式中，單例模式顯得很特別，清晰又簡單，容易被人記住，所以使用的也相當多。然而最近在乙個 c 的新專案中，發現了非常多的地方用了單例模式，幾乎到了濫用的地步，帶來的不好的地方也顯現了出 來。本文總結...
設計模式和執行緒設計模式
volatile 可見性和順序性，不保證原子性 單例模式 監控執行緒生命週期的observable 採用乙個observable介面來獲取任務執行的狀態，主要想法是重寫run方法。在任務建立，開始，結束，錯誤時介入乙個方法，用來進行處理。同時維護乙個指示任務狀態的類變數。採用模板設計模式的方式，將具...
框架模式和設計模式
很多程式設計師往往把框架模式和設計模式混淆，認為mvc是一種設計模式。實際上，他們是完全不同的概念。框架模式和設計模式這兩個概念總容易混淆。其實它們之間是有區別的。框架通常是 重用，而設計模式是設計重用。在軟體成產中有三種級別的重用 內部重用 在同一應用中能公共使用的抽象塊 重用 將通用模組組合成庫...