TypeScript服务：何时向构造函数传参而非执行方法传参？

方案一是否合理？ #

方案一不合理，核心问题在于它把动态业务数据绑定到了服务实例的状态中，违背了服务类的设计原则，具体原因如下：

1. 服务复用性彻底丧失 #

将rows作为构造函数参数存入私有变量后，一个FilterRowsService实例只能对应处理一组固定的行数据。如果业务中需要多组数据的过滤操作，必须反复创建新的服务实例，完全浪费了服务类“提供通用可复用功能”的定位。

2. 隐藏的副作用导致逻辑不可控 #

过滤方法直接修改实例内部的rows变量，属于带隐式副作用的操作。外部调用者无法感知实例内部状态的变化：

• 第一次调用过滤方法后，实例的rows已经被修改；
• 第二次调用时，会基于修改后的结果继续处理，而非原始数据，很容易出现不符合预期的逻辑错误，调试时也需要追踪实例状态的变化链路，成本极高。

3. 测试与维护成本飙升 #

这种带状态的设计违背了纯函数原则：方法的输出不仅依赖输入参数，还依赖实例的内部状态。单元测试时，每次测试都需要先初始化实例的rows状态，测试用例无法独立执行（多个测试会互相污染实例状态），维护起来非常繁琐。

正确的传参策略 #

适合构造函数传参的场景 #

当参数是服务生命周期内固定不变的依赖/配置时，才适合在构造函数传入：

• 比如固定的过滤规则模板、数据库连接实例、日志工具等，这些资源不会随每次业务操作变化，属于服务的初始化依赖。

适合方法传参的场景 #

当参数是每次操作的动态业务数据时（比如这里的rows），必须在执行方法（如execute）中传入：

• 让服务方法成为无状态的纯函数，仅依赖输入参数，返回新的处理结果，不修改任何外部或内部状态；
• 方案二正是这种设计，它的优势很明显：同一个服务实例可以反复处理不同的行数据，复用性高；输入输出完全可预测，测试简单；不修改原始数据，避免了意外的副作用。

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