虽然这只是我个人的猜测,但我认为在中大型软件团队使用扩展时可能会涉及其他问题。
查看微软的指南link text,您会发现:
一般来说,您可能会更频繁地调用扩展方法而不是实现自己的方法。我们建议仅在必要时适度使用扩展方法。每当可能时,必须扩展现有类型的客户端代码应通过创建从现有类型派生的新类型来完成。有关更多信息,请参见继承(C#编程指南)...当编译器遇到方法调用时,它首先查找类型的实例方法。如果没有找到匹配项,则会搜索为该类型定义的任何扩展方法,并绑定到它找到的第一个扩展方法。
还有微软的link text:
扩展方法没有特定的安全漏洞。它们永远不能用于冒充类型上现有的方法,因为所有名称冲突都会被解析为由类型本身定义的实例或静态方法。扩展方法无法访问扩展类中的任何私有数据。
我认为显而易见的因素包括:
我假设您不会编写扩展方法,除非您期望它被广泛且频繁地使用。另一方面:您不能说子类化也是同样的吗?
知道我们可以将它们编译成单独的dll,并添加编译后的dll并引用它,然后使用扩展:“很酷”,但是否“平衡了”编译器首先必须检查是否定义了实例方法,如上所述。或者在“名称冲突”的情况下,使用Static调用方法确保调用扩展而不是实例定义的成本?
频繁使用扩展方法如何影响运行时性能或内存使用:我不知道。
因此,我希望您能分享您的想法,或者了解何时使用扩展和何时不使用,与子类化相比。
谢谢,比尔
this
)的非虚拟、非接口实例方法完全相同。 - Pavel Minaev