我的Spring Boot消息发送设计是否违反里氏替换原则（LSP）？

我正在开发一个Spring Boot应用，消息发送结构如下：

public interface MessageService {
  void send(String message);
}

@Component("SendEmailService")
public class SendEmailService implements MessageService {

  @Override
  public void send(String message) {
    System.out.println("SendEmailService");
  }
}

@Component("SendSmsService")
public class SendSmsService implements MessageService {

  @Override
  public void send(String message) {
    System.out.println("SendSms");
  }
}

目前应用运行正常，但现在有新需求：部分邮件消息发送失败时需具备重试机制。我的实现方式如下：

public class ExceptionUtils {

  public static void retryOnException(Runnable runnable, int maxRetries, long timeSeed) {
    // Retry logic here
  }
}

@Component("RetryableSendEmailService")
public class RetryableSendEmailService extends SendEmailService {

  @Override
  public void send(String message) {
    ExceptionUtils.retryOnException(() -> super.send(message), 3, 5000);
  }
}

设计思路 #

• 创建了继承自SendEmailService的RetryableSendEmailService类；
• 需要重试逻辑的组件注入RetryableSendEmailService，无需则注入SendEmailService。

担忧 #

我担心该设计可能违反SOLID原则中的里氏替换原则（LSP），该原则定义为：

子类对象应当能够替换父类对象，且不会破坏应用程序的运行。这要求子类的行为与父类保持一致。

问题 #

1. 在RetryableSendEmailService中添加重试机制是否因改变send方法行为而违反LSP？
2. 如何重构代码以更贴合SOLID原则（尤其是LSP），同时保留所需功能？

1. 是否违反里氏替换原则？ #

大概率会违反，核心取决于父类SendEmailService的行为约定：

• 如果父类send方法的隐含或明确约定是「仅执行一次邮件发送操作」，那么子类的重试逻辑直接改变了核心行为——原本单次执行的操作变成最多4次（1次尝试+3次重试），依赖父类的代码替换成子类后，可能出现重复发送、触发第三方接口限流、日志冗余等非预期问题，这种情况完全违反LSP。
• 如果父类仅约定「确保邮件尽可能发送成功」，未限制执行次数，重试属于行为增强而非改变，可能不违反LSP。但实际开发中，send方法默认被理解为单次执行，所以你的担忧是合理的，当前设计存在违反LSP的风险。

2. 重构方案：使用装饰器模式 #

装饰器模式能在不修改原有类的前提下动态扩展功能，完美契合SOLID原则（尤其是LSP和开闭原则），具体实现如下：

步骤1：保留原有SendEmailService不变 #

@Component("SendEmailService")
public class SendEmailService implements MessageService {

  @Override
  public void send(String message) {
    System.out.println("SendEmailService");
  }
}

步骤2：创建重试装饰器，实现MessageService接口 #

通过依赖注入原有邮件服务，而非继承，避免强耦合：

@Component("RetryableSendEmailService")
public class RetryableEmailDecorator implements MessageService {

  private final MessageService emailService;

  // 构造注入原有邮件服务
  public RetryableEmailDecorator(@Qualifier("SendEmailService") MessageService emailService) {
    this.emailService = emailService;
  }

  @Override
  public void send(String message) {
    ExceptionUtils.retryOnException(() -> emailService.send(message), 3, 5000);
  }
}

步骤3：按需注入使用 #

• 需要重试功能时，注入RetryableEmailDecorator（或通过@Qualifier("RetryableSendEmailService")指定）；
• 不需要重试时，直接注入SendEmailService。

方案优势 #

• 符合LSP：装饰器和原有服务都实现MessageService接口，替换时不会破坏原有逻辑，均遵循接口行为约定；
• 符合开闭原则：无需修改原有类代码，通过新增装饰器扩展功能；
• 灵活性强：可轻松添加其他装饰器（如日志、限流装饰器），组合多种功能；
• 降低耦合：避免继承带来的子类与父类强绑定问题。

额外优化：结合Spring Retry简化实现 #

若项目已引入Spring Retry依赖，可直接用注解实现重试，无需手动编写ExceptionUtils：

// 启用Spring Retry
@EnableRetry
@SpringBootApplication
public class Application {
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

// 方式1：直接在原有服务添加重试注解
@Component("SendEmailService")
public class SendEmailService implements MessageService {

  @Retryable(maxAttempts = 4, backoff = @Backoff(delay = 5000))
  @Override
  public void send(String message) {
    System.out.println("SendEmailService");
    // 模拟发送异常
    // throw new RuntimeException("发送失败");
  }
}

// 方式2：保留原有服务，用装饰器结合注解
@Component("RetryableSendEmailService")
public class RetryableEmailDecorator implements MessageService {

  private final SendEmailService emailService;

  public RetryableEmailDecorator(SendEmailService emailService) {
    this.emailService = emailService;
  }

  @Retryable(maxAttempts = 4, backoff = @Backoff(delay = 5000))
  @Override
  public void send(String message) {
    emailService.send(message);
  }
}

内容的提问来源于stack exchange，提问作者Tom