策略接口：构造函数配置vs显式方法参数，哪种更适合订单处理器API？

我更倾向于方案2，核心原因如下：

1. 职责划分更清晰 #

构造函数传入的warehouse_layout和cluster_capacity属于处理器的固定依赖配置，这类数据在同一个租户的批处理流程中不会变化；而orders是每次批处理的动态输入数据。方案2将两者分离，process方法只专注于处理动态订单数据，完全符合单一职责原则。

2. 减少冗余代码 #

结合你的业务背景：每个API请求对应一个租户，加载该租户的固定配置后才会处理订单。用方案2的话，处理器初始化时传入一次固定配置即可，无需在每次调用process时重复传递相同的配置参数，代码更简洁易维护。

3. 契约语义更明确 #

方案2的process方法参数直接暴露了"每次批处理需要什么动态数据"，而固定依赖通过构造函数注入，使用者能快速区分哪些是初始化时的配置项，哪些是每次调用的必填项，降低了使用成本。

4. 适配对象生命周期 #

如果同一个租户需要多次执行批处理，方案2的处理器实例可以复用（只要保证线程安全），避免重复加载和初始化配置相关资源，提升效率。

补充：方案1的适用场景 #

方案1并非完全不可取——如果你的业务未来需要让同一个处理器实例切换不同租户的配置（比如跨租户批量处理），方案1的灵活性会更高。但结合当前你描述的API场景（按租户ID单请求处理），方案2的适配性和可维护性更优。

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