設計模式=要解決問題+思想+打法
設計模式=要解決問題+思想+打法
我們很多情況下，在以OO思想思考問題時候不得不考慮：
1、要解決問題：
怎么實現架構的高內聚低耦合
考慮權重：代碼復用+可擴展+可維護性
結合現實情況，對需求進行評估，對代碼架構進行分析。
2、思想
思想 = 原則：
比如開閉，職責單一，依賴倒轉，里氏替換，迪米特。
對變化的理解：
變化始終存在，無論模塊多么封閉，都不可能完全封閉。設計人員必須對于他設計的模塊應該對哪種變化封閉做出選擇，必須先猜出最有可能發生變化的種類，然后構造抽離這些變化。
面對需求，對程序的改動是通過增加新的代碼進行的，而不是更改現有的代碼。
最初編寫代碼時候，假設變化不會發生，當變化發生時，我們就該抽象來隔離以后發生同樣的變化。（重構）
拒絕不成熟抽象和抽象本身一樣重要。
高手是用同樣代價獲得最大收益或者最小代價獲得同樣收益
3、打法
很多時候，思想對了，往往方針落不了地或者有問題，關鍵還是經驗不足。
這也是最核心一步內容，沒有coding經驗的，代碼駕馭能力很弱。
我們在學習到第三步，打法時候，真正才能體驗效果。前面2點，都是理論，說白了都是銀槍醋蠟，忽悠。。。
檢驗了你打法就是實踐
我們很多情況下，在以OO思想思考問題時候不得不考慮：
1、要解決問題：
怎么實現架構的高內聚低耦合
考慮權重：代碼復用+可擴展+可維護性
結合現實情況，對需求進行評估，對代碼架構進行分析。
2、思想
思想 = 原則：
比如開閉，職責單一，依賴倒轉，里氏替換，迪米特。
對變化的理解：
變化始終存在，無論模塊多么封閉，都不可能完全封閉。設計人員必須對于他設計的模塊應該對哪種變化封閉做出選擇，必須先猜出最有可能發生變化的種類，然后構造抽離這些變化。
面對需求，對程序的改動是通過增加新的代碼進行的，而不是更改現有的代碼。
最初編寫代碼時候，假設變化不會發生，當變化發生時，我們就該抽象來隔離以后發生同樣的變化。（重構）
拒絕不成熟抽象和抽象本身一樣重要。
高手是用同樣代價獲得最大收益或者最小代價獲得同樣收益
3、打法
很多時候，思想對了，往往方針落不了地或者有問題，關鍵還是經驗不足。
這也是最核心一步內容，沒有coding經驗的，代碼駕馭能力很弱。
我們在學習到第三步，打法時候，真正才能體驗效果。前面2點，都是理論，說白了都是銀槍醋蠟，忽悠。。。
檢驗了你打法就是實踐
本文由用戶 quguiliang 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
quguiliang 
openkk 
梁援—晉