盡管學(xué)習(xí)任何設(shè)計(jì)原則或模式的最佳方法是通過一個(gè)真實(shí)的示例并了解違反該設(shè)計(jì)原則的后果，但本文的主題是為沒有接觸過它的 Java 程序員介紹面向?qū)ο蟮脑O(shè)計(jì)原則或者在學(xué)習(xí)階段。

1. DRY

我們的第一個(gè)面向?qū)ο蟮脑O(shè)計(jì)原則是 DRY，顧名思義，DRY(不要重復(fù)自己)的意思是不要編寫重復(fù)的代碼，而是使用Abstraction將常見的東西抽象在一個(gè)地方。如果您在兩個(gè)以上的地方有一段代碼，請(qǐng)考慮將其設(shè)為單獨(dú)的方法，或者如果您多次使用硬編碼值，請(qǐng)將它們?cè)O(shè)為 public final constant。

這種面向?qū)ο笤O(shè)計(jì)原則的好處在于維護(hù)。重要的是不要濫用它，重復(fù)不是為了代碼，而是為了功能。這意味著如果您使用標(biāo)準(zhǔn)代碼來驗(yàn)證OrderID和SSN，這并不意味著它們是相同的，或者它們將來會(huì)保持相同。

通過為兩個(gè)不同的功能或事物使用標(biāo)準(zhǔn)代碼，您可以將它們永遠(yuǎn)緊密地結(jié)合在一起，并且當(dāng)您的 OrderId 更改其格式時(shí)，您的 SSN 驗(yàn)證代碼將中斷。

2. 封裝變化

軟件領(lǐng)域只有一件事是不變的，那就是“改變”，所以封裝你期望或懷疑在未來改變的代碼。這種 OOP 設(shè)計(jì)原則的好處是易于測(cè)試和維護(hù)適當(dāng)?shù)姆庋b代碼。

如果你是在 Java 中編碼，那么遵循將變量和方法默認(rèn)設(shè)為私有并逐步增加訪問權(quán)限的原則，例如從私有到受保護(hù)而不是公開。

Java中的一些設(shè)計(jì)模式使用了封裝，工廠設(shè)計(jì)模式 是封裝的一個(gè)示例，它封裝了對(duì)象創(chuàng)建代碼，并為以后引入新產(chǎn)品提供了靈活性，而不會(huì)影響現(xiàn)有代碼。

順便說一句，如果您有興趣了解有關(guān) Java 和面向?qū)ο缶幊?/span>中的設(shè)計(jì)模式的更多信息，那么您必須查看此 設(shè)計(jì)模式庫(kù) 課程 Pluralsight。它是關(guān)于如何在現(xiàn)實(shí)世界中使用它們的設(shè)計(jì)模式和建議的最佳集合之一。

3. 開放封閉設(shè)計(jì)原則

類、方法或函數(shù)應(yīng)該對(duì)擴(kuò)展開放(新功能)，對(duì)修改關(guān)閉。這是另一個(gè)漂亮的 SOLID 設(shè)計(jì)原則，它可以防止有人更改已經(jīng)嘗試和測(cè)試過的代碼。

理想情況下，如果您只是添加新功能，那么您的代碼應(yīng)該經(jīng)過測(cè)試，這就是 開放封閉設(shè)計(jì)原則的目標(biāo)。順便說一句，開閉原則是 SOLID 首字母縮寫詞中的“O”。

4.單一職責(zé)原則(SRP)

Single Responsibility Principle 是另一個(gè) SOLID 設(shè)計(jì)原則，在 SOLID 首字母縮寫詞上代表“S”。根據(jù) SRP，更改類的原因不應(yīng)該超過一個(gè)，或者類應(yīng)該始終處理單一功能。

如果你在 Java 中的一個(gè) Class 中放置多個(gè)功能，它會(huì)引入 兩個(gè)功能之間的耦合 ，即使你更改一個(gè)特性，也有可能破壞耦合功能，這需要另一輪測(cè)試以避免對(duì)生產(chǎn)造成任何意外環(huán)境。

5.依賴注入或倒置原理

不要要求依賴;它將由框架提供給您。這在Spring 框架中已經(jīng)很好地實(shí)現(xiàn)了 ，這種設(shè)計(jì)原則的美妙之處在于，任何由 DI 框架注入的類都易于使用模擬對(duì)象進(jìn)行測(cè)試，并且維護(hù)起來更舒適，因?yàn)閷?duì)象創(chuàng)建代碼集中在框架中。并且客戶端代碼沒有亂七八糟。

有多種實(shí)現(xiàn)依賴注入的方法，例如使用字節(jié)碼檢測(cè)，一些 AOP(面向方面??的編程)框架，如 AspectJ，或者使用代理，就像在 Spring 中使用的那樣。

6. 偏好組合勝于繼承

如果可能的話，總是傾向于組合而不是繼承。你們中的一些人可能會(huì)爭(zhēng)論這一點(diǎn)，但我發(fā)現(xiàn) Composition 比Inheritance靈活得多。

組合允許通過在運(yùn)行時(shí)設(shè)置屬性來改變類在運(yùn)行時(shí)的行為，并且通過使用接口組合一個(gè)類，我們使用多態(tài)性，它提供了隨時(shí)替換為更好實(shí)現(xiàn)的靈活性。

7. 里氏替換原則(LSP)

根據(jù)Liskov 替換原則，子類型必須可替換父類型，即使用超類類型的方法或函數(shù)必須能夠與子類的對(duì)象毫無問題地工作” 。LSP 與單一職責(zé)原則和接口隔離原則

密切相關(guān). 如果一個(gè)類有更多的功能，那么子類可能不支持某些功能并且確實(shí)違反了 LSP。

8.接口隔離原則(ISP)

接口隔離原則指出，如果客戶端不使用接口，則不應(yīng)實(shí)現(xiàn)該接口。這主要發(fā)生在一個(gè)接口包含多個(gè)功能時(shí)，而客戶端只需要一個(gè)功能而不需要其他功能。

界面設(shè)計(jì)是一項(xiàng)棘手的工作，因?yàn)橐坏┌l(fā)布了界面，就無法在不破壞所有實(shí)現(xiàn)的情況下對(duì)其進(jìn)行更改。

Java中這種設(shè)計(jì)原則的另一個(gè)好處是，接口的缺點(diǎn)是在任何類可以使用它之前實(shí)現(xiàn)所有方法，因此具有單一功能意味著實(shí)現(xiàn)的方法更少。

9. 接口編程而不是實(shí)現(xiàn)

始終為接口而不是應(yīng)用程序編程;這將導(dǎo)致靈活的代碼可以與接口的任何新實(shí)現(xiàn)一起使用。

因此，在Java變量、方法的返回類型或方法的參數(shù)類型使用接口類型。

10. 委托原則

不要自己做所有事情，將其委托給相應(yīng)的班級(jí)。委托設(shè)計(jì)原則的經(jīng)典示例是Java 中的 equals() 和 hashCode() 方法。為了比較兩個(gè)對(duì)象是否相等，我們要求類本身進(jìn)行比較，而不是讓Client類進(jìn)行檢查。

這種設(shè)計(jì)原則的主要好處是沒有重復(fù)代碼并且很容易修改行為。事件委托是這個(gè)原則的另一個(gè)例子，其中一個(gè)事件被委托給處理程序進(jìn)行處理。