深度模块（Deep Module）与SRP：消息类设计方案抉择

我有一个可添加内容的Message对象，它还需要具备发送功能。现在纠结两种实现方案：一种是暴露Dispatcher遵循单一职责原则，另一种是隐藏Dispatcher做成深度模块。我觉得后者更易用、可测试，但违反了SRP，想知道哪种方案更优？

示例1：暴露Dispatcher（遵循SRP） #

class Message {
  void add(String key, String value) { ... }
}

class Dispatcher {
  Result send(Message message) { ... }
}

class DispatcherFactory {
  Dispatcher create() { return new DefaultDispatcher(); }
}

示例2：隐藏Dispatcher（深度模块） #

class MessageFactory {
   Message create() { return new Message(DefaultDispatcher()); }
}

class Message {
  Message(Dispatcher dispatcher) { ... }
 
  void add(String key, String value) { ... }
  
  Result send() {
    return dispatcher.dispatch(content);
  }
}

方案分析与选择 #

两种方案没有绝对的最优解，核心取决于你的业务场景、团队协作习惯和长期维护需求：

1. 优先选择示例1（SRP方案）的场景 #

• 业务需要频繁扩展发送逻辑：比如后续要新增邮件、短信、HTTP等不同发送渠道，或者发送逻辑要加限流、重试等复杂规则。这种情况下，Dispatcher作为独立模块可以快速新增实现类，完全不影响Message的代码。
• 团队强调职责清晰、可维护性：Message只负责数据封装，Dispatcher只负责发送，边界清晰，新成员接手时能快速理解代码结构，后续排查问题也更容易定位到对应模块。
• 测试粒度要求精细：测试Message只需验证数据添加逻辑，测试Dispatcher只需验证发送逻辑，两者完全隔离，不会出现测试用例互相干扰的情况。

2. 优先选择示例2（封装方案）的场景 #

• 业务场景稳定，发送逻辑变化少：如果短期内不需要扩展发送渠道，或者发送逻辑非常简单，封装后的API对调用方更友好——调用方只需要和Message交互，不用关心底层的Dispatcher，代码更简洁，学习成本低。
• 追求快速迭代与易用性：比如做小型项目或者快速原型，封装后的模块可以让调用方更快完成功能开发，减少不必要的代码层级。
• 可测试性完全有保障：你担心的违反SRP影响测试是多余的——通过构造函数注入Dispatcher，测试时可以传入Mock实现，完全能隔离测试Message的内容添加逻辑，并不会因为封装了Dispatcher就降低可测试性。

3. 折中方案：兼顾易用性与扩展性 #

如果想同时拿到两种方案的优势，可以保留Message的send()方法，但同时暴露独立的Dispatcher接口：

// 保留独立的Dispatcher接口
interface Dispatcher {
  Result dispatch(Message message);
}

class Message {
  private final Dispatcher dispatcher;
  // 存储内容的结构

  public Message(Dispatcher dispatcher) {
    this.dispatcher = dispatcher;
  }

  public void add(String key, String value) { ... }

  public Result send() {
    return dispatcher.dispatch(this);
  }
}

这种方式下，调用方可以选择直接用Message.send()的简洁API，也可以在需要自定义发送逻辑时，自己获取Dispatcher实例来处理，既保证了易用性，又保留了职责分离的灵活性。

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