面向?qū)ο笤O(shè)計原則是OOPS(Object-Oriented Programming System，面向?qū)ο蟮某绦蛟O(shè)計系統(tǒng))編程的核心，但大多數(shù)Java程序員追逐像Singleton、Decorator、Observer這樣的設(shè)計模式，而不重視面向?qū)ο蟮姆治龊驮O(shè)計。甚至還有經(jīng)驗豐富的Java程序員沒有聽說過OOPS和SOLID設(shè)計原則，他們根本不知道設(shè)計原則的好處，也不知道如何依照這些原則來進(jìn)行編程。

　　眾所周知，Java編程最基本的原則就是要追求高內(nèi)聚和低耦合的解決方案和代碼模塊設(shè)計。查看Apache和Sun的開放源代碼能幫助你發(fā)現(xiàn)其他Java設(shè)計原則在這些代碼中的實際運用。Java Development Kit則遵循以下模式：BorderFactory類中的工廠模式、Runtime類中的單件模式。你可以通過Joshua Bloch的《Effective Java》一書來了解更多信息。我個人偏向的另一種面向?qū)ο蟮脑O(shè)計模式是Kathy Sierra的Head First Design Pattern以及Head First Object Oriented Analysis and Design.

　　雖然實際案例是學(xué)習(xí)設(shè)計原則或模式的最佳途徑，但通過本文的介紹，沒有接觸過這些原則或還在學(xué)習(xí)階段的Java程序員也能夠了解這10個面向?qū)ο蟮脑O(shè)計原則。其實每條原則都需要大量的篇幅才能講清楚，但我會盡力做到言簡意賅。

　　原則1：DRY(Don't repeat yourself)

　　即不要寫重復(fù)的代碼，而是用“abstraction”類來抽象公有的東西。如果你需要多次用到一個硬編碼值，那么可以設(shè)為公共常量;如果你要在兩個以上的地方使用一個代碼塊，那么可以將它設(shè)為一個獨立的方法。SOLID設(shè)計原則的優(yōu)點是易于維護(hù)，但要注意，不要濫用，duplicate 不是針對代碼，而是針對功能。這意味著，即使用公共代碼來驗證OrderID和SSN，二者也不會是相同的。使用公共代碼來實現(xiàn)兩個不同的功能，其實就是近似地把這兩個功能永遠(yuǎn)捆綁到了一起，如果OrderID改變了其格式，SSN驗證代碼也會中斷。因此要慎用這種組合，不要隨意捆綁類似但不相關(guān)的功能。

　　原則2：封裝變化

　　在軟件領(lǐng)域中唯一不變的就是“Change”，因此封裝你認(rèn)為或猜測未來將發(fā)生變化的代碼。OOPS設(shè)計模式的優(yōu)點在于易于測試和維護(hù)封裝的代碼。如果你使用Java編碼，可以默認(rèn)私有化變量和方法，并逐步增加訪問權(quán)限，比如從private到protected和not public.有幾種Java設(shè)計模式也使用封裝，比如Factory設(shè)計模式是封裝“對象創(chuàng)建”，其靈活性使得之后引進(jìn)新代碼不會對現(xiàn)有的代碼造成影響。

　　原則3：開閉原則

　　即對擴(kuò)展開放，對修改關(guān)閉。這是另一種非常棒的設(shè)計原則，可以防止其他人更改已經(jīng)測試好的代碼。理論上，可以在不修改原有的模塊的基礎(chǔ)上，擴(kuò)展功能。這也是開閉原則的宗旨。

　　原則4：單一職責(zé)原則

　　類被修改的幾率很大，因此應(yīng)該專注于單一的功能。如果你把多個功能放在同一個類中，功能之間就形成了關(guān)聯(lián)，改變其中一個功能，有可能中止另一個功能，這時就需要新一輪的測試來避免可能出現(xiàn)的問題。

　　原則5：依賴注入或倒置原則

　　這個設(shè)計原則的亮點在于任何被DI框架注入的類很容易用mock對象進(jìn)行測試和維護(hù)，因為對象創(chuàng)建代碼集中在框架中，客戶端代碼也不混亂。有很多方式可以實現(xiàn)依賴倒置，比如像AspectJ等的AOP(Aspect Oriented programming)框架使用的字節(jié)碼技術(shù)，或Spring框架使用的代理等。

　　原則6：優(yōu)先利用組合而非繼承

　　如果可能的話，優(yōu)先利用組合而不是繼承。一些人可能會質(zhì)疑，但我發(fā)現(xiàn)，組合比繼承靈活得多。組合允許在運行期間通過設(shè)置類的屬性來改變類的行為，也可以通過使用接口來組合一個類，它提供了更高的靈活性，并可以隨時實現(xiàn)。《Effective Java》也推薦此原則。

　　原則7：里氏代換原則(LSP)

　　根據(jù)該原則，子類必須能夠替換掉它們的基類，也就是說使用基類的方法或函數(shù)能夠順利地引用子類對象。LSP原則與單一職責(zé)原則和接口分離原則密切相關(guān)，如果一個類比子類具備更多功能，很有可能某些功能會失效，這就違反了LSP原則。為了遵循該設(shè)計原則，派生類或子類必須增強(qiáng)功能。

　　原則8：接口分離原則

　　采用多個與特定客戶類有關(guān)的接口比采用一個通用的涵蓋多個業(yè)務(wù)方法的接口要好。設(shè)計接口很棘手，因為一旦釋放接口，你就無法在不中斷執(zhí)行的情況下改變它。在Java中，該原則的另一個優(yōu)勢在于，在任何類使用接口之前，接口不利于實現(xiàn)所有的方法，所以單一的功能意味著更少的實現(xiàn)方法。

　　原則9：針對接口編程，而不是針對實現(xiàn)編程

　　該原則可以使代碼更加靈活，以便可以在任何接口實現(xiàn)中使用。因此，在Java中最好使用變量接口類型、方法返回類型、方法參數(shù)類型等。《Effective Java》 和《head first design pattern》書中也有提到。

　　原則10：委托原則

　　該原則最典型的例子是Java中的equals() 和 hashCode() 方法。為了平等地比較兩個對象，我們用類本身而不是客戶端類來做比較。這個設(shè)計原則的好處是沒有重復(fù)的代碼，而且很容易對其進(jìn)行修改。

　　總之，希望這些面向?qū)ο蟮脑O(shè)計原則能幫助你寫出更靈活更好的代碼。理論是第一步，更重要的是需要開發(fā)者在實踐中去運用和體會。

轉(zhuǎn)載于:https://www.cnblogs.com/softwareofjava/p/7279320.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的Java程序员应该了解的10个设计原则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。