接口隔离原则与单一职责原则：9方法接口是否需拆分的技术问询

先给你明确结论：就你描述的场景——9个方法同属一个上下文，每次创建实例后都会用到全部方法，且依赖注入时处于同一作用域——绝对不需要把每个方法拆成单独的接口和实现类，理由如下：

• 别误解单一职责原则：这个原则的核心是“一个接口/类只负责一个业务逻辑单元”，不是“一个方法对应一个接口”。既然这9个方法始终一起被使用，说明它们本来就是高度内聚的逻辑集合，强行拆分反而会把完整的业务逻辑拆得支离破碎，调用方需要注入9个对象，你也要维护9套接口和实现，纯粹增加复杂度。
• 过度解耦反而添乱：依赖注入的目的是解耦，但拆分过度会让代码变得零散，可读性和可维护性直线下降。当所有方法都绑定在同一作用域、必须一起使用时，放在同一个接口里才是最合理的设计。
• 从开发效率看，维护一个内聚的接口和实现类，远比维护9个独立组件简单得多，你不需要重复配置依赖注入，也不用在业务代码里协调一堆零散的实例。

当然，也不是说永远不能拆，如果未来出现以下场景，可以考虑调整：

• 某个业务场景只需要用到其中部分方法，而非全部；
• 部分方法的依赖、生命周期（作用域）和其他方法不一致。

但就你当前的情况，保持现有接口的设计完全没问题，不用瞎折腾。

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