java程序10個(gè)面向對象設計原則

　　本文的宗旨是向那些沒(méi)有接觸過(guò)或正處于學(xué)習階段的Java程序員介紹面向對象設計原則。我個(gè)人認為OOPS 和SOLID設計原則需要有文章清楚的介紹它們，在此我一定盡力做到這點(diǎn)，但現在請您準備瀏覽以下設計模式(原則) :

　　DRY – Don’t repeat yourself

　　我們第一個(gè)面向對象設計原則是：DRY ，從名稱(chēng)可以看出DRY(don’t repeat yourself)意思是不寫(xiě)重復代碼，而是抽象成可復用的代碼塊。如果您有兩處以上相同的代碼塊，請考慮把它們抽象成一個(gè)單獨的方法;或者您多次使用了硬編碼的值，請把它們設置成公共常量。這種面向對象設計原則的優(yōu)點(diǎn)是易于維護。重要的是不要濫用此原則，重復不是針對代碼而是針對功能來(lái)說(shuō)。它的意思是，如果您使用通用代碼來(lái)驗證OrderID和SSN，這并不意味著(zhù)它們是相同的或者他們今后將保持不變。通過(guò)把通用代碼用于實(shí)現兩種不同的功能，或者您把這兩種不同的功能密切地聯(lián)系在一起;當您的OrderID格式改變時(shí)，您的SSN驗證代碼將會(huì )中斷。所以要當心這種耦合，而且不要把彼此之間沒(méi)有任何關(guān)系卻類(lèi)似的代碼組合在一起。

　　封裝經(jīng)常修改的代碼

　　Encapsulate What Changes

　　在軟件領(lǐng)域永遠不變的是“變化”，所以把您認為或懷疑將來(lái)要被修改的代碼封裝起來(lái)。這種面向對象設計模式的優(yōu)點(diǎn)是：易于測試和維護恰當封裝的代碼。如果您在用Java編程，那么請遵守以下原則：變量和方法的訪(fǎng)問(wèn)權限默認設置為私有，并且逐步放開(kāi)它們的訪(fǎng)問(wèn)權限，例如從“private”到“protected ”、“not public”。Java中的一些設計模式使用了封裝，工廠(chǎng)設計模式就是一個(gè)例子，它封裝了創(chuàng )建對象的代碼而且提供了以下靈活性：后續生成新對象不影響現有的代碼。

　　打開(kāi)/關(guān)閉設計原則

　　OpenClosed Design Principle

　　類(lèi)、方法/函數應當是對擴展(新功能)開(kāi)放，對修改閉合。這是另外一個(gè)優(yōu)雅的SOLID 設計原則，以防止有人修改通過(guò)測試的代碼。理想情況下假如您添加了新功能，那么您的代碼要經(jīng)過(guò)測試，這就是打開(kāi)/關(guān)閉設計原則的目標。順便說(shuō)一句，SOLID中的字母“O”指的是打開(kāi)/關(guān)閉設計原則。

　　單一職責原則

　　Single Responsibility Principle(SRP)

　　單一職責原則是另外一個(gè)SOLID設計原則，SOLID中的字母“S”指的就是它。按照SRP，一個(gè)類(lèi)修改的原因應當有且只有一個(gè)，或者一個(gè)類(lèi)應當總是實(shí)現單一功能。如果您在Java中的一個(gè)類(lèi)實(shí)現了多個(gè)功能，那么這些功能之間便產(chǎn)生了耦合關(guān)系;如果您修改其中的一個(gè)功能，您有可能就打破了這種耦合關(guān)系，那么就要進(jìn)行另一輪測試以避免產(chǎn)生新的問(wèn)題。

　　依賴(lài)注入/反轉原則

　　Dependency Injection or Inversion principle

　　不要問(wèn)框架的依賴(lài)注入功能將會(huì )給你帶來(lái)什么益處，依賴(lài)注入功能在spring框架里已經(jīng)很好的得到了實(shí)現，這一設計原則的優(yōu)雅之處在于：DI框架注入的任何一個(gè)類(lèi)都易于用模擬對象進(jìn)行測試，并且更易于維護，因為創(chuàng )建對象的代碼在框架里是集中的而且和客戶(hù)端代碼是隔離的。有多種方法可以實(shí)現依賴(lài)注入，例如使用字節碼工具，其中一些AOP(面向切面編程)框架如切入點(diǎn)表達式或者spring里使用的代理。想對這種SOLID設計原則了解更多，請看IOC 和 DI設計模式中的例子。 SOLID中的字母“D”指的就是這種設計原則。

　　優(yōu)先使用組合而非繼承

　　Favor Composition over Inheritance

　　如果可以的話(huà)，要優(yōu)先使用組合而非繼承。你們中的一些人可能為此爭論，但我發(fā)現組合比繼承更有靈活性。組合允許在運行時(shí)通過(guò)設置屬性修改一個(gè)類(lèi)的行為，通過(guò)使用多態(tài)即以接口的形式實(shí)現類(lèi)之間的組合關(guān)系，并且為修改組合關(guān)系提供了靈活性。甚至 Effective Java也建議優(yōu)先使用組合而非繼承。

　　里氏替換原則

　　Liskov Substitution Principle LSP

　　根據里氏替換原則，父類(lèi)出現的地方可以用子類(lèi)來(lái)替換，例如父類(lèi)的方法或函數被子類(lèi)對象替換應該沒(méi)有任何問(wèn)題。LSP和單一職責原則、接口隔離原則密切相關(guān)。如果一個(gè)父類(lèi)的功能比其子類(lèi)還要多，那么它可能不支持這一功能，而且也違反了LSP設計原則。為了遵循 LSP SOLID設計原則，派生類(lèi)或子類(lèi)(相對父類(lèi)比較)必須增強功能，而非減少。SOLID中的字母“L”指的就是 LSP設計原則。

　　接口隔離原則

　　接口隔離原則指，如果不需要一個(gè)接口的功能，那么就不要實(shí)現此接口。這大多在以下情況發(fā)生：一個(gè)接口包含多種功能，而實(shí)現類(lèi)只需要其中一種功能。接口設計是一種棘手的工作，因為一旦發(fā)布了接口，您就不能修改它否則會(huì )影響實(shí)現該接口的類(lèi)。在Java中這種設計原則的另一個(gè)好處是：接口有一個(gè)特點(diǎn)，任何類(lèi)使用它之前都要實(shí)現該接口所有的方法，所以使用功能單一的接口意味著(zhù)實(shí)現更少的方法。

　　編程以接口(而非實(shí)現對象)為中心

　　編程總是以接口(而非實(shí)現對象)為中心，這會(huì )使代碼的結構靈活，而且任何一個(gè)新的接口實(shí)現對象都能兼容現有代碼結構。所以在Java中，變量、方法返回值、方法參數的數據類(lèi)型請使用接口。這是許多Java程序員的建議， Effective Java 以及 head first design pattern 等書(shū)也這樣建議。

　　代理原則

　　不要期望一個(gè)類(lèi)完成所有的功能，可以適當地把一些功能交給代理類(lèi)實(shí)現。代理原則的典范是：Java 中的equals() 和 hashCode() 方法。為了比較兩個(gè)對象的內容是否相同，我們讓用于比較的類(lèi)本身完成對比工作而非它們的調用方。這種設計原則的好處是：沒(méi)有重復編碼而且很容易修改類(lèi)的行為。

　　總結

　　以上所有面向對象的設計原則可以幫助您寫(xiě)出靈活、優(yōu)雅的代碼：具有高內聚低耦合的代碼結構。理論只是第一步，更重要的是我們要習得一種能力去發(fā)現什么時(shí)候使用這些設計原則。去發(fā)現我們是否違反了什么設計原則和影響了代碼的靈活性，但是世界上沒(méi)有什么是完美的，我們解決問(wèn)題時(shí)不能總去使用設計模式和設計原則，它們大多用于有較長(cháng)維護周期的大型企業(yè)項目。

【java程序10個(gè)面向對象設計原則】相關(guān)文章：

Java面向對象設計的經(jīng)驗原則10-02

關(guān)于java面向對象編程10-06

java面向對象編程題庫及答案07-28

JAVA面向對象的三大特性06-14

PHP程序面向對象分析設計的經(jīng)驗小結10-06

2016年java面向對象編程題庫及答案10-24

Javascript 面向對象編程11-04

2017年計算機java面向對象知識點(diǎn)06-30

javascript面向對象中的對象怎么理解09-02

面向對象編程的javascript基礎08-22