《大話設計模式》設計原則

單一職責原則(srp)， 就乙個類而言，應該僅有乙個引起它變化的原因。

如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。

軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離[asd]。如果你能夠想到多於乙個的動機去改變乙個類， 那麼這個類就具有多於乙個的職責[asd]，就應該考慮類的職責分離。

開放-封閉原則，是說軟體實體(類、模組、函式等等)應該可以擴充套件，但是不可修改。[asd]

也就是說，對於擴充套件是開放的(open for extension),對於更改是封閉的(closed for modification) [asd]。

絕對的對修改關閉是不可能的。無論模組是多麼的『封閉』，都會存在-些無

法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化[asd]。

在我們最初編寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化[asd]。

當面對新增需求時，對程式的改動是通過增加新**進行的，而不是更改現有的**[asd]。這就是『開放-封閉原則』的精神所在。

開放-封閉原則是物件導向設計的核心所在。

遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。

開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要[asd]。

依賴倒轉原則:

a.高層模組不應該依賴低層模組。兩個都應該依賴抽象。

b.抽象不應該依賴細節。細節應該依賴抽象。[asd]

也就是說要針對介面程式設計，不要針對實現程式設計。

舉例說，面向過程的開發時，為了使得常用**可以復用，一般都會把這些

常用**寫成許多函式的程式庫，這樣在做新專案時，去呼叫這些低層的函式就可以了。比如專案大多要訪問資料庫，就把訪問資料庫的**寫成了函式，每次做新專案時就去呼叫這些函式。這也就叫做高層模組依賴低層模組。

當客戶希望用不同的資料庫或儲存資訊方式，我們希望能再次利用這些高層模組，但高層模組都是與低層的訪問資料庫繫結在一起的，沒辦法復用這些高層模組，這就非常糟糕了。

如果不管高層模組還是低層模組，它們都依賴於抽象，具體一點就是介面或抽象類， 只要介面是穩定的，那麼任何乙個的更改都不用擔心其他受到影響，這就使得無論高層模組還是低層模組都可以很容易地被復用。這才是最好的辦法。

黎克特制代換原則(lsp)：子型別必須能夠替換掉它們的父型別。[asd]

只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。

正是由於子型別的可替換性，才使得使用父類型別的模組在無需修改的情況下就可以擴充套件。

依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者介面，那就是物件導向的設計，反之那就是過程化的設計了[asd]。

迪公尺特法則，也叫最少知識法則，如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。

大話設計模式之設計原則

在總結設計模式之前，我覺得有必要把程式設計中要遵循的幾個設計原則總結一下，因為在後面總結設計模式的時候，你會發現，基本上設計模式都是設計原則的體現和應用而已，有助於我們後期的總結學習。單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個...

設計模式原則總結 讀《大話設計模式》有感

讀了 大話設計模式 摘錄該書中講到的設計模式幾大原則，供日後使用。一 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的 職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭 受到意想...

設計模式原則總結 讀《大話設計模式》有感

一 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到破壞。軟體真正要做的許多內容，就是發現職責並把那些職責相互分離。如...