物件導向程式設計原則總結

單一職責原則

就乙個類而言應該僅有乙個引起它變化的原因

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

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

開放-封閉原則

是說軟體實體(類模組函式等等)應該可以擴充套件但是不可修改

對於擴充套件是開放的對於更改是封閉的

怎樣的設計才能面對需求的改變卻可以保持相對穩定從而使得系統可以在第乙個版本以後不斷推出新的版本呢開放-封閉給我們答案

無論模組是多麼的封閉都會存在一些無法對之封閉的變化既然不可能完全封閉設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇他必須先猜測出最有可能發生的變化種類然後構造抽象來隔離那些變化

等到變化發生時立即採取行動

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

面對需求對程式的改動是通過增加新**進行的而不是更改現有的**

我們希望的是在開發工作展開不久就知道可能發生的變化查明可能發生的變化所等待的時間越長要建立正確的抽象就越困難

開放-封閉原則是物件導向設計的核心所在遵循這個原則可以帶來物件導向技術所聲稱的巨大好處也就是可維護可擴充套件可復用靈活性好開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象然而對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意拒絕不成熟的抽象和抽象本身一樣重要

依賴倒轉原則

抽象不應該依賴細節細節應該依賴於抽象

針對介面程式設計不要對實現程式設計

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

黎克特制代換原則

子型別必須能夠替換掉它們的父型別

乙個軟體實體如果使用的是乙個父類的話那麼一定適用於其子類而且它察覺不出父類物件和子類物件的區別也就是說在軟體裡面把父類都替換成它的子類程式的行為沒有變化

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

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

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

迪公尺特法則

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

在類的結構設計上每乙個類都應當盡量降低成員的訪問許可權

迪公尺特法則其根本思想是強調了類之間的松耦合

類之間的耦合越弱越有利於復用乙個處在弱耦合的類被修改不會對有關係的類造成波及