看了大話設計模式，想自己總結一下，以加深印象。本次來總結設計模式中的設計原則。（以下大部分來自大話設計模式）
一：單一職責原則
它的準確解釋是：就乙個類而言，應該僅有乙個引起它變化的原因。
通俗的說，就是乙個類不應該有太多的職責，不然的話，當需求發生改變時，你要改動的地方可能非常多且複雜，設計會遭到意想不到的破壞。比如在資料庫設計中，如果在乙個類中，既要從資料庫中取資料，又要對這些資料進行歸納整理，那麼這個類就不是好的設計，當需求改變時，整個類可能都要修改。應該把它們放在不同的類中，乙個類只負責乙個功能，只取資料或者只整理資料，那麼當需求改變時，只用修改整理資料的那個類就好了。
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
二：開放-封閉原則
它是說軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可修改。
也就是說，軟體實體，最好能夠通過繼承同乙個父類等來進行功能擴充套件，最好不要在已經寫好的類裡面進行修改。
即面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**。
絕對的修改關閉是不可能的。無論模組是多麼的『封閉』，都會存在一些無法對之封閉 的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生變化的種類，然後 構造抽象來隔離那些變化（通過繼承、封裝等）。
當然，並不是什麼時候應對變化都是容易的，我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。
開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分作出抽象，然而，對於程式中的每個部分都刻意的進行抽象並不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
三：依賴倒轉原則
a：高層模組不應該依賴底層模組，兩個都應該依賴抽象。
b：抽象不應該依賴細節，細節應該依賴抽象。
什麼是高層模組依賴底層模組？舉個例子，面向過程開發時，為了使得常用**可以復用，一般都會把這些**寫成許許多多的函式庫，這樣在做新專案時，去呼叫這些底層的函式就可以了。但為什麼高層模組不應該依賴底層模組？比如專案大多時候都有訪問資料庫，所以就把訪問資料庫的**寫成了函式，每次寫新專案時都要呼叫這些函式。如果不管高層模組還是底層模組，他們都依賴於抽象，具體一點就是介面或抽象類，只要介面是穩定的，那麼任何乙個地方的更改都不用擔心其他的地方受到影響，這就使得無論高層模組還是底層模組都可以很容易的復用。
為什麼依賴了抽象的介面或抽象類就不怕更改呢？因為有乙個黎克特制代換原則。
黎克特制代換原則簡單的說就是子型別必須能夠替換掉他們的父型別。也就是說，在軟體裡，把父類都替換成他的子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不會受到影響，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。比如說，在面向過程設計時，有乙個鳥類，有乙個企鵝類，鳥類可以飛，儘管企鵝在生物學上是一種特殊的鳥類，但他在這裡卻不能繼承鳥類，因為他一旦繼承了鳥類，他就繼承了父類的方法，具備了飛行的功能，但企鵝是不會飛的，所以不能繼承鳥類。
正是由於子型別的可替換性才使得使用父類的模組在無需修改的情況下就可以擴充套件。
四：迪公尺特發則
迪公尺特發則是說，如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法 的話，可以通過第三者**這個呼叫。
迪公尺特發則其根本思想是強調了類之間的松耦合，我們在程式設計時，類之間的耦合越弱，越有利於復用，乙個處在弱耦合的類被修改，不會對有關係的類造成波及。
設計模式的四大原則
這幾天 寫完了，開始收拾起本該寒假就讀完的 大話設計模式 整本書讀起來還是不錯的，語言詼諧有趣，以生活中的例子為切入點，使讀者容易理解。比較適合物件導向語言的初學者或者中級人員學習。在這個系列學習中，我們先從設計模式的四大原則開始學起 四大原則 單一職責 就乙個類而言，應該僅有乙個引起它變化的原因。...
物件導向 設計模式的四大原則
註明 下面都是我在學習 大話設計模式 做的筆記，為了傳播設計模式和自我提醒學習。1 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制 這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計...
設計模式 四大原則 迪公尺特法則
單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離 ...