“注入”使用扩展方法实现到类中，从而实现接口？
是否可以将代码“注入”到类中（通过引用包含扩展方法的命名空间），从而模拟某些接口的基类实现？或者这被认为是不好的做法（即使不可能）？
Imports MyApp.Extensions
Class SomeClass : Inherits System.SomeBaseClass : Implements MyApp.IAppInterface
End Class
Public Interface IAppInterface
Sub InterfaceMethod()
End Interface
Namespace MyApp.Extensions
Public Module SomeClassExtensions
Public Sub InterfaceMethod(ByVal someClass as MyApp.SomeClass)
//Implementation
End Sub
End Module
End Namespace
Is it possible to 'inject' code into a class (by referencing a namespace containing extension methods) and thereby simulating base class implementation for some interface? Or is this considered bad practice (even if it is not possible)?
Imports MyApp.Extensions
Class SomeClass : Inherits System.SomeBaseClass : Implements MyApp.IAppInterface
End Class
Public Interface IAppInterface
Sub InterfaceMethod()
End Interface
Namespace MyApp.Extensions
Public Module SomeClassExtensions
Public Sub InterfaceMethod(ByVal someClass as MyApp.SomeClass)
//Implementation
End Sub
End Module
End Namespace
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
问题是，您的
SomeClassExtensions.InterfaceMethod将如何执行？即在IAppInterface中定义哪些属性/方法，以便有足够的数据/行为供您在扩展方法中实现它？我想您会发现接口必须具有一组特定的“基本”方法才能使其有意义。最重要的是，人们经常在接口上定义其他方法，以使调用者更方便——这些方法实际上只是“基本”接口方法集的组合。这些方便的方法是从接口中删除的绝佳候选方法，并通过扩展方法完全定义。这减轻了接口实现者必须实现这些便捷方法（无论实现如何，通常都以相同方式编码的便捷方法）的负担，同时仍然允许您的调用者享受能够调用它们的好处。
The question is, how would your
SomeClassExtensions.InterfaceMethodcarry out the implementation? i.e. What properties/methods would be defined inIAppInterfacesuch that there is enough data/behavior for you to implement it in the extension method? I think you'll find that the interface must have a certain "base" set of methods in order for it to be meaningful.On top of that, people often define other methods on the interface to make it more conveninent for the caller -- methods that are really just compositions of the "base" set of interface methods. These convenience methods are an excellent candidate to be removed from the interface, and wholly defined via extension methods. This relieves the burden on implementors of your interface from having to implement these convenience methods (convenience methods that are usually coded the same way regardless of implementation), while still allowing your callers to enjoy the benefit of being able to invoke them.
我认为您误解了扩展方法是什么。 这里是一个关于与扩展方法相关的设计模式的问题。扩展方法的本体论是它们将动作“附加”到对象，而不是通常的“是”关系。您无法使用它们实现接口方法，因为扩展方法附加到的任何对象都是非抽象的（您已经实例化了它，对吧？），因此这会导致编译错误。
I think you are misunderstanding what extension methods are. Here is a question about design patterns related to extension methods. The ontology of an extension method is that they "attach" actions to an object rather than the usual "is a" relationship. You can't implement interface methods with them because any object that an extension method is being attached to is non-abstract (you instantiated it already, right?) so there fore this would cause a compile error.