爲什麼大家都說計算機是青春飯呢？這是因爲大部分計算式知識是個純粹的對錯的知識。比如你學習C++編程，寫個表達式，編譯器能過就是對的，不能過就是錯的。而這個對錯的門檻是非常低的。任何人只要學過幾天都會的。這樣大量年輕人涌入這個行業，把老鳥給拍死了。新手和老手的價值貌似差不多。公司就不會以更高工資僱傭老鳥。
而靠經驗吃飯的人的知識是分好壞的。一個問題幾個方案，那個也能解決。但是存在好壞。只有經過大量的實踐，積累大量經驗，你才能分出好壞，給出一個優化的選擇。這樣你的飯碗就能端的長久一點。
設計模式就是個分好壞而不是對錯的知識。那麼怎麼區分一個設計的好壞呢？得有個標準，標準又取決於你的目的。所以本文講講設計模式和設計目的的關係。
設計目的有很多種，比如GOF的書名就是“Design patterns: elements of reusable Object-Oriented Software”，書名中提到了reusable可重用。
我們常見的設計目的有：
1)正確性：至少把功能先實現了，能給客戶帶來商業價值
2)性能： 更快的速度，更高的CPU使用率，更少的內存佔用
3)可讀性：這是一個巨大的話題，如何把代碼寫的其他人或者未來的自己一眼就能看懂是一個學問。
4)可擴展性：當新的需求來的時候，只需要增加新的代碼就可以了，無需修改已有的代碼。
5)可複用性：已經寫好的代碼，以後可以很方便的拿來複用。語言層面就是抽取公共的函數或者公共的類；在設計層面，就是要使得你的設計更抽象，從而能複用
6)可維護性: 當需要修改代碼的時候，只需要修改很少一部分，而不是類似的代碼到處修改；也不是同一個功能放在不同的模塊，要修改多個模塊
7）可調試性：當產品出現問題的時候，如何更好的更快的找到問題的所在
8）健壯性：異常處理能力。包括了我們不讓系統發生異常的能力和當系統發生異常的時候，程序還能夠正常運行下去，不至於整個程序死掉。也就是容錯能力。
比如：在GUI界面設計上，如果涉及一個下拉菜單給用戶選擇，那麼不會出現異常的數值；如果設計了一個field，那麼用戶可以輸入任何數值。在編寫代碼的時候，使用enum而不是int也是同樣的意思。
9）可移植性：在不同的系統中方便的移植
NOTE：上面的可擴展性，可複用性，可維護性的概念有時候能分來，有時候又比較模糊。本文中我把三個合併爲一個可擴展性。他的內涵包括了上面三個概念。
如果目標是一個，那麼很好辦。我把各個設計打個分，分高的就是好的，分低的就是不好的設計。
但是這裏的目標維度太多了，甚至是相互衝突的。這個時候就需要對這些目的進行優先級的排列了。
在上一章說過，當今計算機世界的邏輯變了。人是最昂貴的成本；市場競爭異常激烈；計算機滲透到了社會經濟的方方面面。所有因素加起來決定了，好的代碼的重要因素：正確性，可讀性，可擴展性和可調試性。
從軟件系統的角度看，軟件的成本cost(total)= cost(develop) + cost(maintain)。現在軟件越來越滲透到國民經濟的各個方面，那些十分複雜由上千上萬人維護的軟件系統不斷出現，且這些系統經常長達數十年的生命週期。於是cost(maintain)>>>cost(develop)。
且cost(maintain)= cost(read) + cost(change) + cost(test) + cost(deploy)。
如果代碼寫的好，簡單易懂，那麼cost(read)會減小，易讀性成爲追求的目標。
如果代碼寫的好，不用修改或者只改一小部分，那麼cost(change)，cost(test)和cost(deploy)會減小，於是代碼的可擴展性(OCP，靈活性flexible，複用reusable)成爲追求的目標。
根據上面的分析，功能正確實現，可讀性，可擴展性是排在優先級最高的三項。至於性能可以這麼看。優先考慮前三項，當出現性能問題的時候，再調試性能即可。可移植性在某些系統中才會考慮。可調試性也是非常重要的特性，如果你設計的系統能夠在一出現問題，那麼馬上就根據調試知道是什麼問題，那麼對系統維護是極好的。那麼設計模式會對這些目的有什麼影響呢？
對正確性而言：沒有影響。設計模式是對代碼的整理，而不改變產品功能。
對性能而言：某些設計模式會引入很多中間類和中間步驟，因此在某種程度上而言，設計模式對性能有理論上的影響。在實際中，一般不予考慮。除非他真正影響到了性能。
對可讀性而言：這是個雙刃劍。現代的各種庫，框架大量使用了設計模式中的模式。如果你不懂這些模式，這些產品和框架的可讀性極差。因爲你能看到的只是整個系統的一部分，你無法從整體上理解這個產品。如果你學過了設計模式，這個框架和產品的可讀性有極高。根據每個模式的名字，就能幫你理解產品的一大塊。
對可擴展性而言：主要的設計模式都是爲了系統的可擴展性。
可調試性和健壯性而言：影響不大。
對可移植性而言：某系設計模式會把應用層和底層分開。如果產品想移植到新的平臺，那麼非常方便。