Java设计原则的详细介绍

极悦小编要告诉大家，在 Java 中，设计原则是在设计制作中用作规则的一组建议。在 Java 中，设计原则类似于Java设计模式的概念。设计原则和设计模式之间的唯一区别是设计原则更加概括和抽象。设计模式包含更多实用的建议和具体内容。设计模式与整个类问题有关，而不仅仅是通用的编码实践。

有一些最重要的设计原则如下：

坚实的原则

建议零售价

语言服务提供商

互联网服务提供商

开闭原则

蘸

其他原则

干燥原则

亲吻原则

组合优于继承原则

让我们一一了解所有原理：

干燥原则

DRY原则代表Don't Repeat Yourself原则。它是所有编程语言的共同原则之一。DRY 原则说：

在一个系统中，每条逻辑都应该有一个明确的表示。

我们以 DRY 原理为例

公共类 动物{   
    公共无效 吃（）{   
        System.out.println( "吃东西" );  
    }  
}    
公共类 狗 扩展 动物{   
    公共无效 woof() {   
        System.out.println( "狗汪汪！" );  
    }  
}  
公共类 猫 扩展 动物{   
    公共无效 喵（）{   
        System.out.println( "猫喵！" );  
    }  
}  

狗和猫的说话方式不同，但它们需要吃东西。两者的共同功能是吃食物，所以我们可以把这个共同的功能放到父类，即Animals，然后我们可以在子类，即Dog 和Cat 中扩展该父类。

现在，每个类都可以专注于自己独特的逻辑，因此无需在两个类中实现相同的功能。

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

编译运行上述代码后，我们会看到如下输出：

输出：

吃东西
猫喵！
吃东西
狗汪汪！

违反 DRY 原则

违反 DRY 原则的行为称为 WET 解决方案。WET 是以下事物的缩写：

把所有东西都写两次

我们喜欢打字

每次都写

浪费每个人的两倍。

这些违规行为并不总是坏事，因为有时建议重复以减少代码之间的相互依赖、更具可读性、本质上不同的类等。

建议零售价

SRP 是另一个设计原则，代表单一责任原则。SRP 原则说，在一个类中，永远不应该有两种功能。它还解释为：

班级应该只有一个且只有一个需要更改的理由。当有多个职责时，在同一点更改该类的理由不止一个。因此，在同一个类中不应该有多个单独的功能可能会受到影响。

SRP 原则帮助我们从类继承而不继承或实现我们的类不需要的方法。

处理错误。

在不混淆共同依赖关系的情况下实施更改。

语言服务提供商

LSP 是另一种设计原则，代表Liskov Substitution Principle。LSP声明派生类应该能够在不更改我们的代码的情况下替换基类。

LSP 与 SRP 和 ISP 密切相关，因此，违反 SRP 或 ISP 都可能违反(或成为)LSP。违反 LSP 的原因是，如果一个类执行多个功能，扩展它的子类不太可能有意义地实现这两个或多个功能。

蘸

另一个最重要的设计原则是DIP，即依赖倒置原则。该原则表明低层和高层是解耦的，因此低层模块的更改不需要对高层模块进行返工。

高层和低层模块不应相互依赖。它们应该依赖于抽象，例如接口。依赖倒置原则还指出，细节应该依赖于抽象，而不是抽象应该依赖于细节。

亲吻原则

这是另一个设计原则，代表保持简单和愚蠢的原则。这个原则只是提醒我们保持我们的代码对人类可读和简单。如果该方法处理了多个用例，我们需要将它们拆分为更小的函数。

KISS 原则指出，在大多数情况下，堆栈调用不应该严重影响我们程序的性能，直到效率不是非常重要。

另一方面，冗长且不可读的方法对于人类程序员来说将很难维护和发现错误。违反 DRY 原则可以由我们自己完成，因为如果我们有一个执行多个任务的方法，我们不能调用该方法来执行其中一个任务。因此，我们将为此创建另一种方法。

互联网服务提供商

ISP是另一种设计原则，代表接口隔离原则。该原则指出，客户端不应被限制为依赖于未完全使用的接口。这意味着接口应该具有确保功能所需的最少方法集，并且仅限于一个功能。

例如，如果我们创建一个 Burger 接口，我们不需要实现 addCheese() 方法，因为奶酪并非适用于所有 Burger 类型。

让我们假设所有的汉堡都需要烘烤并有酱汁，并通过以下方式定义该汉堡接口：

公共接口 汉堡{   
    无效 添加酱（）；  
    无效 的烤汉堡（）；  
}  

现在，让我们在 VegetarianBurger 和 CheeseBurger 类中实现 Burger 接口。

公共类 VegetarianBurger 实现 Burger {   
公共无效 addTomatoAndCabbage() {   
        System.out.println( "添加番茄和卷心菜" );  
    }  
        @覆盖  
        公共无效 添加酱（）{   
        System.out.println( "在素食汉堡中加酱" );  
    }  
@覆盖  
        公共无效 烘烤（）{   
        System.out.println( "烘焙素食汉堡" );  
    }  
}  
公共类 CheeseBurger 实现 Burger {   
公共无效 添加奶酪（）{   
        System.out.println( "在汉堡中添加奶酪" );  
    }  
@覆盖  
公共无效 添加酱（）{   
        System.out.println( "在芝士汉堡中加酱" );  
    }  
@覆盖  
        公共无效 烘烤（）{   
        System.out.println( "烤芝士汉堡" );  
    }  
}  

VagitarianBurger 有 Cabbage 和 Tomato，而 CheeseBurger 有奶酪，但需要烘烤和界面中定义的酱汁。如果 addCheese() 和 addTomatoandCabbage() 方法位于 Burger 接口中，则这两个类都必须实现它们，即使它们不需要两者。

开/关原则

开放/封闭原则是另一个重要的设计原则，属于SOLID原则的范畴。该原则表明方法和对象或类应该对修改关闭但对修改开放。简而言之，这个原则说我们应该在考虑未来可能的更新的情况下实现我们的模块和类。通过这样做，我们的模块和类将具有通用设计，并且为了扩展它们的行为，我们不需要更改类本身。

我们可以创建新的字段或方法，但是我们不需要修改旧代码，删除已经创建的字段，并重写创建的方法。

Open/Close 原则主要用于防止回归并确保向后兼容。

组合优于继承原则

组合优于继承原则是Java中另一个重要的设计原则。这个原则帮助我们在 Java 中实现灵活和可维护的代码。该原则表明我们应该实现Java接口而不是扩展类。我们实现继承时该类需要实现所有功能子类可以用来代替我们的父类。同理，我们在使用 Composition 时该类需要实现一些特定的功能。