這幾天**寫完了，開始收拾起本該寒假就讀完的《大話設計模式》。整本書讀起來還是不錯的，語言詼諧有趣，以生活中的例子為切入點，使讀者容易理解。比較適合物件導向語言的初學者或者中級人員學習。在這個系列學習中，我們先從設計模式的四大原則開始學起
四大原則：
* 單一職責：就乙個類而言，應該僅有乙個引起它變化的原因。
* 開閉原則：軟體實體（類，方法。。）應該可以擴充套件，但是不能修改。
* 依賴倒置：抽象不應該依賴於細節，細節應該依賴於抽象。
* 裡式替換：子型別必須能夠替換掉他們的父型別。
以開發乙個俄羅斯方塊為例。我們可以把方塊的下落，旋轉，移動，碰撞判斷等邏輯和遊戲頁面分離開來，也可以寫在一起。但是介面的變化和遊戲本身的邏輯之間是沒有關係的。
其實軟體設計的主要內容就是發現職責並把這些職責分離開來。如果我們能想到有多於乙個動機去改變乙個類，那麼這個類就具有多於乙個職責。我們就要想辦法將類的職責進行分離。
因為如果乙個類的職責過多，就等於把這些職責耦合在一起了，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力，使整個設計變得脆弱。
開閉原則
開閉原則從字面意思來解釋即對擴充套件開放，對修改封閉。
整個開閉原則所要描述的問題是怎樣的設計可以使我們的系統在面對突然變化的需求時，可以盡量少的修改即可滿足需求。
以上班考勤為例。針對上班的8小時工作制，有的公司規定早9晚6，有的公司則規定早8晚5。所有的規定都是面向8小時封閉，面向起始時間開放的。甚至對以業績為指標的公司，可以對8小時工作制都開放，但是對員工的業績必須封閉。這裡就需要找清自己想要達到什麼目的。
當然，在我們寫**的時候，我們假設變化不會發生，但是當變化發生時，我們就應該建立抽象類來隔離以後發生的同類變化。比如需要建立乙個加法運算。我們可以建立乙個client類來進行執行。乙個加法類來進行加法運算。但是當我們需要在client中支援減法的時候，我們就應該考慮抽象出乙個運算類來進行實際的運算操作和client的隔離。同時如果我們需要增加乘法，除法類的時候，只需新增加類即可，不許要在修改client了。這樣可以達到對擴充套件開放，對修改封閉的目的。
依賴倒置
其實整個依賴倒置原則的通俗的將就是應該面向切口程式設計。
這裡書中對倒置的解釋引用了資料庫連線中高層模組依賴與底層模組的例子。但是我覺得直接看主機板和記憶體，cpu等的關係更容易理解。即如果記憶體，cpu等壞了，我們直接換掉了就可以了。但是如果作為底層模組的主機板壞了，我們是不是得把整個電腦換了才可以呢？答案是當然不用。因為主機板和記憶體都是面向介面的，所以我們只要換掉主機板就可以了。至於為什麼在類的設計中，我們針對介面程式設計就可以完成依賴倒置呢？是因為介面的設計需要符合裡式替換原則。
裡式替換
裡式替換即乙個軟體裡面如果把父類都替換成了子類，則它的行為是沒有變化的。
比如在設計乙個bird(鳥)類時具有可以飛的屬性。同時設計乙個penguin(企鵝)類不可以飛。那麼penguin類可以繼承bird類嗎?答案當然是否定的。（因為不符合裡式替換的子類可以替換掉父類的原則。）
正是由於子類可替換父類，父類才可以被復用，而子類也可以在父類的基礎上增加行為。同時正是因為子類可替換父類，才使得使用了父類的模組在不需要修改的情況下就可以擴充套件，使開閉原則成為可能。
總結如果編寫程式時考慮的都是依賴抽象程式設計而不是依賴細節程式設計，即編寫程式的依賴關係都終止於抽象類或者介面則是物件導向的設計了。
設計模式之四大原則
看了大話設計模式，想自己總結一下，以加深印象。本次來總結設計模式中的設計原則。以下大部分來自大話設計模式 一 單一職責原則 它的準確解釋是 就乙個類而言，應該僅有乙個引起它變化的原因。通俗的說，就是乙個類不應該有太多的職責，不然的話，當需求發生改變時，你要改動的地方可能非常多且複雜，設計會遭到意想不...
物件導向 設計模式的四大原則
註明 下面都是我在學習 大話設計模式 做的筆記，為了傳播設計模式和自我提醒學習。1 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制 這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計...
設計模式 四大原則 迪公尺特法則
單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離 ...