什么时候该使用interface/abstract class，什么时候应当避免使用？

以下是可直接落地的边界判断准则，完全覆盖过度使用interface/abstract class的判定需求：

只要符合任意一条，基本就属于不必要的过度设计：

• 为只有唯一实现的类提前定义interface/abstract class，且未来1-2个版本周期内没有明确的多实现规划。你提到的过度设计示例就属于这类情况：仅有一种业务实现的场景下硬套接口，除了增加代码层级没有任何实际价值。
• 抽象粒度细到仅对应单个方法，且这个方法没有被多个不同业务域的类复用的需求。比如为每个独立的业务操作都单独定义一个IXxxOperator接口，内部只有一个Run方法，全程没有多态调用的场景，只是为了凑“面向接口编程”的名头。
• 抽象层完全没有屏蔽实现细节，使用者需要同时了解抽象定义和具体实现逻辑才能正常调用，这类抽象没有实际意义，属于为了用而用。
• 为了适配抽象层，需要给实现类写大量冗余的空实现、抛不支持异常的方法。比如让仅支持查询的仓储类实现包含增删改查全方法的IRepository接口，不得不把增删改方法都实现为抛NotSupportedException，就是典型的过度抽象。

使用interface/abstract class之前依次做三个检查，全部通过再使用就不会出现过度设计的问题：

• 必要性检查：如果删掉这个interface/abstract class，当前的业务逻辑能不能正常跑通、可维护性会不会下降？如果删掉之后代码更简洁、没有潜在的扩展风险，那当前的使用就是过度的。
• 多实现验证：你能不能立刻说出至少2个该抽象层的不同实现场景？如果只能想到1个，且没有明确的未来扩展需求，就没必要提前加抽象层。
• 调用方验证：你的代码里有没有调用方依赖这个抽象层，而不是直接依赖具体实现？如果所有调用的地方都直接用了实现类，抽象层完全没被用到，就属于冗余设计。

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