开放封闭原则是面向对象设计中的重要原则之一，它要求软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。这意味着当需要添加新功能时，不应该修改现有的代码，而是应该通过扩展来实现。这可以通过使用接口、抽象类和多态等机制来实现，从而使系统更加灵活和可扩展。
定义
开放封闭原则（Open Closed Principle，简称OCP）是面向开放封闭原则（Open Closed Principle，简称OCP）是面向对象设计中的一个重要原则，它由Bertrand Meyer于1988年提出。该原则主张软件实体（类、模块、函数等等）应该对扩展开放，对修改关闭，这意味着，当需要添加新功能时，我们应该尽量通过扩展已有的代码来实现，而不是修改原有的代码。
该原则的核心思想是，对于已经设计好的软件实体，应该在不修改其源代码的情况下，通过扩展来增加新的功能或行为。换句话说，我们应该尽可能地保持软件实体的稳定性和可靠性，而不是通过修改源代码来适应新的需求。在实现开放封闭原则时，需要注意以下几点：
- 对扩展开放：当需要添加新功能时，应该通过扩展现有的类或模块来实现，而不是修改现有的代码。这可以通过使用接口、抽象类和多态等机制来实现。
- 对修改关闭：当添加新功能时，不应该修改现有的代码。如果必须修改现有的代码，那么这种修改应该是有计划、有目的的，并且应该尽量避免对其他部分的代码产生影响。
- 抽象化设计：通过抽象化设计，可以将具体的实现细节隐藏在抽象接口之后，从而保护现有的代码不被修改。同时，抽象化设计也可以提高代码的可重用性和可维护性。
- 模块化设计：通过模块化设计，可以将系统划分为多个独立的模块，每个模块都有明确的职责和功能。这样可以降低系统的耦合度，提高系统的可维护性和可扩展性。
代码案例
假设我们正在开发一个电商系统，其中包括一个订单处理模块，该模块负责处理用户的订单，包括计算订单金额、生成订单号、发送订单确认邮件等功能。
首先，我们来看一个不符合开放封闭原则的设计，代码如下：
/**
* @版权 Copyright by 程序员古德 <br>
* @创建人 程序员古德 <br>
* @创建时间 2023/12/15 16:37 <br>
*/
// 不符合开放封闭原则的设计
public class OrderProcessor {
public void processOrder(Order order) {
// 计算订单金额
double amount = calculateOrderAmount(order);
// 生成订单号
String orderNumber = generateOrderNumber();
// 发送订单确认邮件
sendOrderConfirmationEmail(order, amount, orderNumber);
// 其他订单处理逻辑...
}
private double calculateOrderAmount(Order order) {
// 计算订单金额的逻辑
return 0.0;
}
private String generateOrderNumber() {
// 生成订单号的逻辑
return null;
}
private void sendOrderConfirmationEmail(Order order, double amount, String orderNumber) {
// 发送订单确认邮件的逻辑
}
}
在上面的代码中，OrderProcessor类负责处理订单的全部逻辑，包括计算金额、生成订单号、发送确认邮件等。如果我们需要添加新的功能，比如添加优惠券处理逻辑，就需要修改OrderProcessor类的代码，这样不符合开放封闭原则，每次添加新功能都需要修改已有代码，会增加系统的维护成本，并且容易引入错误。
为了解决这个问题，我们可以使用开放封闭原则进行改进，我们可以将订单处理的不同功能抽象为不同的接口，比如OrderAmountCalculator、OrderNumberGenerator、OrderConfirmationEmailSender等。然后，我们可以实现这些接口来提供具体的功能实现，这样，当需要添加新功能时，只需要扩展相应的接口，而不需要修改已有的代码，下面是改进后的代码：
/**
* @版权 Copyright by 程序员古德 <br>
* @创建人 程序员古德 <br>
* @创建时间 2023/12/15 16:37 <br>
*/
// 符合开放封闭原则的设计
public interface OrderAmountCalculator {
double calculate(Order order);
}
public interface OrderNumberGenerator {
String generate();
}
public interface OrderConfirmationEmailSender {
void send(Order order, double amount, String orderNumber);
}
public class SimpleOrderAmountCalculator implements OrderAmountCalculator {
@Override
public double calculate(Order order) {
// 计算订单金额的逻辑
return 0.0;
}
}
public class SimpleOrderNumberGenerator implements OrderNumberGenerator {
@Override
public String generate() {
// 生成订单号的逻辑
return null;
}
}
public class SimpleOrderConfirmationEmailSender implements OrderConfirmationEmailSender {
@Override
public void send(Order order, double amount, String orderNumber) {
// 发送订单确认邮件的逻辑
}
}
public class OrderProcessor {
private OrderAmountCalculator orderAmountCalculator;
private OrderNumberGenerator orderNumberGenerator;
private OrderConfirmationEmailSender orderConfirmationEmailSender;
public OrderProcessor(OrderAmountCalculator orderAmountCalculator, OrderNumberGenerator orderNumberGenerator, OrderConfirmationEmailSender orderConfirmationEmailSender) {
this.orderAmountCalculator = orderAmountCalculator;
this.orderNumberGenerator = orderNumberGenerator;
this.orderConfirmationEmailSender = orderConfirmationEmailSender;
}
public void processOrder(Order order) {
double amount = orderAmountCalculator.calculate(order);
String orderNumber = orderNumberGenerator.generate();
orderConfirmationEmailSender.send(order, amount, orderNumber);
// 其他订单处理逻辑...
}
}
在上面的代码中，我们将订单处理的不同功能抽象为了不同的接口，并且提供了相应的实现类，这样，当需要添加新功能时，只需要扩展相应的接口，并提供一个新的实现类即可，比如，如果我们想要添加优惠券处理逻辑，可以创建一个实现了OrderAmountCalculator接口的CouponOrderAmountCalculator类，然后在创建OrderProcessor对象时传入这个新的实现类即可。这种方式符合开放封闭原则，可以在不修改已有代码的情况下扩展系统的功能。同时，由于使用了接口进行抽象，代码的可读性和可维护性也得到了提高，这种方式可以使我们的系统更加灵活和可扩展。
核心总结
开封封闭原则（Open-Closed Principle，OCP）是面向对象设计的五个基本原则之一，它指导我们设计模块时应尽量使其对扩展开放，对修改关闭，这意味着我们可以增加新的功能，而不需要改动已有的代码。
优点：一是提高软件的可维护性，因为修改原有代码可能会引入新的错误；二是有利于团队协作，每个人都可以在不干扰其他人的情况下添加新功能；三是有利于复用，因为每个类或模块只做一件事，所以更容易找到可以复用的代码。
缺点：一是过度设计，如果预设了过多的扩展点，可能导致代码过于复杂；二是可能增加系统的耦合度，因为为了满足开封封闭原则，可能需要引入一些抽象类或接口。
使用建议：在实际开发中，我们应该根据项目需求和规模来权衡是否严格遵循开封封闭原则。对于小型项目或者短期内不会频繁变动的项目，可能不需要过度设计。而对于大型项目或者需要长期维护的项目，遵守开封封闭原则则更为重要。同时，我们也应该注意避免过度设计和增加系统耦合度的问题，可以通过重构和优化代码结构来解决这些问题。
