Spring Boot SOAP场景下工厂类必须有父类吗？当前设计是否合理？

设计合理性评估 #

当前设计具备基础合理性：

• 两个工厂负责完全独立的SOAP请求生成场景，入参、返回值类型均不相同，不需要为了强行套用设计模式抽象公共父类/接口，避免过度设计
• 采用构造函数注入的方式依赖工厂类，符合Spring依赖注入的最佳实践，避免字段注入带来的测试、维护隐患

Factory命名是否合适 #

Factory命名完全符合当前类的职责定义：工厂类的核心作用就是封装复杂对象的创建逻辑，屏蔽请求对象字段组装、默认值填充、公共头植入等细节，不需要更换命名。
注意代码中存在拼写不一致问题：RetrieveComissionsFactory中少了字母m，统一修正为Commissions即可，避免后续维护混淆

现有实现的优化方向 #

当前实现已经可以支撑业务需求，可根据后续迭代规模选择以下优化方案：

• 公共逻辑抽离：如果两个工厂都需要依赖BGBAHeaderFactory生成公共SOAP头，可将公共头填充、通用参数赋值的逻辑抽到抽象父类中，减少重复代码

  public abstract class AbstractSoapRequestFactory {
      @Autowired
      protected BGBAHeaderFactory bgbaHeaderFactory;
  
      protected void fillCommonHeader(BaseSoapRequest request) {
          request.setHeader(bgbaHeaderFactory.createHeader());
          // 其他公共字段处理逻辑
      }
  }
  

  两个业务工厂继承该抽象类即可，不需要重复处理公共逻辑。
• 方法名简化：工厂类名已经明确了业务范围，内部创建方法可以简化前缀，例如retrieveComissionsFactory.createRetrieveCommissionsRequest(date)可简化为retrieveComissionsFactory.create(date)，可读性不会下降，调用更简洁。
• 长入参封装：如果创建方法的入参超过3个，建议封装独立的参数DTO，避免方法入参过长，后续新增参数也不需要修改方法签名：

  public class RegisterCommissionParam {
      private String change;
      private String operador;
      private String authorizing;
      private LocalDate fromDate;
      // 省略getter/setter
  }
  

  调用时改为editCommissionsFactory.create(registerParam)即可，可维护性更高。
• 可选的统一调度层：如果后续SOAP请求类型持续增加，可以新增一个统一的请求工厂调度类，主Service只需要注入调度类即可，不需要依赖多个工厂实例；如果仅维持2个工厂的规模则不需要做这层抽象，避免增加不必要的复杂度。

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