什麼是物件導向的原則

要把軟體做得非常靈活又要方便維護是一件很困難的事。靈活的軟體他的結構就複雜，維護起來就困難。有得必有失，關鍵在於如何處理這兩者，使得大於失。軟體的設計開發應遵循以下六大原則： 
1. OCP 
全名為：「Open-Closed Principle」開放－封閉原則 
#說明：對擴充開放，對修改關閉。 
優點：依照OCP原則設計出來的系統，降低了程序各部分之間的耦合性，其適應性、彈性、穩定性都比較好。當已有軟體系統需要增加新的功能時，不需要對作為系統基礎的抽象層進行修改，只需要在原有基礎上附加新的模組就能實現所需增加的功能。增加的新模組對原有的模組完全沒有影響或影響很小，這樣就無須為原有模組進行重新測試。 
如何實現「開-閉」原則 
在物件導向設計中，不允許改變的是系統的抽象層，而允許擴充的是系統的實作層。換言之，定義一個一勞永逸的抽象設計層，允許盡可能多的行為在實現層被實現。 
解決問題關鍵在於抽象化，抽象化是物件導向設計的第一個核心本質。 
對一個事物抽象化，實質上是在概括歸納地總結它的本質。抽象化讓我們抓住最重要的東西，從更高層思考。這降低了思考的複雜度，我們不用同時考慮那麼多的東西。換言之，我們封裝了事物的本質，看不到任何細節。
在物件導向程式設計中，透過抽象類別及接口，規定了具體類別的特徵作為抽象層，相對穩定，不需更改，從而滿足「對修改關閉」；而從抽象類別導出的具體類別可以改變系統的行為，從而滿足「對擴展開放」。 
對實體進行擴充時，不必改變軟體的原始碼或二進位代碼。關鍵在於抽象。

2. LSP 
全名：「Liskov Substitution Principle」 里氏代換原則 
#說明：子類型必須能夠替換它們的基底類型。一個軟體實體如果使用的是一個基類，那麼當把這個基類替換成繼承該基類的子類，程式的行為不會發生任何變化。軟體實體察覺不出基類物件和子類物件的區別。 
優點：可以很容易的實作同一父類別下各個子類別的互換，而客戶端可以毫不察覺。 

3. DIP 
全名：「Dependence Inversion Principle」依賴倒置原則 
說明：要依賴抽象，不要依賴具體。客戶端依賴抽象耦合。 
抽像不應依賴細節；細節應依賴抽象； 
要針對介面編程，不針對實作程式設計。 
優點：使用傳統流程化程式設計所創建的依賴關係，策略依賴細節，這是糟糕的，因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴抽象，抽象的穩定性決定了系統的穩定性。 
怎樣做到依賴倒置？ 
以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關係總是要涉及具體類別從抽象類別繼承，並且需要確保在任何引用到基類的地方都可以改換成其子類，因此，里氏代換原則是依賴倒轉原則的基礎。
在抽象層次上的耦合雖然有彈性，但也帶來了額外的複雜性，如果一個具體類別發生變化的可能性非常小，那麼抽象耦合能發揮的好處便十分有限，這時可以用具體耦合反而會更好。 
層次化：所有結構良好的物件導向架構都具有清晰的層次定義，每個層次透過一個定義良好的、受控的介面向外提供一組內聚的服務。 
依賴抽象：建議不依賴特定類別，即程式中所有的依賴關係都應該終止於抽象類別或介面。盡量做到： 
1、任何變數都不應該持有一個指向特定類別的指標或引用。 
2、任何類別都不應該從特定類別派生。 
3、任何方法都不應該覆寫它的任何基底類別中的已經實現的方法。 

4. ISP 
全名為：「Interface Segregation Principle」 介面隔離原則 
說明：使用多個專一功能的介面比使用一個的總介面總好。從一個客戶類別的角度來講：一個類別對另一個類別的依賴性應是建立在最小介面上的。過於臃腫的介面是對介面的污染，不應該強迫客戶依賴它們不用的方法。 
優點：會使一個軟體系統功能擴展時，修改的壓力不會傳到別的物件那裡。 
如何實作介面隔離原則 
#不應該強迫使用者依賴他們不用的方法。 
1、利用委託分離介面。 
2、利用多重繼承分離介面。

5. CARP or CRP 
全名："Composite/Aggregate Reuse Principle」合成/聚合復用原則or “ Composite Reuse Principle” 合成復用原則 
說明：如果新物件的某些功能在別的已經創建好的物件裡面已經實現，那麼盡量使用別的對象提供的功能，使之成為新物件的一部分，而不要自己再重新創建。新物件透過向這些物件的委派達到復用已有功能的。 
簡而言之，要盡量使用合成/聚合，盡量不要使用繼承。 
優點： 
1) 新物件存取成分物件的唯一方法是透過成分物件的介面。 
2) 這種複用是黑箱復用，因為成分物件的內部細節是新物件所看不見的。 
3) 這種複用支撐包裝。 
4) 這種複用所需的依賴較少。 
5) 每一個新的類別可以將焦點集中在一個任務上。 
6) 這種複用可以在運行時間內動態進行，新物件可以動態的引用與成分物件類型相同的物件。 
7) 作為複用手段可以應用到幾乎任何環境中去。 
缺點: 
就是系統中會有較多的物件需要管理。

6. LOD or LKP 
全名：「Law of Demeter」 迪米特原則or “Least Knowledge Principle” 最少知識原則 
#說明：物件與物件之間應該使用盡可能少的方法來關聯，避免千絲萬縷的關係。
如何實現迪米特法則 
迪米特法則的主要用意是控制資訊的過載，在將其運用到系統設計中應注意以下幾點： 
1) 在類別的分割上，應創建有弱耦合的類別。類別之間的耦合越弱，就越有利於復用。 
2) 在類別的結構設計上，每個類別都應盡量降低成員的存取權限。一個類別不應當public自己的屬性，而應提供取值和賦值的方法讓外界間接存取自己的屬性。 
3) 在類別的設計上，只要有可能，一個類別應設計成不變類別。 
4) 在對其它物件的引用上，一個類別對其它物件的引用應該降到最低。


還有單一職責原則： 

SRP簡介（SRP--Single-Responsibility Principle）：就一個類別而言，應該只專注於做一件事和僅有一個引起它變化的原因。所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有一個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我們修改這個類，那麼你就要考慮撤分這個類了。因為職責是變化的一個軸線，當需求變化時，該變化會反映類別的職責的變化。 使用SRP注意點：1、一個合理的類，應該只有一個引起它變化的原因，即單一職責； 
2、在沒有變化徵兆的情況下應用SRP或其他原則是不明智的； 
3、在需求實際改變時就應該應用SRP等原則來重構程式碼； 
4、使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理程式碼； 
5、如果測試不能迫使職責分離，僵化性和脆弱性的臭味會變得很強烈，那就應該用Facade或Proxy模式對程式碼重構；SRP優點：消除耦合，減小因需求變化引起程式碼僵化。 


你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。 
-----Arthur J.Riel 
(1)所有資料都應該隱藏在所在的類別的內部。 
(2)類別的使用者必須依賴類別的共有接口，但類別不能依賴它的使用者。 p15 
(3)盡量減少類別的協定中的訊息。 
(4)實現所有類別都理解的最基本公有介面[例如，拷貝運算(深拷貝和淺拷貝)、相等性判斷、正確輸出內容、從ASCII描述解析等等]。 p16 
(5)不要把實作細節(例如放置共用程式碼的私有函數)放到類別的公有介面中。 
如果類別的兩個方法有一段公用程式碼，那麼就可以建立一個防止這些公用程式碼的私人函數。 
(6)不要以使用者無法使用或不感興趣的東西來擾亂類別的公有介面。 p17 
(7)類別之間應該零耦合，或只有導出耦合關係。也即，一個類別要麼同另一個類別毫無關係，要麼只使用另一個類別的公有介面中的操作。 p18 
(8)類別應該只表示一個關鍵抽象。 
包中的所有類別對於同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類別產生影響，而對其他的包不造成任何影響 . 
(9)把相關的資料和行為集中放置。 
設計者應留意那些透過get之類操作從別的物件取得資料的物件。這種類型的行為暗示著這項經驗原則被違反了。 
(10)把不相關的資訊放在另一個類別中(也即：互不溝通的行為)。 p19 
朝著穩定的方向進行依賴. 
(11)確保你為之建模的抽象概念是類，而不只是物件扮演的角色。 p23 
(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)不要繞開公共介面去修改物件的狀態。

以上是什麼是物件導向的原則的詳細內容。更多資訊請關注PHP中文網其他相關文章！