1.單一職責原則（srp）
「單一職責模式」按照字面理解就是，乙個類的功能要「單一」或者專一，不能武斷地把很多相關或者不相關的功能強制寫進乙個類裡去，它的準確解釋是：「就乙個類，應該僅有乙個引起它變化的原因
」。我個人認為這個原則主要就是教我們如何抽象並「封裝」類。
舉例：對於初學者來說，我們幾乎都寫過的**，如webform和winform下使用者進行登陸，webform的default.aspx.cs類和winform的form1.cs不用寫一樣的具體登陸業務邏輯，如資料庫連線和查詢，登陸賬戶和密碼的匹配等等，而是應該抽象出使用者類和乙個登陸方法，然後winform或者webform共同呼叫該類的登陸方法就可以了。
2.開放-封閉原則（oc）
「對於擴充套件開放，對於更改封閉。」也就是「面對需求，對程式的改動是通過增加**進行的，而不是更改現有的**」。對於隨時可能變化的需求，這個原則對於開發者而言實在是太重要了。在設計的時候，我們要盡量考慮種種變化，把問題考慮的盡量全面一些。但是，無論考慮的多麼周到，無論你設計的模組多麼「封閉」，都會存在一些無法對之封閉的變化。既然不太可能完全封閉，我們就必須對設計模組進行抽象，分離出變化點，以備將來「擴充套件」。我們都希望在開發工作展開之前或者開始不久就知道專案中可能的變化，這樣遵循這個原則，抽象出變化點，程式的「可維護，可擴充套件，可復用和靈活性好」將大大增強。
舉例：寫計算器程式是乙個經典的例子，開始要求寫個加法運算，很快我們在客戶端client寫了出來。這個時候又要求寫個減法運算，我們不得不更改client的類，這就違背了「對更改封閉」，所以我們最好抽象出乙個抽象的運算類operation，通過物件導向常見的繼承和多型等特徵來隔離具體加減乘除等方法與client的耦合，這樣需求依然可以滿足，還能應對變化。
3.黎克特制代換原則（lsp）
簡單地說，也就是「子型別必須能夠替換掉它們的父型別」。乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。在程式中，把父類都替換成它的子類，程式的行為沒有變化。
舉例：在程式設計時，我們設計出乙個魚類（fish），它的行為是」遊「（swim），接著是「金魚（goldfish）和木魚（woodenfish）」類，都繼承魚類，但是我們看到金魚很顯然可以「遊」，但是木魚只能被敲打而不能」遊「，也就是說木魚類不能繼承魚類。（這個例子也許不合適，聽歌的時候想到的）
4.依賴倒轉原則（dip）
在解釋這個原則前，我們先看看經常碰到的「依賴」，也就是耦合,耦合可以分為下面三種 ：
（1）零耦合(nil coupling)關係,兩個類沒有依賴關係,那就是零耦合.
（2）具體耦合(concrete coupling)關係,兩個具體的類之間有依賴關係,那麼就是具體耦合關係,如果乙個具體類直接引用另外乙個具體類,就會發生這種關係.
（3）抽象耦合(abstract coupling)關係.這種關係發生在乙個具體類和乙個抽象類之間,這樣就使必須發生關係的類之間保持最大的靈活性. （這也正是我們程式設計過程中最期望的耦合方式）
最經典最完美解釋：「要針對介面程式設計，不要針對實現程式設計
」。依賴倒轉原則：（1）高層模組不應該依賴底層模組。兩個都應該依賴抽象。（2）抽象不應該依賴細節，細節應該依賴於抽象(abstractions should not depend upon details. details should depend upon abstractions)。「抽象」通常都是介面或者抽象類。這裡重點是用到了物件導向裡的「繼
承」特性。必須要注意：這個原則前提是黎克特制代換原則，在程式中，把父類替換成子類，程式的行為不會發生變化。只有當子類可以完全替換掉父類，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。
舉例：還以webform的使用者登陸為例，使用者按照類別可以分成多種型別，比如普通註冊使用者，公司員工，不同等級的忠實使用者，vip使用者等等。我們抽象出乙個抽象類user，這樣讓不同類別的員工繼承user，普通使用者和公司員工可能只有抽象類裡的登陸方法，而不同等級的忠實使用者和vip使用者有擴充套件出一些自己獨有的行為，如支付等等。這樣通過父類user，要呼叫乙個不同類別的使用者就可以通過父類變數等於new一下具體類別的使用者類就可以了。
5.迪公尺特法則（lod）
又叫最少知識原則（least knowledge principle 簡寫lkp）就是說，乙個物件應當對其它物件有盡可能少的了解，也叫做「不要和陌生人說話」。它的正確解釋是」如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。「。它強調我們在封裝類的時候，在類的設計結構上，每乙個類都應當降低成員的訪問許可權。類與類之間的耦合度越低越好，因為乙個類被修改，不會對有關聯的其他類也進行修改。
知根知底，堅持原則 設計模式的主要設計原則簡介
1.單一職責原則 srp 單一職責模式 按照字面理解就是，乙個類的功能要 單一 或者專一，不能武斷地把很多相關或者不相關的功能強制寫進乙個類裡去，它的準確解釋是 就乙個類，應該僅有乙個引起它變化的原因 我個人認為這個原則主要就是教我們如何抽象並 封裝 類。舉例 對於初學者來說，我們幾乎都寫過的 如w...
設計模式的主要設計原則簡介
1.單一職責原則 srp 單一職責模式 按照字面理解就是，乙個類的功能要 單一 或者專一，不能武斷地把很多相關或者不相關的功能強制寫進乙個類裡去，它的準確解釋是 就乙個類，應該僅有乙個引起它變化的原因 我個人認為這個原則主要就是教我們如何抽象並 封裝 類。舉例 對於初學者來說，我們幾乎都寫過的 如w...
設計模式的設計原則
單一職責原則 srp 單一職責適用於 介面，類，方法 開放封閉原則 ocp 乙個軟體實體應當對外擴充套件開放，對修改關閉 關鍵 什麼叫做鉤子方法？是對於抽象方法或者介面中定義的方法的乙個空實現 在實際的運用中，例如有乙個介面，這個介面裡面有7個方法，而你只想用其中的乙個方法，那麼這時，你可以寫乙個抽...