為什么需要面相對象
在歷史進程中，我們由面相對象編程轉向了面相對象編程，項目的規(guī)模也變得越來越大，其中有著必然的需求————改變。這里引用HeadFrist中的一句話:"不管軟件設計的多好，一段時間之后，總是需要成長與改變，否則軟件就會"死亡"。"緊接著就出現(xiàn)了面相對象這一概念:我們使用類來映射現(xiàn)實中的對象，通過對象來實現(xiàn)我們需要的功能，大家各辭其職，互不影響。這時候就不會出現(xiàn)牽一發(fā)而動全身的情況。軟件的更新越來越快，實現(xiàn)的功能也越來越多。由于面相對象的支持，各個功能以模塊化的形式在互聯(lián)網(wǎng)上傳播開來，大家再也不用去造重復的輪子，我們也有了更多時間做更加酷炫的事情。
為什么有了設計模式
很顯然之前面相對象是一種強大而先進的思想，但是在開發(fā)過程中我們發(fā)現(xiàn)了很多問題。問題的來源也是改變，我們來舉一個例子：
假設使用傳統(tǒng)OO的方式，我們創(chuàng)建了一個超類Animal，它定義了所有的Animal產(chǎn)生的共同行為 makeSounds();run();mating();。 之后因為市場需求的變動我們需要給動物添加一個新的功能jump();(不改動就會死)。。這里傳統(tǒng)OO有兩種解決的方式：
繼承
我們意識到OO繼承的強大之處，只要我們使Animal()中增添新的方法jump(),問題就好像得到了解決。但是事實情況是：你需要檢查你所有的子類，因為并不是所有的子類都對于此方法適用，比如蝎子、螃蟹、毛蟲。這個問題也較容易解決：在子類中重寫此方法，對于不適用的子類，重寫它的空白方法jump(){}。到這里問題好像得到了解決，但是需要面臨一個問題：每次我們創(chuàng)造一個新動物時都要氣注意到底哪些需要覆蓋，哪些不要。況且我們也沒辦法通過代碼看出這個對象具體擁有哪些有效行為（需要檢查哪些沒有被覆蓋）。
接口
這時候接口站了出來。他告訴我們只要你寫一個jumpable()接口,讓有能力的動物跳躍就可以了。看起來真是一個清晰的解決方法，但問題是接口是沒有辦法代碼復用的。這意味著我們需要不斷去實現(xiàn)每一個子類的具體功能————即使已經(jīng)實現(xiàn)過了，真的是太可怕了。
之后呢
設計模式應運而生，它通過基于一些設計原則，告訴我們一種科學的規(guī)范，告訴我們?nèi)绾芜M行抽象，如何實現(xiàn)某種功能。
