物件導向的原則

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

軟體實體（類、模組、函式等）應該可以擴充套件，但是不可修改。也就是對於擴充套件是開放等，對於更改是封閉等。

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

無論模組多麼「封閉」，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對他設計對模組應該對哪種變化封閉做出選擇。必須先猜測出最有可能發生對變化種類，然後構造抽象來隔離那些變化。雖然很難提前**，但是可以在發生小變化時立即行動，建立抽象來隔離以後發生的同類變化。

然而，對於應用程式每個部分都刻意進行抽象也不是乙個好事。拒絕不成熟的抽象和抽象本身一樣重要。

抽象不應該依賴細節，細節應該依賴抽象。

高層模組不應該依賴底層模組，兩者都應該依賴抽象。

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

子型別必須能替代其父型別。

乙個軟體實體如果使用的是乙個父類，那麼一定適用其子類，而且察覺不出父類和子類的區別。也就是說，在軟體裡，把父類替換成其子類，軟體行為不會有任何變化。

使用多個專門的介面比使用單一的總介面要好。

不要設計有多個功能的介面，要細化。

如果兩個類不必直接通訊，那麼這兩個類就不應該發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法，可以通過第三者**這個呼叫。

在類的結構設計上，每乙個類都應當盡量降低成員的訪問許可權，強調類之間的松耦合。

類之間的耦合越弱，越有利於復用。

物件導向的原則

1.srp單一職責原則 適用於類功能 就乙個類而言,應該僅有乙個引起它變化的原因.詳細說明 如果乙個類承擔的職責過多,就等於把這些職責耦合在一起.乙個職責的變化可能會削弱或者抑制這個類完成其它職責的能力.這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞.結論 它是所有類設計原則最簡...

物件導向的原則

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

物件導向的原則

設計模式遵循的一般原則 1.開 閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開發,對修改關閉.說的是,再設計乙個模組的時候,應當使這個模組可以在不被修改的前提下被擴充套件.換言之,應當可以在不必修改源 的情況下改變這個模組的行為，在保持系統一定穩定性的基礎上...