1、單一職責原則
不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義：我們把職責定義為系統變化的原因。所有在定義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種情況應該重新細分職責，直到不會出現多種職責的類，介面方法為止（發現職責，並把那些職責相互分離）。單一職責的為最簡單的五種原則之一。在軟體設計的過程中處處體現。無處不在。
2、開放-封閉原則
開閉原則是指類、模組、方法是可以擴充套件的，但不可以修改。開即對擴張開放，閉即對修改關閉。開閉原則的應用體現在，開發人員應該僅僅對程式中頻繁出現變化的地方進行抽象（封裝變化點）。對變化點的封裝即對變化的修改關閉。對於變化的不確定性，可隨時擴充套件。即繼承的使用。抽象類的運用。
3、黎克特制替換原則
黎克特制替換原則即是總是保證子類可以替換它的基類。
黎克特制替換原則的實現。對於一組具有類似屬性，方法，變數的類。我們可以提取公共屬性，方法，變數做為乙個基類（抽象類或者類），使這一組類繼承基類，重寫虛方法。現在這些繼承的類和基類的關係符合is-a。如基類為鳥，則繼承類可以為麻雀，燕子。我們可以說麻雀is-a鳥，燕子is-a鳥。
在專案中所有使用子類的地方都可用父類替換，但在呼叫方法的時候 ，即呈現物件導向程式設計的多型性。即黎克特制替換原則，非常重要的原則，也是比較對難的原則。
4、依賴倒置原則
a、高層模組不應該依賴於低層模組。二者都應該依賴於抽象 b、抽象不應該依賴於細節。細節應該依賴於抽象。
在面向過程的開發語言中分析和設計，總是建立一些高層模組去呼叫低層模組、策略依賴於細節的軟體結構。實際上這種方法的目的就是要定義子程式層次結構，該結構描述了高層模組怎樣呼叫低層模組。而設計良好的物件導向的程式，正好「倒置」了這種依賴關係。高層模組不再依賴於低層模組，從而低層模組的修改不會影響到 高層模組，並且高層模組也是能非常容易的被重用，高層模組和低層模組都影響都依賴於抽象。這樣也非常符合強內聚松耦合的程式設計思想。故該原則也是框架設計的核心原則。
使用傳統的過程化程式設計所建立出來的依賴關係結構，策略是依賴於細節的，這是糟糕的，因為這樣會使策略受到細節改變的影響，物件導向的程式設計倒置了依賴關係結構，全程細節和策略都依賴抽象，並且常常是客戶程式擁有服務介面。
事實上，這種依賴關係的倒置正是好的物件導向設計的標誌所在，使用何種語言來編寫程式是無關緊要的。如果程式的依賴關係是倒置的，它就是物件導向的設計。如果程式的依賴關係不是倒置的，它就是過程化的設計。
依賴倒置原則是實現許多物件導向技術所宣稱的好處的基本低層機制。它的正確應用對於建立可重用的框架來說是必需的。同時它對於構建在變化面前富有彈性的**也是非常重要的，由於抽象和細節彼此隔離，所以**也非常容易維護。
5、介面隔離原則
應該說該原則是處理現有「胖」介面所存在的缺點。如果類的介面不是內聚的，就表示該類具有「胖」介面。換句話說「胖」介面可以分解成多組方法。每一組方法 都服務於一組不同的客戶程式。這樣，量引客戶程式可以使用一組成員函式，而其他客戶程式可以使用其他組的成員函式。
介面隔離的方法有兩種（分享客戶就是分離介面）：
1、使用委託（此委託非.net委託[delegate]）分離介面
使用委託即，建立乙個委託類，用此類去實現分離後的其它介面中的方法。
2、使用多重繼承分離介面、
此方法，即將現有「胖」介面分成供不同客戶程式呼叫的兩個或多個介面，而需要實現多個介面的客戶程式，則使用多重繼承來實現。
這兩種方法是實現介面隔離的全部方法，其中第二種方法使用較普遍，也比較簡單。而第一種方法使用起來相對比較複雜，而且在使用委託的過程中也會產生重 復的物件，則占用執行時間和記憶體開銷。有的時候第二種方法是必須的，第一種方法是不能使用的。如：利用委託物件所做的轉換是必需的，或者不同的時候會需要 不同的轉換。
**：李國清的
不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義：我們把職責定義為系統變化的原因。所有在定義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種情況應該重新細分職責，直到不會出現多種職責的類，介面方法為止（發現職責，並把那些職責相互分離）。單一職責的為最簡單的五種原則之一。在軟體設計的過程中處處體現。無處不在。
2、開放-封閉原則
開閉原則是指類、模組、方法是可以擴充套件的，但不可以修改。開即對擴張開放，閉即對修改關閉。開閉原則的應用體現在，開發人員應該僅僅對程式中頻繁出現變化的地方進行抽象（封裝變化點）。對變化點的封裝即對變化的修改關閉。對於變化的不確定性，可隨時擴充套件。即繼承的使用。抽象類的運用。
3、黎克特制替換原則
黎克特制替換原則即是總是保證子類可以替換它的基類。
黎克特制替換原則的實現。對於一組具有類似屬性，方法，變數的類。我們可以提取公共屬性，方法，變數做為乙個基類（抽象類或者類），使這一組類繼承基類，重寫虛方法。現在這些繼承的類和基類的關係符合is-a。如基類為鳥，則繼承類可以為麻雀，燕子。我們可以說麻雀is-a鳥，燕子is-a鳥。
在專案中所有使用子類的地方都可用父類替換，但在呼叫方法的時候 ，即呈現物件導向程式設計的多型性。即黎克特制替換原則，非常重要的原則，也是比較對難的原則。
4、依賴倒置原則
a、高層模組不應該依賴於低層模組。二者都應該依賴於抽象 b、抽象不應該依賴於細節。細節應該依賴於抽象。
在面向過程的開發語言中分析和設計，總是建立一些高層模組去呼叫低層模組、策略依賴於細節的軟體結構。實際上這種方法的目的就是要定義子程式層次結構，該結構描述了高層模組怎樣呼叫低層模組。而設計良好的物件導向的程式，正好「倒置」了這種依賴關係。高層模組不再依賴於低層模組，從而低層模組的修改不會影響到 高層模組，並且高層模組也是能非常容易的被重用，高層模組和低層模組都影響都依賴於抽象。這樣也非常符合強內聚松耦合的程式設計思想。故該原則也是框架設計的核心原則。
使用傳統的過程化程式設計所建立出來的依賴關係結構，策略是依賴於細節的，這是糟糕的，因為這樣會使策略受到細節改變的影響，物件導向的程式設計倒置了依賴關係結構，全程細節和策略都依賴抽象，並且常常是客戶程式擁有服務介面。
事實上，這種依賴關係的倒置正是好的物件導向設計的標誌所在，使用何種語言來編寫程式是無關緊要的。如果程式的依賴關係是倒置的，它就是物件導向的設計。如果程式的依賴關係不是倒置的，它就是過程化的設計。
依賴倒置原則是實現許多物件導向技術所宣稱的好處的基本低層機制。它的正確應用對於建立可重用的框架來說是必需的。同時它對於構建在變化面前富有彈性的**也是非常重要的，由於抽象和細節彼此隔離，所以**也非常容易維護。
5、介面隔離原則
應該說該原則是處理現有「胖」介面所存在的缺點。如果類的介面不是內聚的，就表示該類具有「胖」介面。換句話說「胖」介面可以分解成多組方法。每一組方法 都服務於一組不同的客戶程式。這樣，量引客戶程式可以使用一組成員函式，而其他客戶程式可以使用其他組的成員函式。
介面隔離的方法有兩種（分享客戶就是分離介面）：
1、使用委託（此委託非.net委託[delegate]）分離介面
使用委託即，建立乙個委託類，用此類去實現分離後的其它介面中的方法。
2、使用多重繼承分離介面、
此方法，即將現有「胖」介面分成供不同客戶程式呼叫的兩個或多個介面，而需要實現多個介面的客戶程式，則使用多重繼承來實現。
這兩種方法是實現介面隔離的全部方法，其中第二種方法使用較普遍，也比較簡單。而第一種方法使用起來相對比較複雜，而且在使用委託的過程中也會產生重 復的物件，則占用執行時間和記憶體開銷。有的時候第二種方法是必須的，第一種方法是不能使用的。如：利用委託物件所做的轉換是必需的，或者不同的時候會需要 不同的轉換。
**：李國清的
設計模式五大原則
1 單一職責 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定 義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種情...
設計模式的五大原則 五
乙個物件對其他物件最少的了解，又叫做最少知道的原則 盡量降低，類與類之間的耦合，類之間的弱耦合，如果大量使用迪公尺特法則 生活中的迪公尺特原則 例如 boos 讓部門經理我要你們部門的人的所有材料，顯然boos不會親自幹這個事了，boos通知部門經理，部門經理在通知工作人員你們把材料交到我的手中，經...
OO設計五大原則
oo的五大原則是指srp ocp lsp dip isp 1.srp single responsibility principle 單一職責原則 單一職責很容易理解，所謂單一職責，就是乙個設計元素只做一件事。srp 原則的核心含義是只能讓乙個類有且只有乙個職責，永遠不要讓乙個類存在多個改變的理由。...