下面小編就為大家帶來一篇淺談java中OO的概念和設計原則(必看)。小編覺得蠻不錯的，現在就分享給大家，也給大家做個參考。一起跟著小編過來看看吧
一． OO(物件導向)的設計基礎
物件導向(OO)：就是基於物件概念，以物件為中心，以類別和繼承為建構機制，充分利用介面和多型提供彈性，來認識、理解、刻劃客觀世界和設計、建構對應的軟體系統。物件導向的特徵：雖然各種物件導向程式語言相互有別，但都能看到它們對物件導向基本特徵的支持，
即「抽象、封裝、繼承、多態」 ：
– 抽象，先不考慮細節
##– 封裝，就隱藏內部實現
– 繼承，重複使用現有程式碼
#– 多態，改寫物件行為
物件導向
設計模式：是“好的物件導向設計”，所謂“好的物件導向設計”是那些可以滿足“應對變化，提高複用”的設計。物件導向設計模式描述的是軟體設計，因此它是獨立於程式設計 語言的，但是物件導向設計模式的最終實作仍然要使用物件導向程式語言來表達。物件導向設計模式不像演算法技巧，可以照搬照用，它是建立在對「物件導向」純 熟、深入的理解的基礎上的經驗性認識。
上邊就見大的描述一下物件導向和設計模式的概念和關係。我們進行設計的時候，就是充分的理解和利用OO的四個基本的特徵來展開設計，所以大家必須在進行設計前，要熟悉和掌握面向對象的技術，在這就不詳細介紹了，而對於設計模式是給我們提供了設計時的參考
模型，而掌握物件導向設計模式的前提是先掌握「物件導向」技術。
二． OO(物件導向)的設計目標
※可擴充性Extensibility：有了新的需求，新的效能可以容易添加到系統中，不影響現有的效能，也不會帶來新的缺陷。
※可修改性Flexibility：系統一部分的程式碼要修改時不會破壞系統的現有結構，也不會影響到其它的部分。
※可替換性Pluggability：可以將系統中的某些程式碼替換為相同介面的其它類，不會影響到系統。
三． OO設計的5大原則及其之間的關係
#3.1 OO設計原則的總結
※單一職責原則:就一個類別而言，應該只有一個造成它變化的原因。單一是一個類的優良設計。交雜不清的職責將使得程式碼看起來特別彆牽一發而動全身，有失美感和必然導致醜陋的系統錯誤風險。
※開放封閉原則:是說軟體實體（類別、模組、函數等等）應該可以擴充但不可修改。實現開開放封閉原則的核心思想是對抽象編程，而不對具體編程，因為抽象相對穩定。讓類別依賴固定的抽象，所以修改就是封閉的；而透過物件導向的繼承和多型機制，又可以實現對抽象類別的繼承，透過覆寫其方法來改變固有行為，實現新的拓展方法，所以就是開放的。 「需求總是改變」沒有不變的軟體，所以就需要用封閉開放原則來封閉變化滿足需求，同時還能維持軟體內部的封裝系統穩定，不被需求的變化影響。
※依賴倒置原則:依賴抽象，不要依賴具體。抽 象的穩定性決定了系統的穩定性，因為抽像是不變的，依賴抽像是物件導向設計的精髓，也是依賴倒置原則的核心。依賴抽像是一個通用的原則，而某些時候依 賴於細節則是在所難免的，必須權衡在抽象和具體之間的取捨，方法不是一層不變的。依賴抽象，就是對介面編程，不要對實作編程。
※里氏代換原則：子類型必須能夠替換到他們的父類型。 Liskov 替換原則，主要著眼於對抽象和多態建立在繼承的基礎上，因此只有遵循了Liskov替換原則，才能保證繼承復用是可靠地。實現的方法是面向介面程式設計：將公共部分抽象化為基底類別介面或抽象類，透過ExtractAbstractClass，在子類別中透過覆寫父類別的方法實作新的方式支持同樣的職責。 Liskov替 換原則能夠確保系統具有良好的拓展性，同時實現基於多態性的抽象機制，能夠減少程式碼冗餘，避免運作期間的類型判別。
※介面隔離原則: 多個和客戶相關的介面比一個通用介面好。分離的手段主要有以下兩種：1、委託分離，透過增加一個新的類型來委託客戶的請求，隔離客戶和介面的直接依賴，但是會增加系統的開銷。 2.多重繼承分離，透過介面多繼承來實現客戶的需求，這種方式是較好的。
下邊是前面沒有提到過的兩個原則，也是設計時要考慮的重要原則。
※迪米特法則：不互相直接溝通的類別之間，不要直接發生交互作用。如果兩個類別不必彼此直接通信，那麼這兩個類別就不應發生直接的交互作用。如果一個類別需要呼叫領一個類別的某個方法話，可以透過第三者轉發這個呼叫。迪米特法則首先強調的前提是在類別的設計上，每一類都應盡量降低成員的存取權限。它的根本思想是強調類別之間的鬆散耦合。
※合成/聚合重複使用原則：盡量使用合成/聚合，盡量不要使用繼承。合成(Composition)和聚合(Aggregation)都是關聯的特殊種類，聚合表示一種弱的擁有關係；合成這是一種強的擁有關係，體現了嚴格的部分和整體的關係，部分和整體的生命週期一樣。優先使用合成或聚合原則將有助於保持每個類別被封裝，並被集中在單一任務上。這樣類別和類別繼承層次會保持較小規模，並且不太可能成長為不可控制的龐然大物
#3.2 OO設計原則之間的關係
1. 實現「開-閉」原則（OCP）的關鍵步驟是抽象化。基底類別與子類別之間的繼承關係就是抽象化的體現。因此里氏代換原則是實現抽象化的具體步驟的規範。違反里氏代換原則意味著違反了「開-閉」原則，反之未必。
2. 「開-閉」原則與依賴倒轉原則(DIP)是目標與手段的關係。如果說開閉原則是目標,依賴倒閉原則是到達"開閉"原則的手段。如果要達到最好的"開閉"原則,就要盡量的遵守依賴倒轉原則，依賴倒轉原則是對"抽象化"的最好規範。
3. 里氏代換原則(LSP)是依賴倒轉原則的基礎，依賴倒轉原則是里氏代換原則的重要補充。
4. 介面分離原則(ISP)也是確保「開-閉」原則的一個重要手段。
5. 對於單一職責原則(SRP)，個人認為盡量做到為好，職責越單一，「開-閉」和里氏代換越容易實現。
四． OO設計原則和目標的關係
1.可擴展性Extensibility ：允許一個具有同樣介面的新類別取代舊類，是對抽象介面的複用。客戶端依賴抽象接口，而不是一個具體實現類，使得這個具體類可以被別的具體類替換，而不影響客戶端。以下原則實現可擴展性。
※開/閉原則
※里氏替換原則
※依賴倒轉原則
※合成/聚合復用原則
###################
2.可修改性Flexibility：模組相對獨立，通訊盡可能少。這樣當一個模組修改時，對別的模組的影響很小。
以下原則實作可修改性。
※開/閉原則
※迪米特法則
※介面隔離原則
3、可替換性Pluggability：
# #當一部分不再滿足需求時，可以將舊的部分拔出，新的部分插入。
以下原則實現可替換性。
※開/閉原則
※里氏代換原則
※依賴倒轉原則※合成/聚合復用原則
五． OO(物件導向)的設計流程
1. 分析式樣，進行機能分類。
2. 根據機能進行類別的抽象化。
※ 類別的抽象 - 在這裡步裡，我們可以根據 “單一職責原則”，進行類別的具體抽象。盡量做到，類別的功能單一和清晰化。 ※ 封裝變化點– 使用封裝來建立物件
之間的分界層，讓設計者可以在分界層的一側進行修改，而不會對另一側產生不良的影響，從而實現層次間的鬆散耦合。
3. 設計抽象基底類別和介面類別。
※ 在進行基本的基底類別的抽象和介面定義時，要遵照「介面分離原則」進行介面的抽象化。
※ 在設計介面和基類時，不要總是注意細節，要記住針對介面編程，而不是針對實作編程。
※ 對於抽象的基底類別和衍生類別之間要做到「里氏替換原則」的要求。
4.決定類別間的耦合關係。
4.1 決定耦合的程度的依據何在呢？
※ 簡單的說，就是依照需求的穩定性，來決定耦合的程度。
###※ 對於穩定性高的需求，不容易改變的需求，我們完全可以把各類設計成緊密耦合的，因為這樣可以提高效率，而且我們還可以使用一些更好的技術來提高效率或簡化程式碼。 ######※ 如果需求極有可能變化，我們就需要充分的考慮類別之間的耦合問題，我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個抽象層次可以是抽象的類、具體的類，也可以是接口，或是一組的類。我們可以用一句話來概括降低耦合度的思想："針對介面編程，而不是針對實現編程。######※ 在決定類別的耦合關係時，盡量考慮「迪米特法則」和「合成/聚合復用原則」。############4.2 怎麼做到依賴倒轉？############※ 以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關係總是要涉及具體類別從抽象類別繼承，並且需要保證在任何###引用###到基類的地方都可以改換成其子類，因此，里氏代換原則是依賴倒轉原則的基礎。 （1）任何###變數###都不應該持有一個指向特定類別的指標或引用。不應該覆寫它的任何基底類別中的已經實現的方法。 ######※ 對於類別的抽象和職能，是否滿足“單一職責原則”###※ 對於繼承關係和引用基類的地方，是否滿足“里氏代換原則”和“依賴倒置原則” ###※ 對於介面和基類，是否「介面隔離原則」###※ 總體上是否滿足「開-閉原則」#########總體上說，在物件導向設計時，要充分考慮設計的5大原則，但不是強求的，一味的追求滿足原則也可能會導致設計出的系統在性能和資源上的消耗，可以根據具體的情況來具體的分析和設計。 ##
以上是簡單介紹java中OO的概念設計原則(收藏)的詳細內容。更多資訊請關注PHP中文網其他相關文章！
