動力節(jié)點(diǎn)小編要告訴大家，在 Java 中，設(shè)計原則是在設(shè)計制作中用作規(guī)則的一組建議。在 Java 中，設(shè)計原則類似于Java設(shè)計模式的概念。設(shè)計原則和設(shè)計模式之間的唯一區(qū)別是設(shè)計原則更加概括和抽象。設(shè)計模式包含更多實(shí)用的建議和具體內(nèi)容。設(shè)計模式與整個類問題有關(guān)，而不僅僅是通用的編碼實(shí)踐。

有一些最重要的設(shè)計原則如下：

堅(jiān)實(shí)的原則

建議零售價

語言服務(wù)提供商

互聯(lián)網(wǎng)服務(wù)提供商

開閉原則

蘸

其他原則

干燥原則

親吻原則

組合優(yōu)于繼承原則

讓我們一一了解所有原理：

干燥原則

DRY原則代表Don't Repeat Yourself原則。它是所有編程語言的共同原則之一。DRY 原則說：

在一個系統(tǒng)中，每條邏輯都應(yīng)該有一個明確的表示。

我們以 DRY 原理為例

公共類 動物{   
    公共無效 吃（）{   
        System.out.println( "吃東西" );  
    }  
}    
公共類 狗 擴(kuò)展 動物{   
    公共無效 woof() {   
        System.out.println( "狗汪汪！" );  
    }  
}  
公共類 貓 擴(kuò)展 動物{   
    公共無效 喵（）{   
        System.out.println( "貓喵！" );  
    }  
}  

狗和貓的說話方式不同，但它們需要吃東西。兩者的共同功能是吃食物，所以我們可以把這個共同的功能放到父類，即Animals，然后我們可以在子類，即Dog 和Cat 中擴(kuò)展該父類。

現(xiàn)在，每個類都可以專注于自己獨(dú)特的邏輯，因此無需在兩個類中實(shí)現(xiàn)相同的功能。

狗 obj1 =  new  Dog();  
obj1.eatFood();  
obj1.woof();  
貓 obj2 = 新 貓（）；  
obj2.eatFood();  
obj2.meow();  

編譯運(yùn)行上述代碼后，我們會看到如下輸出：

輸出：

吃東西
貓喵！
吃東西
狗汪汪！

違反 DRY 原則

違反 DRY 原則的行為稱為 WET 解決方案。WET 是以下事物的縮寫：

把所有東西都寫兩次

我們喜歡打字

每次都寫

浪費(fèi)每個人的兩倍。

這些違規(guī)行為并不總是壞事，因?yàn)橛袝r建議重復(fù)以減少代碼之間的相互依賴、更具可讀性、本質(zhì)上不同的類等。

建議零售價

SRP 是另一個設(shè)計原則，代表單一責(zé)任原則。SRP 原則說，在一個類中，永遠(yuǎn)不應(yīng)該有兩種功能。它還解釋為：

班級應(yīng)該只有一個且只有一個需要更改的理由。當(dāng)有多個職責(zé)時，在同一點(diǎn)更改該類的理由不止一個。因此，在同一個類中不應(yīng)該有多個單獨(dú)的功能可能會受到影響。

SRP 原則幫助我們從類繼承而不繼承或?qū)崿F(xiàn)我們的類不需要的方法。

處理錯誤。

在不混淆共同依賴關(guān)系的情況下實(shí)施更改。

語言服務(wù)提供商

LSP 是另一種設(shè)計原則，代表Liskov Substitution Principle。LSP聲明派生類應(yīng)該能夠在不更改我們的代碼的情況下替換基類。

LSP 與 SRP 和 ISP 密切相關(guān)，因此，違反 SRP 或 ISP 都可能違反(或成為)LSP。違反 LSP 的原因是，如果一個類執(zhí)行多個功能，擴(kuò)展它的子類不太可能有意義地實(shí)現(xiàn)這兩個或多個功能。

蘸

另一個最重要的設(shè)計原則是DIP，即依賴倒置原則。該原則表明低層和高層是解耦的，因此低層模塊的更改不需要對高層模塊進(jìn)行返工。

高層和低層模塊不應(yīng)相互依賴。它們應(yīng)該依賴于抽象，例如接口。依賴倒置原則還指出，細(xì)節(jié)應(yīng)該依賴于抽象，而不是抽象應(yīng)該依賴于細(xì)節(jié)。

親吻原則

這是另一個設(shè)計原則，代表保持簡單和愚蠢的原則。這個原則只是提醒我們保持我們的代碼對人類可讀和簡單。如果該方法處理了多個用例，我們需要將它們拆分為更小的函數(shù)。

KISS 原則指出，在大多數(shù)情況下，堆棧調(diào)用不應(yīng)該嚴(yán)重影響我們程序的性能，直到效率不是非常重要。

另一方面，冗長且不可讀的方法對于人類程序員來說將很難維護(hù)和發(fā)現(xiàn)錯誤。違反 DRY 原則可以由我們自己完成，因?yàn)槿绻覀冇幸粋€執(zhí)行多個任務(wù)的方法，我們不能調(diào)用該方法來執(zhí)行其中一個任務(wù)。因此，我們將為此創(chuàng)建另一種方法。

互聯(lián)網(wǎng)服務(wù)提供商

ISP是另一種設(shè)計原則，代表接口隔離原則。該原則指出，客戶端不應(yīng)被限制為依賴于未完全使用的接口。這意味著接口應(yīng)該具有確保功能所需的最少方法集，并且僅限于一個功能。

例如，如果我們創(chuàng)建一個 Burger 接口，我們不需要實(shí)現(xiàn) addCheese() 方法，因?yàn)槟汤也⒎沁m用于所有 Burger 類型。

讓我們假設(shè)所有的漢堡都需要烘烤并有醬汁，并通過以下方式定義該漢堡接口：

公共接口 漢堡{   
    無效 添加醬（）；  
    無效 的烤漢堡（）；  
}  

現(xiàn)在，讓我們在 VegetarianBurger 和 CheeseBurger 類中實(shí)現(xiàn) Burger 接口。

公共類 VegetarianBurger 實(shí)現(xiàn) Burger {   
公共無效 addTomatoAndCabbage() {   
        System.out.println( "添加番茄和卷心菜" );  
    }  
        @覆蓋  
        公共無效 添加醬（）{   
        System.out.println( "在素食漢堡中加醬" );  
    }  
@覆蓋  
        公共無效 烘烤（）{   
        System.out.println( "烘焙素食漢堡" );  
    }  
}  
公共類 CheeseBurger 實(shí)現(xiàn) Burger {   
公共無效 添加奶酪（）{   
        System.out.println( "在漢堡中添加奶酪" );  
    }  
@覆蓋  
公共無效 添加醬（）{   
        System.out.println( "在芝士漢堡中加醬" );  
    }  
@覆蓋  
        公共無效 烘烤（）{   
        System.out.println( "烤芝士漢堡" );  
    }  
}  

VagitarianBurger 有 Cabbage 和 Tomato，而 CheeseBurger 有奶酪，但需要烘烤和界面中定義的醬汁。如果 addCheese() 和 addTomatoandCabbage() 方法位于 Burger 接口中，則這兩個類都必須實(shí)現(xiàn)它們，即使它們不需要兩者。

開/關(guān)原則

開放/封閉原則是另一個重要的設(shè)計原則，屬于SOLID原則的范疇。該原則表明方法和對象或類應(yīng)該對修改關(guān)閉但對修改開放。簡而言之，這個原則說我們應(yīng)該在考慮未來可能的更新的情況下實(shí)現(xiàn)我們的模塊和類。通過這樣做，我們的模塊和類將具有通用設(shè)計，并且為了擴(kuò)展它們的行為，我們不需要更改類本身。

我們可以創(chuàng)建新的字段或方法，但是我們不需要修改舊代碼，刪除已經(jīng)創(chuàng)建的字段，并重寫創(chuàng)建的方法。

Open/Close 原則主要用于防止回歸并確保向后兼容。

組合優(yōu)于繼承原則

組合優(yōu)于繼承原則是Java中另一個重要的設(shè)計原則。這個原則幫助我們在 Java 中實(shí)現(xiàn)靈活和可維護(hù)的代碼。該原則表明我們應(yīng)該實(shí)現(xiàn)Java接口而不是擴(kuò)展類。我們實(shí)現(xiàn)繼承時該類需要實(shí)現(xiàn)所有功能子類可以用來代替我們的父類。同理，我們在使用 Composition 時該類需要實(shí)現(xiàn)一些特定的功能。