Ruby中Service类实例化后仅调用call方法的设计疑问

• 状态隔离与复用弹性：哪怕当前场景里实例只用一次，但这种模式天然支持状态隔离。如果后续需求变了，要多次调用同一个实例（比如同一个契约实例验证多组数据，或者服务需要保留中间状态做后续操作），不用改结构就能适配。换成类方法的话，要实现状态隔离就得每次在方法里搞局部变量，还要处理线程安全，反而麻烦。

• 依赖注入更清晰：初始化时传参数，等于把依赖明明白白注入到实例里，看代码一眼就知道这个服务靠什么运行。比如Service.new(user_repo, logger).call(params)，依赖一目了然。要是用类方法，要么把依赖硬写在方法里，要么每次调用都带一堆参数，显得乱糟糟。

• 贴合面向对象设计：这种写法更符合单一职责和封装性。实例属性存服务运行需要的上下文，call方法只负责执行核心逻辑。类方法容易把逻辑和上下文混在一起，逻辑复杂起来后，类方法会变得臃肿，拆分和维护都费劲。

• 测试更方便：初始化实例时可以传模拟对象（比如测试用的假数据仓库、假日志），然后调用call测逻辑，测试和生产逻辑完全一致。用类方法的话，可能得靠猴子补丁或者依赖注入框架替换依赖，测试成本高多了。

• 适配Ruby生态与设计模式：像dry-validation这类gem本身就是基于实例设计的，因为契约类可能包含配置（比如验证规则），初始化时能根据场景调整配置，类方法很难做到这么灵活。另外，Ruby里的命令模式等常见模式都是基于实例的，这种写法能无缝衔接这些模式。

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