宣告：下面列出的物件導向程式設計原則並非我個人總結，而是最近學習設計模式的筆記。目前只是列出剛看過的幾條，以後學到再繼續新增。
1. 單一職責原則（srp）
單一職責原則，就是，就乙個類而言，應該僅有乙個引起它變化的原因。
也就是說，乙個類應該只實現乙個單一的功能。為什麼呢？因為，如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。比如我們寫乙個窗體應用程式，一般都會生成乙個form1這樣的類，於是我們就將各種各樣的**，像某種功能的演算法啊，資料庫訪問的sql語句啊什麼的都寫到這樣的類中，這就意味著，無論任何需求要來，你都需要更改這個窗體類。這其實是很糟糕的，維護麻煩，復用不可能，也缺乏靈活性。
軟體設計真正要做的許多內容，就是發現職責，並把這些職責相互分離。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就具有多於乙個的職責，就應該考慮類的職責分離。
2. 開放-封閉原則
開放-封閉原則，是說軟體實體（類、模組、函式等）應該可以擴充套件，但是不可修改。
這個原則其實有兩個特徵，乙個是說「對於擴充套件是開放的（open for extension）」，另乙個是說「對於更改是封閉的（closed for modification）」。其實就是所謂的「高內聚，松耦合」。這樣，面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**。
開放-封閉原則是物件導向設計的核心所在。遵循這個原則，可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象。然而，對於應用程式中的每個部分都刻意進行抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
3. 依賴倒轉原則
a. 高層模組不應依賴於低層模組。兩者都應依賴抽象。
b. 抽象不應依賴於細節。細節應該依賴於抽象。
為什麼叫倒轉呢？在面向過程開發時，為了使常用**可復用，一般都會把它們寫出許多函式的程式庫。在做新專案時，去呼叫這些低層的函式就行了。比如我們做專案時大多要訪問資料庫，我們就把訪問資料庫的**寫出函式，每次做新專案時就去呼叫這些函式。這就叫做高層模組依賴低層模組。這樣做的問題是，我們要做新專案時，發現高層模組的業務邏輯都是一樣的，但客戶卻希望使用不同的資料庫或儲存資訊方式，這時就出現麻煩了。我們希望能再次利用這些高層模組，但高層模組都是與低層的訪問資料庫聯絡在一起的，沒辦法復用這些高層模組。而如果不管高層模組還是低層模組，它們都依賴於抽象（介面或抽象類），只要介面是穩定的，那麼任何乙個的更改都不用擔心其他受到影響，這就使得高層模組和低層模組都可以很容易的被復用。
黎克特制代換原則
子型別必須能夠替換掉他們的父型別。
黎克特制代換原則是barbara liskov女士在2023年發表的，具體的數學定義比較複雜，白話翻譯就是乙個父類出現的地方，乙個可以用子類去替換掉它，而且不對程式造成任何影響。就是說這軟體裡面，把父類都替換成它的子類，程式的行為不會發生任何變化。
正是由於子型別能夠替換掉他們的父型別，才使得使用父型別的模組在無需修改的情況下就可以擴充套件，才有可能實現依賴倒轉原則，才有可能實現開放-封閉原則。
依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言編寫程式並不重要，如果編寫時考慮的都是如何針對抽象程式設計，而不是針對細節程式設計，即程式中的所有依賴關係都是終止於抽象類或者介面，那就是物件導向的設計，反之那就是過程化的設計了。
物件導向程式設計原則
很久以前就知道物件導向設計有一些公認的基本原則，可都是零零碎碎的了解一部分，雖然在實踐的過程中也有意識的用到了一些，可是從來沒有系統的總結過，這是我從網上找到的比較詳細的介紹，就當是讀書筆記吧 所有的設計模式都是對不同的可變性的封裝，從而使系統在不同角度達到 開閉原則 的要求。在軟體軟體系統中，乙個...
物件導向程式設計的原則
1.開閉原則 the open closed principle ocp 乙個模組在擴充套件性方面應該是開放的而在更改性方面應該是封閉的。因此在進行物件導向設計時要盡量考慮介面封裝機制 抽象機制和多型技術。該原則同樣適合於非物件導向設計的方法，是軟體工程設計方法的重要原則之一。我們以收音機的例子為例...
物件導向程式設計原則總結
單一職責原則 就乙個類而言 應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多 就等於把這些職責耦合在一起 乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力 這種耦合會導致脆弱的設計 當變化發生時 設計會遭受到意想不到的破壞 軟體設計真正要做的許多內容 就是發現職責並把那些職責相互分離 ...