設計模式的四大原則

  這幾天論文寫完了，開始收拾起本該寒假就讀完的《大話設計模式》。整本書讀起來仍是不錯的，語言詼諧有趣，以生活中的例子爲切入點，使讀者容易理解。比較適合面嚮對象語言的初學者或者中級人員學習。在這個系列學習中，咱們先從設計模式的四大原則開始學起

四大原則：

* 單一職責：就一個類而言，應該僅有一個引發它變化的緣由。 * 開閉原則：軟件實體（類，方法。。）應該能夠擴展，可是不能修改。 * 依賴倒置：抽象不該該依賴於細節，細節應該依賴於抽象。 * 裏式替換：子類型必須可以替換掉他們的父類型。

單一職責

  以開發一個俄羅斯方塊爲例。咱們能夠把方塊的下落，旋轉，移動，碰撞判斷等邏輯和遊戲頁面分離開來，也能夠寫在一塊兒。可是界面的變化和遊戲自己的邏輯之間是沒有關係的。
　　其實軟件設計的主要內容就是發現職責並把這些職責分離開來。若是咱們能想到有多於一個動機去改變一個類，那麼這個類就具備多於一個職責。咱們就要想辦法將類的職責進行分離。
　　由於若是一個類的職責過多，就等於把這些職責耦合在一塊兒了，一個職責的變化可能會削弱或者抑制這個類完成其餘職責的能力，使整個設計變得脆弱。

開閉原則

  開閉原則從字面意思來解釋即對擴展開放，對修改封閉。
　　整個開閉原則所要描述的問題是怎樣的設計可使咱們的系統在面對忽然變化的需求時，能夠儘可能少的修改便可知足需求。
　　以上班考勤爲例。針對上班的8小時工做制，有的公司規定早9晚6，有的公司則規定早8晚5。全部的規定都是面向8小時封閉，面向起始時間開放的。甚至對以業績爲指標的公司，能夠對8小時工做制都開放，可是對員工的業績必須封閉。這裏就須要找清本身想要達到什麼目的。
　　固然，在咱們寫代碼的時候，咱們假設變化不會發生，可是當變化發生時，咱們就應該建立抽象類來隔離之後發生的同類變化。好比須要建立一個加法運算。咱們能夠建立一個Client類來進行執行。一個加法類來進行加法運算。可是當咱們須要在Client中支持減法的時候，咱們就應該考慮抽象出一個運算類來進行實際的運算操做和Client的隔離。同時若是咱們須要增長乘法，除法類的時候，只需新增長類便可，不準要在修改Client了。這樣能夠達到對擴展開放，對修改封閉的目的。

依賴倒置

  其實整個依賴倒置原則的通俗的將就是應該面向切口編程。
　　這裏書中對倒置的解釋引用了數據庫鏈接中高層模塊依賴與底層模塊的例子。可是我以爲直接看主板和內存，CPU等的關係更容易理解。即若是內存，CPU等壞了，咱們直接換掉了就能夠了。可是若是做爲底層模塊的主板壞了，咱們是否是得把整個電腦換了才能夠呢？答案是固然不用。由於主板和內存都是面向接口的，因此咱們只要換掉主板就能夠了。至於爲何在類的設計中，咱們針對接口編程就能夠完成依賴倒置呢？是由於接口的設計須要符合裏式替換原則。

裏式替換

  裏式替換即一個軟件裏面若是把父類都替換成了子類，則它的行爲是沒有變化的。
　　好比在設計一個Bird(鳥)類時具備能夠飛的屬性。同時設計一個Penguin(企鵝)類不能夠飛。那麼Penguin類能夠繼承Bird類嗎?答案固然是否認的。（由於不符合裏式替換的子類能夠替換掉父類的原則。）
　　正是因爲子類可替換父類，父類才能夠被複用，而子類也能夠在父類的基礎上增長行爲。同時正是由於子類可替換父類，才使得使用了父類的模塊在不須要修改的狀況下就能夠擴展，使開閉原則成爲可能。

總結

  若是編寫程序時考慮的都是依賴抽象編程而不是依賴細節編程，即編寫程序的依賴關係都終止於抽象類或者接口則是面向對象的設計了。