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

有一些最重要的設計原則如下：

堅實的原則

建議零售價

語言服務提供商

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

開閉原則

蘸

其他原則

干燥原則

親吻原則

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

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

干燥原則

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

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

我們以 DRY 原理為例

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

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

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

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

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

輸出：

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

違反 DRY 原則

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

把所有東西都寫兩次

我們喜歡打字

每次都寫

浪費每個人的兩倍。

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

建議零售價

SRP 是另一個設計原則，代表單一責任原則。SRP 原則說，在一個類中，永遠不應該有兩種功能。它還解釋為：

班級應該只有一個且只有一個需要更改的理由。當有多個職責時，在同一點更改該類的理由不止一個。因此，在同一個類中不應該有多個單獨的功能可能會受到影響。

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

處理錯誤。

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

語言服務提供商

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

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

蘸

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

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

親吻原則

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

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

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

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

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

例如，如果我們創(chuàng)建一個 Burger 接口，我們不需要實現(xiàn) addCheese() 方法，因為奶酪并非適用于所有 Burger 類型。

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

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

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

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

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

開/關(guān)原則

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

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

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

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

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