面向對象設計原則

㈠ 面向對象設計原則有哪些

SRP單一職來責原則
就一個類而言源，應該專注於做一件事和僅有一個引起它變化的原因。
OCP開放－－封閉原則
對於擴展開放，對於修改封閉。
LSP里氏替換原則
子（繼承）類能在程序中代替父類（C#：基類，Java：超類）。
DIP 依賴倒置原則
抽象不依賴於細節，細節應該依賴抽象。（面向抽象編程，C#為面向介面編程）。
ISP介面隔離原則
介面屬於用戶類。（介面面用用戶類，不用想著和自身層次、方法相關）
REP重用發布等價原則
重用的粒度就是發布的粒度。（？這個沒有具體的認識）
CCP共同封閉原則
對於需求的響應，一個包中的所以類，有一個共同的響應（改變），而對於包外是不造成影響。
CRP 共同重用原則
包中的所有類共同重用，就是要重用就全部重用。
ADP 無環依賴原則
依賴關系不要存在環。
ADP 穩定依賴原則
朝著穩定的方向進行依賴。
SAP穩定抽象原則
包的抽象程度應該和穩定程序一致。

㈡ JAVA面向對象設計有哪些原則

一、單一職責原則（SRP）
就一個類而言，應該僅有一個引起它變化的原因。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。測試驅動的開發實踐常常會在設計出現臭味之前就迫使我們分離職責。

二、開閉原則（OCP）

軟體實體（類、模塊、函數）應該是可擴展的，但是不可修改的。也就是說：對於擴展是開放的，對於更改是封閉的。怎樣可能在不改動模塊源代碼的情況下去更改它的行為呢？怎樣才能在無需對模塊進行改動的情況下就改變它的功能呢？關鍵是抽象！因此在進行面向對象設計時要盡量考慮介面封裝機制、抽象機制和多態技術。該原則同樣適合於非面向對象設計的方法，是軟體工程設計方法的重要原則之一。

三、替換原則（LSP）

子類應當可以替換父類並出現在父類能夠出現的任何地方。這個原則是Liskov於1987年提出的設計原則。它同樣可以從Bertrand Meyer 的DBC (Design by Contract〔基於契約設計〕) 的概念推出。

四、依賴倒置原則（DIP）

1、高層模塊不應該依賴於低層模塊。二者都應該依賴於抽象。2、抽象不應該依賴於細節。細節應該依賴於抽象。在進行業務設計時，與特定業務有關的依賴關系應該盡量依賴介面和抽象類，而不是依賴於具體類。具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關系。在結構化設計中，我們可以看到底層的模塊是對高層抽象模塊的實現（高層抽象模塊通過調用底層模塊），這說明，抽象的模塊要依賴具體實現相關的模塊，底層模塊的具體實現發生變動時將會嚴重影響高層抽象的模塊，顯然這是結構化方法的一個\"硬傷\"。面向對象方法的依賴關系剛好相反，具體實現類依賴於抽象類和介面。

五、介面分離原則（ISP）

採用多個與特定客戶類有關的介面比採用一個通用的涵蓋多個業務方法的介面要好。ISP原則是另外一個支持諸如COM等組件化的使能技術。缺少ISP，組件、類的可用性和移植性將大打折扣。這個原則的本質相當簡單。如果你擁有一個針對多個客戶的類，為每一個客戶創建特定業務介面，然後使該客戶類繼承多個特定業務介面將比直接載入客戶所需所有方法有效。

以上五個原則是面向對象中常常用到的原則。此外，除上述五原則外，還有一些常用的經驗諸如類結構層次以三到四層為宜、類的職責明確化（一個類對應一個具體職責）等可供我們在進行面向對象設計參考。但就上面的幾個原則看來，我們看到這些類在幾何分布上呈現樹型拓撲的關系，這是一種良好、開放式的線性關系、具有較低的設計復雜度。一般說來，在軟體設計中我們應當盡量避免出現帶有閉包、循環的設計關系，它們反映的是較大的耦合度和設計復雜化。

---------------------------------------------------------------------------------------------------------

「你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。」

----------摘抄自《OOD 啟思錄》--Arthur J.Riel 著 鮑志雲 譯

(1)所有數據都應該隱藏在所在的類的內部。

(2)類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。

(3)盡量減少類的協議中的消息。

(4)實現所有類都理解的最基本公有介面。

(5)不要把實現細節(例如放置共用代碼的私有函數)放到類的公有介面中。
如果類的兩個方法有一段公共代碼，那麼就可以創建一個防止這些公共代碼的私有函數。

(6)不要以用戶無法使用或不感興趣的東西擾亂類的公有介面。

(7)類之間應該零耦合，或者只有導出耦合關系。也即，一個類要麼同另一個類毫無關系，要麼只使用另一個類的公有介面中的操作。

(8)類應該只表示一個關鍵抽象。
包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 .

(9)把相關的數據和行為集中放置。
設計者應當留意那些通過get之類操作從別的對象中獲取數據的對象。這種類型的行為暗示著這條經驗原則被違反了。

(10)把不相關的信息放在另一個類中(也即：互不溝通的行為)。
朝著穩定的方向進行依賴.

(11)確保你為之建模的抽象概念是類，而不只是對象扮演的角色。

(12)在水平方向上盡可能統一地分布系統功能，也即：按照設計，頂層類應當統一地共享工作。

(13)在你的系統中不要創建全能類/對象。對名字包含Driver、Manager、System、Susystem的類要特別多加小心。
規劃一個介面而不是實現一個介面。

(14)對公共介面中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數據和行為沒有集中存放。

(15)對包含太多互不溝通的行為的類多加小心。
這個問題的另一表現是在你的應用程序中的類的公有介面中創建了很多的get和set函數。

(16)在由同用戶界面交互的面向對象模型構成的應用程序中，模型不應該依賴於界面，界面則應當依賴於模型。

(17)盡可能地按照現實世界建模(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關數據和行為的原則而違背這條原則) 。

(18)從你的設計中去除不需要的類。
一般來說，我們會把這個類降級成一個屬性。

(19)去除系統外的類。
系統外的類的特點是，抽象地看它們只往系統領域發送消息但並不接受系統領域內其他類發出的消息。

(20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。

(21)我們在創建應用程序的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。

(22)盡量減少類的協作者的數量。
一個類用到的其他類的數目應當盡量少。

(23)盡量減少類和協作者之間傳遞的消息的數量。

(24)盡量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同消息的數量。

(25)盡量減少類的扇出，也即：減少類定義的消息數和發送的消息數的乘積。

(26)如果類包含另一個類的對象，那麼包含類應當給被包含的對象發送消息。也即：包含關系總是意味著使用關系。

(27)類中定義的大多數方法都應當在大多數時間里使用大多數數據成員。

(28)類包含的對象數目不應當超過開發者短期記憶的容量。這個數目常常是6。
當類包含多於6個數據成員時，可以把邏輯相關的數據成員劃分為一組，然後用一個新的包含類去包含這一組成員。

(29)讓系統功能在窄而深的繼承體系中垂直分布。

(30)在實現語義約束時，最好根據類定義來實現。這常常會導致類泛濫成災，在這種情況下，約束應當在類的行為中實現，通常是在構造函數中實現，但不是必須如此。

(31)在類的構造函數中實現語義約束時，把約束測試放在構造函數領域所允許的盡量深的包含層次中。

(32)約束所依賴的語義信息如果經常改變，那麼最好放在一個集中式的第3方對象中。

(33)約束所依賴的語義信息如果很少改變，那麼最好分布在約束所涉及的各個類中。

(34)類必須知道它包含什麼，但是不能知道誰包含它。

(35)共享字面范圍(也就是被同一個類所包含)的對象相互之間不應當有使用關系。

(36)繼承只應被用來為特化層次結構建模。

(37)派生類必須知道基類，基類不應該知道關於它們的派生類的任何信息。

(38)基類中的所有數據都應當是私有的，不要使用保護數據。
類的設計者永遠都不應該把類的使用者不需要的東西放在公有介面中。

(39)在理論上，繼承層次體系應當深一點，越深越好。

(40)在實踐中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度值是6。

(41)所有的抽象類都應當是基類。

(42)所有的基類都應當是抽象類。

(43)把數據、行為和/或介面的共性盡可能地放到繼承層次體系的高端。

(44)如果兩個或更多個類共享公共數據(但沒有公共行為)，那麼應當把公共數據放在一個類中，每個共享這個數據的類都包含這個類。

(45)如果兩個或更多個類有共同的數據和行為(就是方法)，那麼這些類的每一個都應當從一個表示了這些數據和方法的公共基類繼承。

(46)如果兩個或更多個類共享公共介面(指的是消息，而不是方法)，那麼只有他們需要被多態地使用時，他們才應當從一個公共基類繼承。

(47)對對象類型的顯示的分情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多態。

(48)對屬性值的顯示的分情況分析常常是錯誤的。類應當解耦合成一個繼承層次結構，每個屬性值都被變換成一個派生類。

(49)不要通過繼承關系來為類的動態語義建模。試圖用靜態語義關系來為動態語義建模會導致在運行時切換類型。

(50)不要把類的對象變成派生類。對任何只有一個實例的派生類都要多加小心。

(51)如果你覺得需要在運行時刻創建新的類，那麼退後一步以認清你要創建的是對象。現在，把這些對象概括成一個類。

(52)在派生類中用空方法(也就是什麼也不做的方法)來覆寫基類中的方法應當是非法的。

(53)不要把可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來泛濫成災的類。

(54)在創建繼承層次時，試著創建可復用的框架，而不是可復用的組件。

(55)如果你在設計中使用了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要設法證明。

(56)只要在面向對象設計中用到了繼承，問自己兩個問題：(1)派生類是否是它繼承的那個東西的一個特殊類型？(2)基類是不是派生類的一部分？

(57)如果你在一個面向對象設計中發現了多重繼承關系，確保沒有哪個基類實際上是另一個基類的派生類。

(58)在面向對象設計中如果你需要在包含關系和關聯關系間作出選擇，請選擇包含關系。

(59)不要把全局數據或全局函數用於類的對象的薄記工作。應當使用類變數或類方法。

(60)面向對象設計者不應當讓物理設計准則來破壞他們的邏輯設計。但是，在對邏輯設計作出決策的過程中我們經常用到物理設計准則。
(61)不要繞開公共介面去修改對象的狀態。

㈢ 面向對象原則

面向對象的原則，面向對象，應該有自己的做人的底線和原則信信。

㈣ java面向對象設計原則和設計模式詳解

Java面向對象設計原則
1) Open-Close Principle（OCP），開-閉原則，講的是設計要對擴展有好的支持，而對修改要嚴格限制。這是最重要也是最為抽象的原則，基本上我們所說的Reusable Software既是基於此原則而開發的。其他的原則也是對它的實現提供了路徑。
2) Liskov Substituition Principle（LSP），里氏代換原則，很嚴格的原則，規則是「子類必須能夠替換基類，否則不應當設計為其子類。」也就是說，子類只能去擴展基類，而不是隱藏或覆蓋基類.
3) Dependence Inversion Principle（DIP），依賴倒換原則，「設計要依賴於抽象而不是具體化」。換句話說就是設計的時候我們要用抽象來思考，而不是一上來就開始劃分我需要哪些哪些類，因為這些是具體。這樣做有什麼好處呢？人的思維本身實際上就是很抽象的，我們分析問題的時候不是一下子就考慮到細節，而是很抽象的將整個問題都構思出來，所以面向抽象設計是符合人的思維的。另外這個原則會很好的支持OCP，面向抽象的設計使我們能夠不必太多依賴於實現，這樣擴展就成為了可能，這個原則也是另一篇文章《Design by Contract》的基石。
4) Interface Segregation Principle（ISP），「將大的介面打散成多個小介面」，這樣做的好處很明顯，我不知道有沒有必要再繼續描述了，為了節省篇幅，實際上我對這些原則只是做了一個小總結，如果有需要更深入了解的話推薦看《Java與模式》，MS MVP的一本巨作！^_^
5) Composition/Aggregation Reuse Principle（CARP），設計者首先應當考慮復合/聚合，而不是繼承（因為它很直觀，第一印象就是「哦，這個就是OO啊」）。這個就是所謂的「Favor Composition over Inheritance」，在實踐中復合/聚合會帶來比繼承更大的利益，所以要優先考慮。
6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法則或最少知識原則，這個原則首次在Demeter系統中得到正式運用，所以定義為迪米特法則。它講的是「一個對象應當盡可能少的去了解其他對象」。也就是又一個關於如何松耦合（Loosely-Coupled）的法則。
設計模式：
1）適配器模式
http://eneasy.javaeye.com/blog/174838
2）橋接器模式
http://eneasy.javaeye.com/blog/174892
3）職責鏈模式
http://eneasy.javaeye.com/blog/174906
4）命令模式
http://eneasy.javaeye.com/blog/174896
5）裝飾器模式
http://eneasy.javaeye.com/blog/174840
6）外觀模式
http://eneasy.javaeye.com/blog/174890
7）工廠模式
http://eneasy.javaeye.com/blog/174831
8）享元模式
http://eneasy.javaeye.com/blog/174891
9）代理模式
http://eneasy.javaeye.com/blog/174887
10）單例模式
http://eneasy.javaeye.com/blog/174829
11）狀態模式
http://eneasy.javaeye.com/blog/174897
12）策略模式
http://eneasy.javaeye.com/blog/174894
13）模板模式
http://eneasy.javaeye.com/blog/174893
14）訪問者模式
http://eneasy.javaeye.com/blog/174914

㈤ 面向對象應該遵循什麼原則

題目太寬泛了，你就跟考官隨便扯點。。。

1.封裝原則，簡單的說就是不改給人看見的就不要讓人看見，就好比冠生園生產月餅，裡面的心都是封裝在皮下面的，要不是被曝光你根本不知道它已經過期了。。。

2.努力降低類之間的耦合度，就像一個女人盤了個發髻，看著舒服，但盤起來那是相當的費勁，頭皮上再來個虱子，手都不知道怎麼伸進去撓癢。同樣在類設計中，不要讓各個類之間發生過多依賴關系，系統中的職責要分配給不同的對象去完成，對象之間不應該越俎代庖，只需做好本職就行了

3.好萊塢原則，它允許低層組件將自己掛鉤到高層組件上以供使用。如果高層類依賴底層的方法，底層又調用高層的，這就形成了環形依賴，典型的依賴腐敗啊！怎麼治理，一句話，只需周官放火，不許百姓點燈。。。

4.開閉原則：對擴展開放，對修改關閉。盡量不要修改已經完成的模塊來實現功能的擴展，不說啥了。。。

推薦樓主去看head first design pattern，或許能對樓主有所幫助

㈥ 面向對象設計的6個設計原則最早誰提出的

Booch最先描述了面向對象的軟體開發方法的基礎問題。

面向對象設計的六大基本原則:
1)開閉原則
2)里氏代換原則
3)依賴倒轉原則
4)介面隔離原則
5)迪米特法則
6)合成/聚合復用原則

㈦ 面向對象的核心原則是什麼

61條面向對象設計的經驗原則
摘抄自《OOD 啟思錄》--Arthur J.Riel 著 鮑志雲 譯

「你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。」

「你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。」

----------Arthur J.Riel

(1)所有數據都應該隱藏在所在的類的內部。p13

(2)類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。p15

(3)盡量減少類的協議中的消息。p16

(4)實現所有類都理解的最基本公有介面[例如，拷貝操作(深拷貝和淺拷貝)、相等性判斷、正確輸出內容、從ASCII描述解析等等]。 p16

(5)不要把實現細節(例如放置共用代碼的私有函數)放到類的公有介面中。p17

如果類的兩個方法有一段公共代碼，那麼就可以創建一個防止這些公共代碼的私有函數。

(6)不要以用戶無法使用或不感興趣的東西擾亂類的公有介面。p17

(7)類之間應該零耦合，或者只有導出耦合關系。也即，一個類要麼同另一個類毫無關系，要麼只使用另一個類的公有介面中的操作。 p18

(8)類應該只表示一個關鍵抽象。p19

包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 .

(9)把相關的數據和行為集中放置。p19

設計者應當留意那些通過get之類操作從別的對象中獲取數據的對象。這種類型的行為暗示著這條經驗原則被違反了。

(10)把不相關的信息放在另一個類中(也即：互不溝通的行為)。p19

朝著穩定的方向進行依賴.

(11)確保你為之建模的抽象概念是類，而不只是對象扮演的角色。p23

(12)在水平方向上盡可能統一地分布系統功能，也即：按照設計，頂層類應當統一地共享工作。p30

(13)在你的系統中不要創建全能類/對象。對名字包含Driver、Manager、System、Susystem的類要特別多加小心。p30

規劃一個介面而不是實現一個介面。

(14)對公共介面中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數據和行為沒有集中存放。p30

(15)對包含太多互不溝通的行為的類多加小心。p31

這個問題的另一表現是在你的應用程序中的類的公有介面中創建了很多的get和set函數。

(16)在由同用戶界面交互的面向對象模型構成的應用程序中，模型不應該依賴於界面，界面則應當依賴於模型。p33

(17)盡可能地按照現實世界建模(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關數據和行為的原則而違背這條原則) 。p36

(18)從你的設計中去除不需要的類。p38

一般來說，我們會把這個類降級成一個屬性。

(19)去除系統外的類。p39

系統外的類的特點是，抽象地看它們只往系統領域發送消息但並不接受系統領域內其他類發出的消息。

(20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。p40

(21)我們在創建應用程序的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。p43

(22)盡量減少類的協作者的數量。p52

一個類用到的其他類的數目應當盡量少。

(23)盡量減少類和協作者之間傳遞的消息的數量。p55

(24)盡量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同消息的數量。p55

(25)盡量減少類的扇出，也即：減少類定義的消息數和發送的消息數的乘積。p55

(26)如果類包含另一個類的對象，那麼包含類應當給被包含的對象發送消息。也即：包含關系總是意味著使用關系。p55

(27)類中定義的大多數方法都應當在大多數時間里使用大多數數據成員。p57

(28)類包含的對象數目不應當超過開發者短期記憶的容量。這個數目常常是6。p57

當類包含多於6個數據成員時，可以把邏輯相關的數據成員劃分為一組，然後用一個新的包含類去包含這一組成員。

(29)讓系統功能在窄而深的繼承體系中垂直分布。p58

(30)在實現語義約束時，最好根據類定義來實現。這常常會導致類泛濫成災，在這種情況下，約束應當在類的行為中實現，通常是在構造函數中實現，但不是必須如此。p60

(31)在類的構造函數中實現語義約束時，把約束測試放在構造函數領域所允許的盡量深的包含層次中。p60

(32)約束所依賴的語義信息如果經常改變，那麼最好放在一個集中式的第3方對象中。p60

(33)約束所依賴的語義信息如果很少改變，那麼最好分布在約束所涉及的各個類中。p60

(34)類必須知道它包含什麼，但是不能知道誰包含它。p61

(35)共享字面范圍(也就是被同一個類所包含)的對象相互之間不應當有使用關系。p61

(36)繼承只應被用來為特化層次結構建模。p74

(37)派生類必須知道基類，基類不應該知道關於它們的派生類的任何信息。p74

(38)基類中的所有數據都應當是私有的，不要使用保護數據。p75

類的設計者永遠都不應該把類的使用者不需要的東西放在公有介面中。

(39)在理論上，繼承層次體系應當深一點，越深越好。p77

(40)在實踐中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度值是6。p77

(41)所有的抽象類都應當是基類。p81

(42)所有的基類都應當是抽象類。p82

(43)把數據、行為和/或介面的共性盡可能地放到繼承層次體系的高端。p85

(44)如果兩個或更多個類共享公共數據(但沒有公共行為)，那麼應當把公共數據放在一個類中，每個共享這個數據的類都包含這個類。 p88

(45)如果兩個或更多個類有共同的數據和行為(就是方法)，那麼這些類的每一個都應當從一個表示了這些數據和方法的公共基類繼承。 p89

(46)如果兩個或更多個類共享公共介面(指的是消息，而不是方法)，那麼只有他們需要被多態地使用時，他們才應當從一個公共基類繼承。 p89

(47)對對象類型的顯示的分情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多態。p89

(48)對屬性值的顯示的分情況分析常常是錯誤的。類應當解耦合成一個繼承層次結構，每個屬性值都被變換成一個派生類。 p96

(49)不要通過繼承關系來為類的動態語義建模。試圖用靜態語義關系來為動態語義建模會導致在運行時切換類型。p97

(50)不要把類的對象變成派生類。對任何只有一個實例的派生類都要多加小心。p99

(51)如果你覺得需要在運行時刻創建新的類，那麼退後一步以認清你要創建的是對象。現在，把這些對象概括成一個類。 p103

(52)在派生類中用空方法(也就是什麼也不做的方法)來覆寫基類中的方法應當是非法的。p103

(53)不要把可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來泛濫成災的類。p108

(54)在創建繼承層次時，試著創建可復用的框架，而不是可復用的組件。p112

(55)如果你在設計中使用了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要設法證明。p120

(56)只要在面向對象設計中用到了繼承，問自己兩個問題：(1)派生類是否是它繼承的那個東西的一個特殊類型？(2)基類是不是派生類的一部分？p121

(57)如果你在一個面向對象設計中發現了多重繼承關系，確保沒有哪個基類實際上是另一個基類的派生類。p122

(58)在面向對象設計中如果你需要在包含關系和關聯關系間作出選擇，請選擇包含關系。p135

(59)不要把全局數據或全局函數用於類的對象的薄記工作。應當使用類變數或類方法。p140

(60)面向對象設計者不應當讓物理設計准則來破壞他們的邏輯設計。但是，在對邏輯設計作出決策的過程中我們經常用到物理設計准則。 p149

(61)不要繞開公共介面去修改對象的狀態。p164

----------Arthur J.Riel

㈧ 面向對象設計中的要素與原則有哪些

面向抄對象三要素
封裝(Encapsulation)
繼承(Inheritance)
多態(Polymorphism)
面向對象五原則
單一職責原則(SRP)
開放-封閉原則(OCP)
Liskov替換原則(LSP)
依賴倒置原則(DIP)
介面隔離原則(ISP)

面向對象六視點
復用(Reusibility)
擴展(Extensibility)

㈨ 面向對象設計的原則是什麼

SRP單一職責原則 就一個類而言，應該專注於做一件事和僅有一個引起它變化的原因。 回OCP開放－－封閉答原則 對於擴展開放，對於修改封閉。 LSP里氏替換原則 子（繼承）類能在程序中代替父類（C#：基類，Java：超類）。 DIP 依賴倒置原則 抽象不依賴於細節，細節應該依賴抽象。（面向抽象編程，C#為面向介面編程）。 ISP介面隔離原則 介面屬於用戶類。（介面面用用戶類，不用想著和自身層次、方法相關） REP重用發布等價原則 重用的粒度就是發布的粒度。（？這個沒有具體的認識） CCP共同封閉原則 對於需求的響應，一個包中的所以類，有一個共同的響應（改變），而對於包外是不造成影響。 CRP 共同重用原則 包中的所有類共同重用，就是要重用就全部重用。 ADP 無環依賴原則 依賴關系不要存在環。 ADP 穩定依賴原則 朝著穩定的方向進行依賴。 SAP穩定抽象原則 包的抽象程度應該和穩定程序一致。

㈩ 面向對象五項基本原則

◆ SRP，單一職責原則，一個類應該有且只有一個改變的理由。

◆ OCP，開放封閉原則，你應該能夠不用修改原有類就能擴展一個類的行為。

◆ LSP，Liskov替換原則，派生類要與其基類自相容。

◆ DIP，依賴倒置原則，依賴於抽象而不是實現。

◆ ISP，介面隔離原則，客戶只要關注它們所需的介面