設計模式經驗談

• 設計模式是從已經完成的代碼和設計中提煉的，不是在設計和編碼之前構思的。
• 永遠不要為了眼前不存在的需求引入設計模式，更不要為了美化代碼而引入設計模式，這些都是過度設計最直接的根源。
• 引入設計模式最恰當的時機是需求變更的時候對代碼的重構，而且要注意，一次重構只引入最少量的設計模式，能滿足本次變更的需求即可。

作者：徐辰 鏈接：https://www.zhihu.com/question/20088337/answer/15391204 來源：知乎 著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

多層封裝，採用 複雜 的數據結構，代碼更直觀，易理解-----自己容易理解，不等於別人容易理解，或者你再過一段時間看看，說這話的人基本都是思維沒有扭轉過來。習慣了局限於自己代碼習慣，可能看優雅的代碼都不習慣。 引入（設計模式）後雖然做到了高度的解耦，------設計模式不是為瞭解耦，解耦只是帶來的效果，關鍵是清晰的功能分割，容易擴展。但基本不變的東西，或者本來就是耦合的東西就不需要引入一些模式。 但是代碼邏輯複雜了，怎麼平衡好？-----我問你，加法複雜還是乘法複雜，微積分呢，人們有了加法為何還要發明乘法這樣複雜的東西? 從1加到N 你願意一個一個加起來得出結果，還是用(1+n)*n/2直接得出結果？ 不要把自己停留在小學生水平，覺得初高中的東西複雜，那樣你永遠只能做小學生的題。到了初中，乘法就是小孩子游戲，根本不需要特別注意什麼時候用乘法，到了大學生水平，知道什麼時候該用微積分，簡單的方程是再顯然不過的事情。該用什麼數學工具就用什麼數學工具。

作者：白順龍 鏈接：https://www.zhihu.com/question/20088337/answer/13944410 來源：知乎 著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

引入設計模式後：

• 局部看，代碼邏輯複雜了；
• 全局看，系統結構清晰了。
• 當然，好東西容易被濫用，那就另說了~