最近，跟朋友在聊天的時候說到設計模式，有剛畢業的，也有工作了好幾年的，大家都說設計模式很難理解，但理解了就是理解了，儘管在平時的程式設計裡我們經常用到，但是就是說不出個所以然來，於是，就有了這篇文章。下面都是自己的一些理解，有不對的地方歡迎指出來，先道謝。

  我覺得設計模式無非就是解決程式設計的低耦合高內聚的，或者更簡單的理解就是面向介面程式設計，這個應該是我們理想的最終形態。

現在我們都習慣了面向物件程式設計，那麼我們採取哪些方法可以做到這些呢？於是經過很多前輩的實踐，得出了面向物件程式設計的5大基本原則，分別是單一職責、依賴倒置、里氏替換、介面剝離、開閉原則，也許還有一個迪米特法則，但是我個人覺得只要理解了前面的5個最基本的就可以了，迪米特法則也是為了降低耦合而總結出來的，那麼我們一起來討論下前面的5個：

（1）單一職責：詳細的解釋可以自行百度，但我覺得只要記住一個點就可以了，那就是一個類只作一樣事情，我相信在實際的程式設計中，大家對於工具類都很熟悉，其實這個就是單一職責最好的例項，那麼我們在思考其他的類的時候要不要借鑑下？

（2）依賴倒置：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。跟你們一樣每次我看見這些描述性的文字就不好理解，或者感到特別的煩，但是我們可以結合spring框架來清楚的明白這些，只要你理解或者直到spring的依賴方式，那麼理解這個就可以了，怎麼注入的，這個就不展開講。簡單來說就是介面跟實現的只能是單向的高到低的依賴，不能實現來決定介面，抽象也一樣。

（3）里氏替換：子類可以擴充套件父類的功能，但不能改變父類原有的功能。就是說通過繼承的方式來擴充套件，下面通過例子來說明，其實這個非常容易理解

（4）介面隔離：客戶端不應該依賴它不需要的介面，一個類對另一個類的依賴應該建立在最小的介面上。其實就是說一個類引進的依賴儘量的少，不要重複關聯介面，比如A、B、C三者，我們的需求是AC就可以實現的，但是我們有的時候做一樣的事情卻選擇了ABC這種組合。

（5）開閉原則：對修改閉合，對擴充套件開放。這個就是說一個類寫好了（明確功能了），就不要去修改這個類，我們可以通過繼承或者介面實現的方式擴充套件我們需要的功能，保留原來的類的功能

  看了上面的解釋，再聯想自己平時的程式設計過程，是不是經常用？其實我們就是很少總結而已，其實我個人覺得其中有很多的地方都相互重複了的，如果覺得還是有疑問，那麼看看下面的圖，再自己回味下，就拿我們平常耳熟能詳的故事：

                   烏鴉->飛到->瓶子裡->用嘴搬石頭->喝水

 如果這個時候你看錯了，不是烏鴉，是白鴿或者其他的，那怎麼辦？如果這個烏鴉比較特別，他用翅膀呢？如果喝的不是水，是飲料呢？這個時候就考驗我們的總結能力了，經過思考，上面的是不是可以換成這樣：

                   鳥->飛到->一個地方->用它的方法->喝東西

這樣是不是就好很多了？程式設計實現的話，我們就實現一個鳥類都基本具有的類（bird），再定義一個鳥的行為介面，然後是一些飲料的基本類，這樣是不是就可以處理更多的需求了，如果在現實的程式設計中？

 那麼這裡面是不是包含了里氏替換，單一職責、介面剝離、開閉？

  最後，這樣會不會感覺好一點？當然每個人都有自己的理解，我覺得通過結合自己的實際還是很容易就理解的。