oo的五大原則是指srp、ocp、lsp、dip、isp1. srp（single responsibility principle 單一職責原則）
單一職責很容易理解，所謂單一職責，就是乙個設計元素只做一件事。
srp 原則的核心含義是只能讓乙個類有且只有乙個職責，永遠不要讓乙個類存在多個改變的理由。換句話說，如果乙個類需要改變，改變它的理由永遠只有乙個，如果存在多個改變它的理由，就需要重新設計該類，如果乙個類承擔的職責過多，那麼就等於把這些職業耦合在一起了，乙個職責的變化可能會抑制該類完成其他職責的能力，這樣的耦合會導致脆弱的設計，當變化發生時，設計會受到意想不到的破壞。
2. ocp （open close principle 開閉原則）
一句話：「closed for modification; open for extension」——「對變更關閉；對擴充套件開放」。
ocp是指在進行物件導向設計中，設計類或其他程式單位時，應該遵循對擴充套件開放對修改關閉的原則，開閉原則是判斷物件導向設計是否正確的最基礎的原理之一，開閉原則要求對擴充套件開放，擴充套件提供新的或改變原有的功能，讓軟體具有靈活性，開閉原則要求擴充套件功能不修改原有的**，使軟體在變化中保持穩定，遵循開閉原則的系統設計，可以讓軟體系統可復用，並且易於維護。
3. lsp（liskov substitution principle 黎克特制替換原則）
子類應當可以替換父類並出現在父類能夠出現的任何地方。這個原則是liskov於2023年提出的設計原則。它同樣可以從bertrand meyer 的dbc (design by contract) 的概念推出。我們以學生為例，夜校生為學生的子類，因此在任何學生可以出現的地方，夜校生均可出現。這個例子有些牽強，乙個能夠反映這個原則的例子時圓和橢圓，圓是橢圓的乙個特殊子類。因此任何出現橢圓的地方，圓均可以出現。但反過來就可能行不通。運用替換原則時，我們盡量把類b設計為抽象類或者介面，讓c類繼承類b(介面b)並實現操作a和操作b，執行時，類c例項替換b，這樣我們即可進行新類的擴充套件(繼承類b或介面b)，同時無須對類a進行修改。
黎克特制替換原則即如果乙個軟體實體使用的是基類，那麼也一定適用於子類，但反過來的替換不成立。
如果有兩個具體的類a和b之間的關係違反了黎克特制替換原則，那麼在以下兩種重構方案中選擇一種：
1）建立乙個新的抽象類c，作為兩個具體類的超類，將a和b共同的行為移到c中，從而解決a和b行為不完全一致的問題
2）從b到a的繼承關係改寫為委派關係，子型別必須能替換掉他們的基本型別
4.dip（dependence inversion principle 依賴倒置原則）
依賴倒置（dependence inversion principle）原則講的是：要依賴於抽象，不要依賴於具體。簡單的說，依賴倒置原則要求客戶端依賴於抽象耦合。原則表述：抽象不應當依賴於細節；細節應當依賴於抽象；要針對介面程式設計，不針對實現程式設計。
依賴倒置原則，要以來於抽象，不要依賴於具體，也就是說要針對介面程式設計，不要針對實現程式設計，針對介面程式設計意味著應當使用介面和抽象類進行變數的型別宣告，參量的型別宣告，資料型別的轉換等，任何變數都不應該覆蓋它的任何基類中的已經實現的方法
5.isp（inte***ce segregation principle 介面分隔原則）
採用多個與特定客戶類有關的介面比採用乙個通用的涵蓋多個業務方法的介面要好。isp原則是另外乙個支援諸如com等元件化的使能技術。缺少isp，元件、類的可用性和移植性將大打折扣。這個原則的本質相當簡單。如果你擁有乙個針對多個客戶的類，為每乙個客戶建立特定業務介面，然後使該客戶類繼承多個特定業務介面將比直接載入客戶所需所有方法有效。
介面隔離原則的含義是使用多個專門的介面比使用單一的介面要好，從客戶端只需要某一些方法的話，那麼就應當向客戶端提供這些需要的方法，而不要提供不需要的方法提供介面意味著向客戶端作出承諾，過多的承諾會給系統的維護造成不必要的負擔，不應該強迫客戶依賴於他們不用的方法介面屬於客戶，不屬於他所在的類層次結構，多個面向特定使用者的介面勝於乙個通用介面。
OO的五大原則
oo的五大原則是指srp ocp lsp dip isp 1.srp single responsibility principle 單一職責原則 單一職責很容易理解，所謂單一職責，就是乙個設計元素只做一件事。2.ocp open close principle 開閉原則 一句話 closed fo...
設計模式五大原則
1 單一職責 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定 義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種情...
設計模式五大原則
1 單一職責原則 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種...