1. 開閉原則(the open closed principle ocp)
乙個模組在擴充套件性方面應該是開放的而在更改性方面應該是封閉的。因此在進行物件導向設計時要盡量考慮介面封裝機制、抽象機制和多型技術。該原則同樣適合於非物件導向設計的方法，是軟體工程設計方法的重要原則之一。我們以收音機的例子為例，講述物件導向的開閉原則。我們收聽節目時需要開啟收音機電源，對準電台頻率和進行音量調節。但是對於不同的收音機，實現這三個步驟的細節往往有所不同。比如自動收縮電台的收音機和按鈕式收縮在操作細節上並不相同。因此，我們不太可能針對每種不同型別的收音機通過乙個收音機類來實現(通過過載)這些不同的操作方式。但是我們可以定義乙個收音機介面，提供開機、關機、增加頻率、降低頻率、增加音量、降低音量六個抽象方法。不同的收音機繼承並實現這六個抽象方法。這樣新增收音機型別不會影響其它原有的收音機型別，收音機型別擴充套件極為方便。此外，已存在的收音機型別在修改其操作方法時也不會影響到其它型別的收音機。
2. 替換原則 (the liskov substitution principle lsp)
子類應當可以替換父類並出現在父類能夠出現的任何地方。這個原則是liskov於2023年提出的設計原則。它同樣可以從bertrand meyer 的dbc (design by contract) 的概念推出。
我們以學生為例，夜校生為學生的子類，因此在任何學生可以出現的地方，夜校生均可出現。這個例子有些牽強，乙個能夠反映這個原則的例子時圓和橢圓，圓是橢圓的乙個特殊子類。因此任何出現橢圓的地方，圓均可以出現。但反過來就可能行不通。
運用替換原則時，我們盡量把類b設計為抽象類或者介面，讓c類繼承類b(介面b)並實現操作a和操作b，執行時，類c例項替換b，這樣我們即可進行新類的擴充套件(繼承類b或介面b)，同時無須對類a進行修改。
3. 依賴原則 (the dependency inversion principle dip)
在進行業務設計時，與特定業務有關的依賴關係應該盡量依賴介面和抽象類，而不是依賴於具體類。具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關係。
在結構化設計中，我們可以看到底層的模組是對高層抽象模組的實現(高層抽象模組通過呼叫底層模組)，這說明，抽象的模組要依賴具體實現相關的模組，底層模組的具體實現發生變動時將會嚴重影響高層抽象的模組，顯然這是結構化方法的乙個"硬傷"。
物件導向方法的依賴關係剛好相反，具體實現類依賴於抽象類和介面。
為此，我們在進行業務設計時，應盡量在介面或抽象類中定義業務方法的原型，並通過具體的實現類(子類)來實現該業務方法，業務方法內容的修改將不會影響到執行時業務方法的呼叫。
4. 介面分離原則(the inte***ce segregation principle isp)
採用多個與特定客戶類有關的介面比採用乙個通用的涵蓋多個業務方法的介面要好。
isp原則是另外乙個支援諸如com等元件化的使能技術。缺少isp，元件、類的可用性和移植性將大打折扣。
這個原則的本質相當簡單。如果你擁有乙個針對多個客戶的類，為每乙個客戶建立特定業務介面，然後使該客戶類繼承多個特定業務介面將比直接載入客戶所需所有方法有效。
以上四個原則是物件導向中常常用到的原則。此外，除上述四原則外，還有一些常用的經驗諸如類結構層次以三到四層為宜、類的職責明確化(乙個類對應乙個具體職責)等可供我們在進行物件導向設計參考。但就上面的幾個原則看來，我們看到這些類在幾何分布上呈現樹型拓撲的關係，這是一種良好、開放式的線性關係、具有較低的設計複雜度。一般說來，在軟體設計中我們應當盡量避免出現帶有閉包、迴圈的設計關係，它們反映的是較大的耦合度和設計複雜化。
物件導向程式設計原則
很久以前就知道物件導向設計有一些公認的基本原則，可都是零零碎碎的了解一部分，雖然在實踐的過程中也有意識的用到了一些，可是從來沒有系統的總結過，這是我從網上找到的比較詳細的介紹，就當是讀書筆記吧 所有的設計模式都是對不同的可變性的封裝，從而使系統在不同角度達到 開閉原則 的要求。在軟體軟體系統中，乙個...
物件導向程式設計原則
宣告 下面列出的物件導向程式設計原則並非我個人總結，而是最近學習設計模式的筆記。目前只是列出剛看過的幾條，以後學到再繼續新增。1.單一職責原則 srp 單一職責原則，就是，就乙個類而言，應該僅有乙個引起它變化的原因。也就是說，乙個類應該只實現乙個單一的功能。為什麼呢？因為，如果乙個類承擔的職責過多，...
物件導向程式設計原則總結
單一職責原則 就乙個類而言 應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多 就等於把這些職責耦合在一起 乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力 這種耦合會導致脆弱的設計 當變化發生時 設計會遭受到意想不到的破壞 軟體設計真正要做的許多內容 就是發現職責並把那些職責相互分離 ...