【23种设计模式】开闭原则
个人主页：金鳞踏雨
个人简介：大家好，我是金鳞，一个初出茅庐的Java小白
目前状况：22届普通本科毕业生，几经波折了，现在任职于一家国内大型知名日化公司，从事Java开发工作
我的博客：这里是CSDN，是我学习技术，总结知识的地方。希望和各位大佬交流，共同进步 ~
本文来自抖音《IT楠老师》设计模式课程，下面是本人结合原课件的一些学习心得。
一、原理概述
开闭原则（Open Closed Principle），简写为 OCP。软件实体（模块、类、方法等）应该"对扩展开放、对修改关闭"。一个很明显的例子就是——策略设计模式
对扩展开放、对修改关闭。
当我们需要添加一个新的功能时，应该在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。
开闭原则并不是不让我们修改代码，而是让我们尽量避免"大修大改"，设计模式是方法，是套路，而不是"枷锁"！！！
案例分析
问题代码
以下是一个常见的生产环境中的例子，我们将展示一个简化的电商平台的订单折扣策略。下述代码是否可以符合开闭原则的定义呢？
class Order {private double totalAmount;public Order(double totalAmount) {this.totalAmount = totalAmount;}// 计算折扣后的金额public double getDiscountedAmount(String discountType) {double discountedAmount = totalAmount;if (discountType.equals("FESTIVAL")) {discountedAmount = totalAmount * 0.9; // 节日折扣，9折} else if (discountType.equals("SEASONAL")) {discountedAmount = totalAmount * 0.8; // 季节折扣，8折}return discountedAmount;}
}上述代码中，Order 类包含一个计算折扣金额的方法，它根据不同的折扣类型应用折扣。当我们需要添加新的折扣类型时，就不得不需要修改 getDiscountedAmount() 方法的代码，这显然是不合理的，这就违反了开闭原则。
优化
抽象接口
// 抽象折扣策略接口
interface DiscountStrategy {double getDiscountedAmount(double totalAmount);
}具体策略
// 节日折扣策略
class FestivalDiscountStrategy implements DiscountStrategy {@Overridepublic double getDiscountedAmount(double totalAmount) {return totalAmount * 0.9; // 9折}
}// 季节折扣策略
class SeasonalDiscountStrategy implements DiscountStrategy {@Overridepublic double getDiscountedAmount(double totalAmount) {return totalAmount * 0.8; // 8折}
}class Order {private double totalAmount;private DiscountStrategy discountStrategy;public Order(double totalAmount, DiscountStrategy discountStrategy) {this.totalAmount = totalAmount;this.discountStrategy = discountStrategy;}public void setDiscountStrategy(DiscountStrategy discountStrategy) {this.discountStrategy = discountStrategy;}// 计算折扣后的金额public double getDiscountedAmount() {return discountStrategy.getDiscountedAmount(totalAmount);}
}在遵循开闭原则的代码中，我们定义了一个抽象的折扣策略接口 DiscountStrategy，然后为每种折扣类型创建了一个实现该接口的策略类。Order 类使用组合的方式，包含一个 DiscountStrategy 类型的成员变量，以便在运行时设置或更改折扣策略，（可以通过编码，配置、依赖注入等形式）。
这样，当我们需要添加新的折扣类型时，只需实现 DiscountStrategy 接口即可，而无需修改现有的 Order 代码。这个例子遵循了开闭原则。
二、修改代码就意味着违背开闭原则吗？
开闭原则的核心思想是要尽量减少对现有代码的修改，以降低修改带来的风险和影响。在实际开发过程中，完全不修改代码是不现实的！当需求变更或者发现代码中的错误时，修改代码是正常的。然而，开闭原则鼓励我们通过设计更好的代码结构，使得在添加新功能或者扩展系统时，尽量减少对现有代码的修改。
案例分析
以下是一个简化的日志记录器的示例，展示了在适当情况下修改代码，也不违背开闭原则。
在这个例子中，我们的应用程序支持将日志输出到控制台和文件。假设我们需要添加一个新功能，以便在输出日志时同时添加一个时间戳。
原始代码
interface Logger {void log(String message);
}class ConsoleLogger implements Logger {@Overridepublic void log(String message) {System.out.println("Console: " + message);}
}class FileLogger implements Logger {@Overridepublic void log(String message) {System.out.println("File: " + message);// 将日志写入文件的实现省略}
}为了添加时间戳功能，我们需要修改现有的 ConsoleLogger 和 FileLogger 类。虽然我们需要修改代码，但由于这是对现有功能的改进，而不是添加新的功能，所以这种修改是可以接受的，不违背开闭原则。
修改后的代码
interface Logger {void log(String message);
}class ConsoleLogger implements Logger {@Overridepublic void log(String message) {String timestamp = LocalDateTime.now().format(DateTimeFormatter.ISO_LOCAL_DATE_TIME);System.out.println("Console [" + timestamp + "]: " + message);}
}class FileLogger implements Logger {@Overridepublic void log(String message) {String timestamp = LocalDateTime.now().format(DateTimeFormatter.ISO_LOCAL_DATE_TIME);String logMessage = "File [" + timestamp + "]: " + message;System.out.println(logMessage);// 将日志写入文件的实现省略}
}在这个例子中，我们只是对现有的日志记录器类进行了适当的修改，以添加时间戳功能。这种修改不会影响到其他部分的代码，因此不违背开闭原则。总之，适当的修改代码并不一定违背开闭原则，关键在于我们如何权衡修改的影响和代码设计。
三、如何做到 "对扩展开放、修改关闭"？
开闭原则讲的就是代码的扩展性问题，是判断一段代码是否易扩展的“黄金标准”。
如果某段代码在应对未来需求变化的时候，能够做到“对扩展开放、对修改关闭”，那就说明这段代码的扩展性比较好。
在讲具体的方法论之前，我们先来看一些更加偏向顶层的指导思想。为了尽量写出扩展性好的代码，我们要时刻具备扩展意识、抽象意识、封装意识。这些“潜意识”可能比任何开发技巧都重要。
有些时候，我们有必要思考如下问题：
- 我要写的这段代码未来可能有哪些需求变更、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到“对扩展开放、对修改关闭”。
- 我们还要识别出代码可变部分和不可变部分，要将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。
需要注意的是，遵循开闭原则并不意味着永远不能修改代码。在实际开发过程中，完全不修改代码是不现实的。开闭原则的目标是要尽量降低修改代码带来的风险和影响，提高代码的可维护性和可复用性。在实际开发中，我们应该根据项目需求和预期的变化来平衡遵循开闭原则的程度。
文章到这里就结束了，如果有什么疑问的地方，可以在评论区指出~
希望能和大佬们一起努力，诸君顶峰相见
再次感谢各位小伙伴儿们的支持！！！