程序员必知！开放封闭原则的实战应用与案例分析-编程知识

开放封闭原则是面向对象设计中的重要原则之一，它要求软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。这意味着当需要添加新功能时，不应该修改现有的代码，而是应该通过扩展来实现。这可以通过使用接口、抽象类和多态等机制来实现，从而使系统更加灵活和可扩展。

程序员必知！开放封闭原则的实战应用与案例分析 - 程序员古德

定义

开放封闭原则（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）是面向对象设计的五个基本原则之一，它指导我们设计模块时应尽量使其对扩展开放，对修改关闭，这意味着我们可以增加新的功能，而不需要改动已有的代码。

优点：一是提高软件的可维护性，因为修改原有代码可能会引入新的错误；二是有利于团队协作，每个人都可以在不干扰其他人的情况下添加新功能；三是有利于复用，因为每个类或模块只做一件事，所以更容易找到可以复用的代码。

缺点：一是过度设计，如果预设了过多的扩展点，可能导致代码过于复杂；二是可能增加系统的耦合度，因为为了满足开封封闭原则，可能需要引入一些抽象类或接口。

使用建议：在实际开发中，我们应该根据项目需求和规模来权衡是否严格遵循开封封闭原则。对于小型项目或者短期内不会频繁变动的项目，可能不需要过度设计。而对于大型项目或者需要长期维护的项目，遵守开封封闭原则则更为重要。同时，我们也应该注意避免过度设计和增加系统耦合度的问题，可以通过重构和优化代码结构来解决这些问题。