C#中的“抽象”接口

Question

这是一个学术问题。 背后可能存在 X-Y 问题，稍后我可能会单独发布。但我我实际上对这里的学术问题特别感兴趣。

---

我经常发现我有一组接口，它们都有共同的属性。我想定义一个基本接口来通用这些接口，部分原因是因为没有重复，部分原因是我可以在不知道确切类型的情况下传递对象并使用常用方法。

也许我有IFooRepository、IBarRepository等，我可以声明IRepository<TEntity>。

或者我有一个IHappyBot、ISadBot、IConfusedBot，所有这些都有IBot。

值得注意的是，没有任何类会直接实现这些基本接口——你永远不会有实现的东西只是IBot。

如果我们谈论的是类的层次结构，而不是接口，那么我会说“啊……基本的东西是一个抽象类”。

我可以对接口做些什么类似的事情来记录IBot 不会被直接实现的期望。

我感兴趣的一个方面是做一些你以后可以通过反射检测到的事情，所以当我test my DI setup 时，我可以说“啊，这个界面不是预期的是可绑定的，因为它是“抽象的”。

---

我自己主要关心 C#，但如果这个特性特别存在于其他主要语言中，那么听到它会很有趣。

Answer 1

也许是一个哲学问题的回应 - 但是如果一个类想要实现 IBot，为什么它不能实现呢？

抽象类呢？我可能想要一个抽象的 Bot 基类来实现 IBot，以此来检查 Bot 基类是否符合基本 Bot 的所有预期功能。

界面是关于定义可以/应该做什么的，它是一个功能列表。在我看来，说“某些东西不能声称它满足这个功能列表”没有多大意义。

抽象类是有意义的，因为有时抽象类需要填补其实现漏洞（抽象方法等）。接口不是这种情况。

Answer 2

我不这么认为，接口的实现细节是故意向他们的合作者隐藏的。允许接口契约指定接口的实现细节将是混合隐喻，似乎没有意义。

如果你真的想实现这一点，你可以引入一个标记属性类，比如[AbstractInterface]，但我认为它的用途会非常有限（并且值得怀疑）。

您的励志示例，DI 系统需要知道接口是直接实现还是通过超级接口实现，这对我来说似乎没有说服力。我认为 DI 系统可以只寻找实现。