- 相關(guān)推薦
java程序10個(gè)面向?qū)ο笤O(shè)計(jì)原則
本文的宗旨是向那些沒有接觸過或正處于學(xué)習(xí)階段的Java程序員介紹面向?qū)ο笤O(shè)計(jì)原則。我個(gè)人認(rèn)為OOPS 和SOLID設(shè)計(jì)原則需要有文章清楚的介紹它們，在此我一定盡力做到這點(diǎn)，但現(xiàn)在請(qǐng)您準(zhǔn)備瀏覽以下設(shè)計(jì)模式(原則) :
DRY – Don’t repeat yourself
我們第一個(gè)面向?qū)ο笤O(shè)計(jì)原則是：DRY ，從名稱可以看出DRY(don’t repeat yourself)意思是不寫重復(fù)代碼，而是抽象成可復(fù)用的代碼塊。如果您有兩處以上相同的代碼塊，請(qǐng)考慮把它們抽象成一個(gè)單獨(dú)的方法;或者您多次使用了硬編碼的值，請(qǐng)把它們設(shè)置成公共常量。這種面向?qū)ο笤O(shè)計(jì)原則的優(yōu)點(diǎn)是易于維護(hù)。重要的是不要濫用此原則，重復(fù)不是針對(duì)代碼而是針對(duì)功能來說。它的意思是，如果您使用通用代碼來驗(yàn)證OrderID和SSN，這并不意味著它們是相同的或者他們今后將保持不變。通過把通用代碼用于實(shí)現(xiàn)兩種不同的功能，或者您把這兩種不同的功能密切地聯(lián)系在一起;當(dāng)您的OrderID格式改變時(shí)，您的SSN驗(yàn)證代碼將會(huì)中斷。所以要當(dāng)心這種耦合，而且不要把彼此之間沒有任何關(guān)系卻類似的代碼組合在一起。
封裝經(jīng)常修改的代碼
Encapsulate What Changes
在軟件領(lǐng)域永遠(yuǎn)不變的是“變化”，所以把您認(rèn)為或懷疑將來要被修改的代碼封裝起來。這種面向?qū)ο笤O(shè)計(jì)模式的優(yōu)點(diǎn)是：易于測試和維護(hù)恰當(dāng)封裝的代碼。如果您在用Java編程，那么請(qǐng)遵守以下原則：變量和方法的訪問權(quán)限默認(rèn)設(shè)置為私有，并且逐步放開它們的訪問權(quán)限，例如從“private”到“protected ”、“not public”。Java中的一些設(shè)計(jì)模式使用了封裝，工廠設(shè)計(jì)模式就是一個(gè)例子，它封裝了創(chuàng)建對(duì)象的代碼而且提供了以下靈活性：后續(xù)生成新對(duì)象不影響現(xiàn)有的代碼。
打開/關(guān)閉設(shè)計(jì)原則
OpenClosed Design Principle
類、方法/函數(shù)應(yīng)當(dāng)是對(duì)擴(kuò)展(新功能)開放，對(duì)修改閉合。這是另外一個(gè)優(yōu)雅的SOLID 設(shè)計(jì)原則，以防止有人修改通過測試的代碼。理想情況下假如您添加了新功能，那么您的代碼要經(jīng)過測試，這就是打開/關(guān)閉設(shè)計(jì)原則的目標(biāo)。順便說一句，SOLID中的字母“O”指的是打開/關(guān)閉設(shè)計(jì)原則。
單一職責(zé)原則
Single Responsibility Principle(SRP)
單一職責(zé)原則是另外一個(gè)SOLID設(shè)計(jì)原則，SOLID中的字母“S”指的就是它。按照SRP，一個(gè)類修改的原因應(yīng)當(dāng)有且只有一個(gè)，或者一個(gè)類應(yīng)當(dāng)總是實(shí)現(xiàn)單一功能。如果您在Java中的一個(gè)類實(shí)現(xiàn)了多個(gè)功能，那么這些功能之間便產(chǎn)生了耦合關(guān)系;如果您修改其中的一個(gè)功能，您有可能就打破了這種耦合關(guān)系，那么就要進(jìn)行另一輪測試以避免產(chǎn)生新的問題。
依賴注入/反轉(zhuǎn)原則
Dependency Injection or Inversion principle
不要問框架的依賴注入功能將會(huì)給你帶來什么益處，依賴注入功能在spring框架里已經(jīng)很好的得到了實(shí)現(xiàn)，這一設(shè)計(jì)原則的優(yōu)雅之處在于：DI框架注入的任何一個(gè)類都易于用模擬對(duì)象進(jìn)行測試，并且更易于維護(hù)，因?yàn)閯?chuàng)建對(duì)象的代碼在框架里是集中的而且和客戶端代碼是隔離的。有多種方法可以實(shí)現(xiàn)依賴注入，例如使用字節(jié)碼工具，其中一些AOP(面向切面編程)框架如切入點(diǎn)表達(dá)式或者spring里使用的代理。想對(duì)這種SOLID設(shè)計(jì)原則了解更多，請(qǐng)看IOC 和 DI設(shè)計(jì)模式中的例子。 SOLID中的字母“D”指的就是這種設(shè)計(jì)原則。
優(yōu)先使用組合而非繼承
Favor Composition over Inheritance
如果可以的話，要優(yōu)先使用組合而非繼承。你們中的一些人可能為此爭論，但我發(fā)現(xiàn)組合比繼承更有靈活性。組合允許在運(yùn)行時(shí)通過設(shè)置屬性修改一個(gè)類的行為，通過使用多態(tài)即以接口的形式實(shí)現(xiàn)類之間的組合關(guān)系，并且為修改組合關(guān)系提供了靈活性。甚至 Effective Java也建議優(yōu)先使用組合而非繼承。
里氏替換原則
Liskov Substitution Principle LSP
根據(jù)里氏替換原則，父類出現(xiàn)的地方可以用子類來替換，例如父類的方法或函數(shù)被子類對(duì)象替換應(yīng)該沒有任何問題。LSP和單一職責(zé)原則、接口隔離原則密切相關(guān)。如果一個(gè)父類的功能比其子類還要多，那么它可能不支持這一功能，而且也違反了LSP設(shè)計(jì)原則。為了遵循 LSP SOLID設(shè)計(jì)原則，派生類或子類(相對(duì)父類比較)必須增強(qiáng)功能，而非減少。SOLID中的字母“L”指的就是 LSP設(shè)計(jì)原則。
接口隔離原則
接口隔離原則指，如果不需要一個(gè)接口的功能，那么就不要實(shí)現(xiàn)此接口。這大多在以下情況發(fā)生：一個(gè)接口包含多種功能，而實(shí)現(xiàn)類只需要其中一種功能。接口設(shè)計(jì)是一種棘手的工作，因?yàn)橐坏┌l(fā)布了接口，您就不能修改它否則會(huì)影響實(shí)現(xiàn)該接口的類。在Java中這種設(shè)計(jì)原則的另一個(gè)好處是：接口有一個(gè)特點(diǎn)，任何類使用它之前都要實(shí)現(xiàn)該接口所有的方法，所以使用功能單一的接口意味著實(shí)現(xiàn)更少的方法。
編程以接口(而非實(shí)現(xiàn)對(duì)象)為中心
編程總是以接口(而非實(shí)現(xiàn)對(duì)象)為中心，這會(huì)使代碼的結(jié)構(gòu)靈活，而且任何一個(gè)新的接口實(shí)現(xiàn)對(duì)象都能兼容現(xiàn)有代碼結(jié)構(gòu)。所以在Java中，變量、方法返回值、方法參數(shù)的數(shù)據(jù)類型請(qǐng)使用接口。這是許多Java程序員的建議， Effective Java 以及 head first design pattern 等書也這樣建議。
代理原則
不要期望一個(gè)類完成所有的功能，可以適當(dāng)?shù)匕岩恍┕δ芙唤o代理類實(shí)現(xiàn)。代理原則的典范是：Java 中的equals() 和 hashCode() 方法。為了比較兩個(gè)對(duì)象的內(nèi)容是否相同，我們讓用于比較的類本身完成對(duì)比工作而非它們的調(diào)用方。這種設(shè)計(jì)原則的好處是：沒有重復(fù)編碼而且很容易修改類的行為。
總結(jié)
以上所有面向?qū)ο蟮脑O(shè)計(jì)原則可以幫助您寫出靈活、優(yōu)雅的代碼：具有高內(nèi)聚低耦合的代碼結(jié)構(gòu)。理論只是第一步，更重要的是我們要習(xí)得一種能力去發(fā)現(xiàn)什么時(shí)候使用這些設(shè)計(jì)原則。去發(fā)現(xiàn)我們是否違反了什么設(shè)計(jì)原則和影響了代碼的靈活性，但是世界上沒有什么是完美的，我們解決問題時(shí)不能總?cè)ナ褂迷O(shè)計(jì)模式和設(shè)計(jì)原則，它們大多用于有較長維護(hù)周期的大型企業(yè)項(xiàng)目。
【java程序10個(gè)面向?qū)ο笤O(shè)計(jì)原則】相關(guān)文章：
Java面向?qū)ο笤O(shè)計(jì)的經(jīng)驗(yàn)原則10-02
java面向?qū)ο缶幊填}庫及答案07-28
PHP程序面向?qū)ο蠓治鲈O(shè)計(jì)的經(jīng)驗(yàn)小結(jié)10-06
2017年計(jì)算機(jī)java面向?qū)ο笾R(shí)點(diǎn)06-30