C# 中接口上具有扩展方法的伪多重继承？
我认为扩展方法与接口位于同一名称空间中您可以获得与多重继承类似的效果，因为您不需要在 10 个不同的类中以相同的方式使用重复的代码来实现相同的接口。
这样做有哪些缺点？ 我认为优点是非常明显的，缺点通常会在稍后回来咬你。
我看到的缺点之一是扩展方法不能是虚拟的，因此您需要确保您确实希望它们以相同的方式为每个实例实现。
Similar question but not quite the same thing
I was thinking that with extension methods in the same namespace as the interface you could get a similar effect to multiple inheritance in that you don't need to have duplicate code implementing the same interface the same way in 10 different classes.
What are some of the downsides of doing this? I think the pros are pretty obvious, it's the cons that usually come back to bite you later on.
One of the cons I see is that the extension methods can't be virtual, so you need to be sure that you actually do want them implemented the same way for every instance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我发现通过扩展方法构建接口功能的问题是，您不再实际实现接口，因此无法使用对象作为接口类型。
假设我有一个采用 IBar 类型的对象的方法。 如果我通过扩展方法在 Foo 类上实现 IBar 接口，那么 Foo 就不是从 IBar 派生的，并且不能与其互换使用（里氏替换原则）。 当然，我得到了我想要添加到 Foo 中的行为，但是我首先失去了创建接口的最重要的方面——能够定义一个抽象契约，该契约可以由各种类以多种方式实现，以便依赖类不需要知道具体的实现。
如果我非常需要多重继承（到目前为止我一直没有它），我想我会使用组合来最大程度地减少代码重复量。
The problem that I see with building interface capability via extension methods is that you are no longer actually implementing the interface and so can't use the object as the interface type.
Say I have a method that takes an object of type IBar. If I implement the IBar interface on class Foo via extension methods, then Foo doesn't derive from IBar and can't be used interchangeably with it (Liskov Substitution principle). Sure, I get the behavior that I want added to Foo, but I lose the most important aspect of creating interfaces in the first place -- being able to define an abstract contract that can be implemented in a variety of ways by various classes so that dependent classes need not know about concrete implementations.
If I needed multiple inheritance (and so far I've lived without it) badly enough, I think I'd use composition instead to minimize the amount of code duplication.
考虑这个问题的一个不错的方法是，实例方法是由对象完成的，而扩展方法是对对象完成的。 我相当确定框架设计指南说您应该尽可能实现实例方法。
接口声明“我关心使用此功能，但不关心它是如何实现的”。 这使得实施者可以自由选择如何实施。 它将意图（公共 API）与机制（具有具体代码的类）分离。
由于这是接口的主要优点，因此将它们完全实现为扩展方法似乎违背了它们的目的。 甚至
IEnumerable也有一个实例方法。编辑：此外，对象旨在对其包含的数据进行操作。 扩展方法只能看到对象的公共 API（因为它们只是静态方法）； 您必须公开对象的所有状态才能使其正常工作（面向对象的禁忌）。
A decent way to think about this is that instance methods are something done by the object, while extension methods are something done to the object. I am fairly certain the Framework Design Guidelines say you should implement an instance method whenever possible.
An interface declares "I care about using this functionality, but not how it is accomplished." That leaves implementers the freedom to choose the how. It decouples the intent, a public API, from the mechanism, a class with concrete code.
As this is the main benefit of interfaces, implementing them entirely as extension methods seems to defeat their purpose. Even
IEnumerable<T>has an instance method.Edit: Also, objects are meant to act on the data they contain. Extension methods can only see an object's public API (as they are just static methods); you would have to expose all of an object's state to make it work (an OO no-no).