Rob*_*vey 11 c# extension-methods
我发现它们是扩展现有类的一种非常自然的方式,特别是当您只需要将某些功能"点焊"到现有类时.
微软表示,"一般来说,我们建议您谨慎实施扩展方法,并且只在必要时才实施." 然而,扩展方法构成了Linq的基础; 事实上,Linq是创建扩展方法的原因.
是否存在使用扩展方法而不是继承或组合的特定设计标准？他们劝阻什么标准？
Eri*_*ert 16
我们向C#MVP展示了提出的新语言功能(至少是那些有一半看到光明的机会)的早期反馈.我们经常在很多功能上得到的一些反馈是" 我会明智地使用这个功能,并且符合该功能的设计原则,但是我的goofball同事会对这个东西发疯,并写出一大堆不可维护的东西,不可理解的代码,我将在接下来的十年中遇到调试问题,所以我希望它能够实现这个功能!"
虽然我在某种程度上夸大了喜剧效果,但这是我们非常认真对待的事情; 我们希望设计新功能以鼓励他们使用,但不鼓励他们滥用.
我们担心扩展方法会被用来,例如,不加区别地不加区分地扩展"对象",从而创建一个很难理解,调试和维护的松散类型的泥球.
我个人特别关注你在"流利"编程中看到的"可爱"扩展方法.好像的东西
6.Times(x=>Print("hello"));
呸."for"循环在C#中普遍可以理解和惯用; 不要装可爱.
Ree*_*sey 11
问题是扩展方法不一定清楚.
当你在代码中看到类似的东西时:
myObject.Foo();
天生的直觉是Foo()在myObject的类或myObject的类的父类上定义的方法.
使用Extension方法,这是不正确的.几乎任何类型的方法都可以定义几乎任何类型(你可以在System.Object上定义一个扩展方法,虽然这是一个坏主意......).这确实增加了代码的维护成本,因为它降低了可发现性.
每当您添加非显而易见的代码,甚至降低实现的"显而易见性"时,就长期可维护性而言都会涉及成本.
过度使用扩展方法是不好的,原因与过度使用重载运算符的原因相同.让我解释.
我们先来看看运算符重载示例.当你看到代码时:
var result = myFoo + myBar;
你想希望,myFoo并myBar为数字类型,以及operator +正在执行加法.这是合乎逻辑的,直观的,易于理解的.但是一旦操作员超载进入图片,您就无法确定myFoo + myBar实际在做什么 - +运算符可能会被重载以表示任何内容.您不仅可以阅读代码并找出正在发生的事情,而无需阅读表达式中涉及的所有类型的代码.现在,operator +已经是重载类型,如String或DateTime-但是,有一个直观的解释一下另外在这些情况下指.更重要的是,在这些常见情况下,它为代码增加了许多表达能力.因此值得潜在的混淆.
那么所有这些与扩展方法有什么关系呢？好吧,扩展方法引入了类似的情况.没有扩展方法,当你看到:
var result = myFoo.DoSomething();
你可以假设它DoSomething()是一个方法myFoo或其中一个基类.这很简单,易于理解,甚至直观.但随着扩展方法,DoSomething() 可在任何地方定义 -更糟的是,定义取决于设定的using代码文件,报表和带来潜在的许多类混进去,其中任何一个都可能拥有的实现DoSomething().
现在不要误会我的意思.运算符重载和扩展方法都是有用且强大的语言功能.但请记住 - 强大的力量带来了巨大的责任.您应该在提高实现的清晰度或功能时使用这些功能.如果你不加选择地开始使用它们,它们会给你想要创建的东西增加混乱,复杂性和可能的缺陷.