Bil*_*llW 7 c# extension-methods c#-3.0
在什么情况下(使用场景)你会选择编写扩展而不是对对象进行子类化？
<完全披露:我不是MS员工; 我个人不知道Mitsu Furota; 我知道这里提到的开源Componax库的作者,但我与他没有任何业务往来; 我不是在创建或计划使用扩展创建任何商业产品:总之:这篇文章来自与我试图(不断)意识到"最佳实践"相关的纯粹智力上的好奇心
我发现扩展方法的想法很"酷",显然你可以用它们做"远远"的事情,就像你在Mitsu Furota(MS)博客文章链接文本中的许多例子一样.
一位私人朋友写了开源Componax图书馆链接文本,那里有一些非凡的设施; 但他完全控制着他的小公司,完全控制代码指南,每一行代码都"通过他的手".
虽然这是我的猜测:我认为/猜测其他问题可能会在大中型软件团队的情况下重新使用Extensions.
在链接文本中查看MS的指南,您会发现:
通常,您可能会比实现自己的方法更频繁地调用扩展方法....一般情况下,我们建议您谨慎实施扩展方法,并且仅在必要时实施.必要时,必须扩展现有类型的客户端代码应通过创建从现有类型派生的新类型来实现.有关更多信息,请参见继承(C#编程指南)....当编译器遇到方法调用时,它首先在类型的实例方法中查找匹配项.如果未找到匹配项,它将搜索为该类型定义的任何扩展方法,并绑定到它找到的第一个扩展方法.
在Ms的链接文本中:
扩展方法没有特定的安全漏洞.它们永远不能用于模拟类型上的现有方法,因为所有名称冲突都被解析为有利于类型本身定义的实例或静态方法.扩展方法无法访问扩展类中的任何私有数据.
对我来说显而易见的因素包括:
我假设你不会写一个扩展,除非你期望它被非常普遍地使用.另一方面:难道你不能对子类别说同样的话吗？
知道我们可以将它们编译成一个单独的dll,并添加已编译的dll,并引用它,然后使用扩展:是"酷",但是这"平衡"编译器中固有的成本首先必须检查才能看到如果实例方法如上所述定义.或者,在"名称冲突"的情况下使用静态调用方法来确保调用扩展而不是实例定义的成本？
频繁使用Extensions会影响运行时性能或内存使用:我不知道.
因此,与子分类相比,我会感谢您的想法,或了解您如何/何时做或不做,使用扩展.
比尔,谢谢
sni*_*ker 11
我最大的用途是扩展封闭的第三方API.
大多数情况下,当软件开发人员最近在Windows上提供API时,他们越来越倾向于使用.NET来实现这种可扩展性.我喜欢这样做,因为我更喜欢依赖我自己的方法,我可以在将来修改它们,并在它们改变它的情况下充当它们的API的全局入口点.
以前,当必须这样做,并且我无法继承API对象,因为它是密封的或其他东西,我将依赖于适配器模式来创建我自己的包裹其对象的类.这是一个功能齐全但不太优雅的解决方案.扩展方法为您提供了一种美妙的方式,可以为您无法控制的内容添加更多功能.
LINQ,许多其他人最大的用途!
没有为IEnumerable提供的扩展方法,LINQ是不可能的.
人们喜欢它们的原因是因为它们使代码更具可读性.
我注意到扩展方法的另一个主要用途(包括我自己)是为了使代码更具可读性,并使它看起来好像做某事的代码属于它应该的地方.它也摆脱了我多次见过的可怕的"Util"静态神级.什么看起来更好...... Util.DecimalToFraction(decimal value);或者value.ToFraction();？如果你像我一样,后者.
最后,有些人认为"静态方法"是邪恶的!
许多"优秀程序员"会告诉您应该尽量避免使用静态方法,尤其是那些使用大量单元测试的方法.静态方法在某些情况下很难测试,但如果使用得当它们并不邪恶.虽然扩展方法是静态的......它们看起来或行为都不像它.这允许您从类中获取这些静态方法,并将它们添加到它们应该附加到的对象上.
关于表现..
扩展方法与调用静态方法没有什么不同,将被扩展的对象作为参数传递...因为这是编译器将其转换为的内容.最棒的是你的代码看起来干净,它做你想要的,编译器为你处理脏工作.