接口函数是否应当强制传入参数？购物车商品检索接口重构设计疑问

这种设计在你现在的重构阶段完全合理，没有任何问题。
很多人刚开始抽离接口的时候总容易走极端：一上来就想搭个能覆盖未来所有需求的万能接口，平白增加重构的复杂度。而你现在的核心目标非常明确——把原本硬编码在业务逻辑里的两套检索分支（生产环境走真实数据库查询、测试环境走可控的Mock数据返回）抽离成可替换的实现，根本不需要为不确定的未来做过度设计。
你提到的两个固定入参（商品ID、是否检索已删除商品），是当前所有现有检索场景100%会用到的参数，没有其他需要临时分支判断的逻辑。把这两个参数直接纳入接口方法签名，完全符合「接口是所有实现必须遵守的统一调用契约」的核心定义，也刚好匹配*YAGNI（你不会需要它）*原则，完全没问题。

如果后续不对设计做主动调整，当业务需求迭代到需要新增检索维度、扩充查询参数时，会遇到三个非常实际的痛点：

• 接口快速膨胀成“大杂烩”：如果你始终把不同维度的检索需求（比如按商品ID查单个购物车条目、按用户ID查全量购物车列表、按购物车批次ID查一组条目）都堆在最开始定义的这一个检索接口上，最后这个接口会变成什么场景都要管的万能接口。而你最开始做的测试专用实现，往往只需要适配某一个特定的检索场景，到时候就会被迫写一堆空实现、或者直接抛出“当前方法未支持”的异常，维护成本会随着接口上方法数量的增长直线上升。
• 方法签名变更的连锁反应：如果一开始你就把入参硬编码在方法签名上（比如写死GetCartItem(long productId, bool includeDeleted)），后续只要新增一个控制参数（比如是否关联查询商品实时价格、是否过滤已经失效的优惠关联项），就必须修改接口的方法签名——这会逼着所有实现类、所有调用这个接口的业务代码同步修改，完全失去了接口解耦的设计意义。
• 测试实现的适配成本失控：你当初做测试专用实现的核心目的，本来是降低测试场景的Mock成本。但如果接口方法频繁变更签名、入参越来越多，你写测试用例的时候就要给每一次调用传一堆根本不关心的无效参数，最后测试代码的维护成本甚至会超过当初没抽接口的时候。

针对上面提到的问题，完全可以在不增加太多初期复杂度的前提下提前做预留，不需要把简单的事情搞复杂：

• 把硬编码的方法入参替换为独立的查询请求值对象。不要直接把两个参数写死在方法签名上，而是定义一个CartItemQuery类，把当前的商品ID、是否查已删除商品作为这个类的属性，接口方法签名统一改成GetCartItem(CartItemQuery query)。后续如果需要新增任何检索相关的控制参数，直接往这个Query类里加字段、给好默认值即可，完全不需要改动接口方法签名，所有原有实现和调用方都不需要做适配，兼容性会好很多。
• 按检索的业务维度拆分接口粒度，不要搞大一统的检索接口。比如你当前只需要做「按商品ID检索购物车单个条目」的能力，就把对应的接口定义为单商品检索的专用接口；未来如果要做「按用户检索全量购物车列表」的能力，就单独定义对应的列表检索接口，不要把不同维度的方法都堆在同一个接口上。这样你的测试专用实现只需要适配对应场景的接口，完全不需要接和自己无关的方法，从根源上避免空实现的问题。
• 给非核心的检索能力预留默认实现。在接口设计上，对后期新增的非核心方法，提供框架层面的默认逻辑（比如默认抛出“当前场景不支持该检索能力”的标准化异常），不需要每个实现类都强制重写一遍冗余的空逻辑，减少重复代码。

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