掌握 Java 的 SOLID 原则：实用指南

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《掌握 Java 的 SOLID 原则：实用指南》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

SOLID 原则对于任何旨在构建健壮、可维护系统的开发人员来说都是基础。这些原则不仅提高了代码质量，而且促进了项目的团队合作和可扩展性。让我们通过 Java 中的实际示例深入研究这些原则，重点介绍常见违规行为和推荐做法。

1.单一职责原则（SRP）

原则：一个类应该只有一个改变的理由。

违反建议零售价：

公开课用户{
    私有字符串名称；
    私人字符串电子邮件；

    公共无效保存用户（）{
        // 将用户保存到数据库的逻辑
    }

    公共无效发送电子邮件（）{
        // 向用户发送电子邮件的逻辑
    }
}

在此示例中，User 类具有多个职责：管理用户数据和发送电子邮件。

应用建议零售价：

公开课用户{
    私有字符串名称；
    私人字符串电子邮件；
}

公共类用户存储库{
    公共无效保存用户（用户用户）{
        // 将用户保存到数据库的逻辑
    }
}

公共类电子邮件服务{
    公共无效sendEmail（用户用户）{
        // 向用户发送电子邮件的逻辑
    }
}

在这里，我们将职责划分为不同的类别，遵循 SRP。

2. 开闭原理（OCP）

原则：类应该对扩展开放，对修改关闭。

违反 OCP：

公共课折扣计算器 {
    公共双计算折扣（字符串类型）{
        if (type.equals("NORMAL")) {
            返回0.05；
        } else if (type.equals("SPECIAL")) {
            返回0.1；
        }
        返回0；
    }
}

在此示例中，任何新的折扣类型都需要修改 DiscountCalculator 类。

应用 OCP：

公共接口折扣 {
    双计算折扣（）；
}

公共类 NormalDiscount 实现 Discount {
    公共双计算折扣（）{
        返回0.05；
    }
}

公共类 SpecialDiscount 实现 Discount {
    公共双计算折扣（）{
        返回0.1；
    }
}

公共类折扣计算器{
    公共双计算折扣（折扣折扣）{
        返回折扣.calculateDiscount();
    }
}

在这种情况下，DiscountCalculator 关闭以进行修改，但可以通过实施新的折扣类型进行扩展。

3.里氏替换原理（LSP）

原则：子类应该可以被基类替换，而不影响程序的正确性。

违反LSP：

公开课鸟{
    公共无效飞行（）{
        // 飞行实现
    }
}

公共类企鹅扩展了鸟{
    @覆盖
    公共无效飞行（）{
        throw new UnsupportedOperationException("企鹅不会飞");
    }
}

这里，Penguin类不能代替Bird而不影响程序的正确性。

应用 LSP：

公共抽象类 Bird {
}

公共类 FlyingBird 扩展 Bird {
    公共无效飞行（）{
        // 飞行实现
    }
}

公共类企鹅扩展了鸟{
}

现在，FlyingBird 和 Penguin 分开了，尊重 Bird 被其子类取代的能力。

4. 接口隔离原则（ISP）

原则：不应该强迫客户端依赖他们不使用的接口。

违反ISP：

公共界面动物{
    无效步行（）；
    无效飞行（）；
    无效游泳（）；
}

公共类 Dog 实现 Animal {
    公共无效步行（）{
        // 步行实现
    }

    公共无效飞行（）{
        抛出新的 UnsupportedOperationException();
    }

    公共无效游泳（）{
        // 狗会游泳
    }
}

这里，Dog被迫实现fly，这是不相关的。

应用ISP：

公共界面步行{
    无效步行（）；
}

公共接口可飞{
    无效飞行（）；
}

公共接口可游泳{
    无效游泳（）；
}

公共类 Dog 实现 Walkable、Swimmable {
    公共无效步行（）{
        // 步行实现
    }

    公共无效游泳（）{
        // 游泳实现
    }
}

现在，Dog 只实现与其动作相关的接口。

5. 依赖倒置原则（DIP）

原则：高层模块不应该依赖于低层模块。两者都应该依赖于抽象。

违反 DIP：

公共课灯泡{
    公共无效打开（）{
        // 打开灯泡
    }
}

公共类电力开关{
    私有 LightBulb lightBulb = new LightBulb();

    公共无效按下（）{
        灯泡.turnOn();
    }
}

ElectricPowerSwitch 直接依赖于 LightBulb，一个低级模块。

应用 DIP：

公共界面可切换{
    无效打开（）；
}

公共类 LightBulb 实现可切换 {
    公共无效打开（）{
        // 打开灯泡
    }
}

公共类电力开关{
    私人可切换客户端；

    公共 ElectricPowerSwitch（可切换客户端）{
        this.client = 客户端；
    }

    公共无效按下（）{
        客户端.turnOn();
    }
}

现在，ElectricPowerSwitch 依赖于一个抽象（Switchable），这使得设计更加灵活和可持续。

结论
在 Java 中应用 SOLID 原则不仅是良好的理论实践，而且是保持软件灵活性、可持续性和可理解性的行之有效的策略。我希望这些示例有助于说明如何在自己的软件项目中实现这些原则。

今天关于《掌握 Java 的 SOLID 原则：实用指南》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！