SOLID 原则对于任何旨在构建健壮、可维护系统的开发人员来说都是基础。这些原则不仅提高了代码质量，而且促进了项目的团队合作和可扩展性。让我们通过 Java 中的实际示例深入研究这些原则，重点介绍常见违规行为和推荐做法。
1.单一职责原则（SRP）
原则：一个类应该只有一个改变的理由。
违反建议零售价：
公开课用户{
私有字符串名称；
私人字符串电子邮件；
公共无效保存用户（）{
// 将用户保存到数据库的逻辑
}
公共无效发送电子邮件（）{
// 向用户发送电子邮件的逻辑
}
}
在此示例中，User 类具有多个职责：管理用户数据和发送电子邮件。
应用建议零售价：
公开课用户{
私有字符串名称；
私人字符串电子邮件；
}
公共类用户存储库{
公共无效保存用户（用户用户）{
// 将用户保存到数据库的逻辑
}
}
公共类电子邮件服务{
公共无效sendEmail（用户用户）{
// 向用户发送电子邮件的逻辑
}
}
在这里，我们将职责划分为不同的类别，遵循 SRP。
立即学习“Java免费学习笔记（深入）”；
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 原则不仅是良好的理论实践，而且是保持软件灵活性、可持续性和可理解性的行之有效的策略。我希望这些示例有助于说明如何在自己的软件项目中实现这些原则。
