物件導向設計原則

一. 單一職責原則(srp)

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

如果乙個類承載的職責過多，就等於把這些職責耦合在一起。乙個職責的變化可能削弱或抑制這個類完成其他職責的能力。

這種耦合會導致脆弱的設計，當發生變化時，設計會遭受意想不到的破壞。

軟體設計真正要做的就是，發現職責並把職責相互分離。

如果你能想到多於乙個動機去改變乙個類，那麼這個類就具有多於乙個的職責，應該進行分離。

例如：一場籃球比賽當中，既要判定隊員是否犯規，還要進行計分。如果講個兩職責教給乙個裁判的話，很容易造成比賽的混亂

二.開閉原則(ocp)

軟體實體（類，模組，函式）應該是可擴充套件，不可修改的。

無論模組多少封閉，都會存在一些對之無法封閉的變化，既然不能完全封閉，設計人員就要對他設計的模組應該對哪些變化進行封閉做出選擇。他必須猜測出最有可能發生變化的種類，然後構造抽象對這些變化進行隔離。

面對需求的變化，通過增加新**來實現而不是改變現有的**。

開發人員可以僅對程式中出現頻繁變化的部分進行抽象，然而對於應用程式的每個部分都進行刻意的抽象同樣不是乙個好主意，拒絕不成熟的抽象與抽象一樣重要。

例如：飯店要擴招乙個配菜師，原來沒有配菜師這個職位，只需要直接新增配菜師這個職位，不需要改動原本的員工體系。

三.依賴倒置原則(dip)

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

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

面向過程的開發，上層呼叫下層，上層依賴於下層，當下層劇烈變動時上層也要跟著變動，這就會導致模組的復用性降低而且大大提高了開發的成本。

物件導向的開發很好的解決了這個問題，一般情況下抽象的變化概率很小，讓使用者程式依賴於抽象，實現的細節也依賴於抽象。即使實現細節不斷變動，只要抽象不變，客戶程式就不需要變化。這大大降低了客戶程式與實現細節的耦合度。

例如：四.黎克特制替換原則(lsp)

子類必須能替換它的父型別。

任何基類可以出現的地方，子類一定可以出現。

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

五.介面分離原則(isp)

採用多個與特定類有關的介面，比採用乙個通用的涵蓋多種業務的介面更好。

如果你擁有乙個針對多個客戶的類，為每乙個客戶建立特定業務介面，然後使該客戶類繼承多個特定業務介面將比直接載入客戶所需所有方法有效。

六.迪公尺特原則(lop)

迪公尺特原則又叫最少知識原則：如果兩個類不直接發生通訊，那麼這兩個類就不應該發生直接的相互作用。

如果乙個類要呼叫另乙個類，則通過第三者呼叫。

迪公尺特法則首先強調的前提是在類的結構設計上，每乙個類都應當盡量降低成員的訪問許可權。

迪公尺特法則其根本思想強調的是類之間的松耦合。類之間的耦合越弱，越利於復用，乙個處於弱耦合的類被修改，不會對有關係的類造成波及。

七.合成/聚合復用原則

合成/聚合復用原則：經常又叫做合成復用原則，就是在乙個新的物件裡面使用一些已有的物件，使之成為新物件的一部分；新物件通過向這些物件的委派達到復用已有功能的目的。我白了就是要盡量使用合成/聚合，盡量不要使用繼承。