Java程式設計師熟悉以物件為導向的十個設計原則詳解

這篇文章主要為大家詳細介紹了Java程式設計師應當知道的10個物件導向設計原則，具有一定的參考價值，有興趣的夥伴們可以參考一下

物件導向設計原則是OOPS程式設計的核心， 但我見過的大多數Java程式設計師熱心於像Singleton (單例) 、 Decorator(裝飾器)、Observer(觀察者) 等設計模式，而沒有把足夠多的注意力放在學習物件導向的分析和設計上面。學習物件導向程式設計「抽象」、「封裝」、「多型」、「繼承」 等基礎知識是重要的，但同時為了創造簡潔、模組化的設計，了解這些設計原則也同等重要。我經常看到不同經驗程度的java程式設計師，他們有的不知道這些OOPS 和SOLID設計原則，有的只是不知道一個特定的設計原則會帶來怎樣的好處，甚至不知道在編碼中如何使用這些設計原則。

(設計原則)底線是永遠追求高內聚、低耦合的編碼或設計。 Apache 和 Sun的開源程式碼是學習Java和OOPS設計原則的良好範例。它們向我們展示了，設計原則在Java程式設計中是如何使用的。 Java JDK 使用了一些設計原則：BorderFactory類別中的工廠模式、Runtime類別中的單例模式、java.io 類別中的裝飾器模式。順便說一句，如果您真的對Java編碼原則感興趣，請閱讀Joshua Bloch 的Effective Java，他編寫過Java API。我個人最喜歡的關於物件導向設計模式的是Kathy Sierra的Head First Design Pattern(深入淺出設計模式)，以及其它的關於深入淺出物件導向分析和設計。這些書對編寫更好的程式碼有很大幫助，充分利用各種物件導向和SOLID的設計模式。

雖然學習設計模式(原則)最好的方法是現實中的例子和理解違反設計原則帶來的不便，本文的宗旨是向那些沒有接觸過或正處於學習階段的Java程式設計師介紹物件導向設計原則。我個人認為OOPS 和SOLID設計原則需要有文章清楚的介紹它們，在此我一定盡力做到這一點，但現在請您準備瀏覽以下設計模式(原則) :)
DRY – Don't repeat yourself

我們第一個物件導向設計原則是：DRY ，從名稱可以看出DRY(don't repeat yourself)意思是不寫重複程式碼，而是抽象化成可重複使用的程式碼區塊。如果您有兩處以上相同的程式碼區塊，請考慮把它們抽象成一個單獨的方法；或者您多次使用了硬編碼的值，請把它們設定成公共常數。這種物件導向設計原則的優點是易於維護。重要的是不要濫用此原則，重複不是針對程式碼而是針對功能。它的意思是，如果您使用通用程式碼來驗證OrderID和SSN，這並不意味著它們是相同的或他們今後將保持不變。透過把通用程式碼用於實現兩種不同的功能，或者您將這兩種不同的功能密切聯繫在一起；當您的OrderID格式改變時，您的SSN驗證程式碼將會中斷。所以要當心這種耦合，而且不要把彼此之間沒有任何關係卻類似的程式碼組合在一起。

封裝經常修改的程式碼

Encapsulate What Changes

在軟體領域永遠不變的是“變化”，所以把您認為或懷疑將來要被修改的程式碼封裝起來。這種物件導向設計模式的優點是：易於測試和維護適當封裝的程式碼。如果您正在用Java編程，那麼請遵守以下原則：變數和方法的存取權限預設為私有，並且逐步放開它們的存取權限，例如從“private”到“protected ”、“ not public」。 Java中的一些設計模式使用了封裝，工廠設計模式就是一個例子，它封裝了創建物件的程式碼而且提供了以下靈活性：後續生成新物件不影響現有的程式碼。

開啟/關閉設計原則

OpenClosed Design Principle

類別、方法/函數應為擴充(新功能)開放，對修改閉合。這是另一個優雅的SOLID 設計原則，以防止有人修改通過測試的程式碼。理想情況下假如您新增了新功能，那麼您的程式碼要經過測試，這就是開啟/關閉設計原則的目標。順便說一句，SOLID中的字母“O”指的是開啟/關閉設計原則。

單一職責原則

Single Responsibility Principle(SRP)

單一職責原則是另一個SOLID設計原則，SOLID中的字母「S」指的就是它。依照SRP，一個類別修改的原因應有且只有一個，或一個類別應總是實現單一功能。如果您在Java中的一個類別實現了多個功能，那麼這些功能之間便產生了耦合關係；如果您修改其中的一個功能，您有可能就打破了這種耦合關係，那麼就要進行另一輪測試以避免產生新的問題。

依賴注入/反轉原則

Dependency Injection or Inversion principle

不要問框架的依賴注入功能將會為你帶來什麼好處，依賴注入功能在spring框架裡已經很好的得到了實現，這一設計原則的優雅之處在於：DI框架注入的任何一個類都易於用模擬對象進行測試，並且更易於維護，因為創建物件的程式碼在框架裡是集中的而且和客戶端程式碼是隔離的。有多種方法可以實現依賴注入，例如使用字節碼工具，其中一些AOP(面向切面編程)框架如切入點表達式或spring裡使用的代理。想對這種SOLID設計原則了解更多，請看IOC 和 DI設計模式中的範例。 SOLID中的字母「D」指的就是這種設計原則。

優先使用組合而非繼承

Favor Composition over Inheritance

如果可以的話，要優先使用組合而非繼承。你們中的一些人可能為此爭論，但我發現組合比繼承更有靈活性。組合允許在運行時透過設定屬性修改一個類別的行為，透過使用多態即以介面的形式實現類別之間的組合關係，並且為修改組合關係提供了靈活性。甚至 Effective Java也建議優先使用組合而非繼承。

里氏替換原則

Liskov Substitution Principle LSP

根據李氏替換原則，父類別出現的地方可以用子類別來替換，例如父類別的方法或函數被子類別物件替換應該沒有任何問題。 LSP和單一職責原則、介面隔離原則密切相關。如果一個父類別的功能比其子類別還要多，那麼它可能不支援這項功能，也違反了LSP設計原則。為了遵循 LSP SOLID設計原則，衍生類別或子類別(相對父類別比較)必須增強功能，而非減少。 SOLID中的字母「L」指的就是 LSP設計原則。

介面隔離原則

介面隔離原則指，如果不需要一個介面的功能，那麼就不要實作此介面。這大多在以下情況發生：一個介麵包含多種功能，而實作類別只需要其中一種功能。介面設計是一種棘手的工作，因為一旦發布了接口，您就不能修改它否則會影響實現該接口的類別。在Java中這種設計原則的另一個好處是：介面有一個特點，任何類別使用它之前都要實現該介面所有的方法，所以使用功能單一的介面意味著實作更少的方法。

程式設計以介面(而非實作物件)為中心

程式設計總是以介面(而非實作物件)為中心，這會使程式碼的結構靈活，而且任何一個新的介面實作物件都能相容於現有程式碼結構。所以在Java中，變數、方法傳回值、方法參數的資料型別請使用介面。這是許多Java程式設計師的建議， Effective Java 以及 head first design pattern 等書也這樣建議。

代理原則

不要期望一個類別完成所有的功能，可以適當地把一些函數交給代理類別實作。代理原則的典範是：Java 中的equals() 和 hashCode() 方法。為了比較兩個物件的內容是否相同，我們讓用於比較的類別本身完成對比工作而非它們的呼叫方。這種設計原則的好處是：沒有重複編碼而且很容易修改類別的行為。

總結

以上所有物件導向的設計原則可以幫助您寫出靈活、優雅的程式碼​​：具有高內聚低耦合的程式碼結構。理論只是第一步，更重要的是我們要學習一種能力去發現什麼時候使用這些設計原則。去發現我們是否違反了什麼設計原則和影響了程式碼的靈活性，但是世界上沒有什麼是完美的，我們解決問題時不能總去使用設計模式和設計原則，它們大多用於有較長維護週期的大型企業專案。

以上是Java程式設計師熟悉以物件為導向的十個設計原則詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！