如果所有静态方法都是扩展方法默认值，会发生什么情况？
静态方法总是应该用括号封装参数。因此，在打字时使用扩展方法要容易得多。这就是我喜欢扩展方法的原因之一。
我不确定什么时候使用扩展或静态方法更好。我在想如果所有静态方法都是默认扩展方法会发生什么。扩展方法的输入很容易，但是这个想法还有什么其他优点或缺点呢？
编辑
在我意识到将所有静态方法转换为扩展方法并不是一个好主意之后。 例如：不带参数或带不同类型参数的方法。我们也可以改变问题。如果静态方法可由扩展方法默认使用，而静态方法采用其自己类型的参数，则会发生什么情况。
Static methods always should to encapsulate arguments by parenthesis . So it is much more easy to use extension methods while typing. That is one of the reason why i like extension methods.
I am not sure when time it is better to use extension or static methods. And i am thinking that what would be happen if all static methods would be default extension methods. Would be easy typing for extension methods but what other advantage or disadvantage of this idea ?
Edit
After i realize that not good idea to make all static methods to extension methods.
For example : Methods that does not take argument or takes argument of different type. Also we can change the question. What would be happen if static methods would be usable by extension methods default for static methods which takes argument of its own type.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
虽然许多静态方法（尤其是值类型和字符串）对自身实例进行操作，但也有一些静态方法的扩展语法没有意义，因为它们不对自己的类型进行操作。例如，ConfigurationManager 是一个“纯静态”的，没有实例组件；尝试将任何此类调用构造为扩展方法是没有意义的。
我还遇到过这样的情况：我引用了具有相似签名的不同实用程序库中的重复扩展方法；引用包含该方法的静态类是解决此类歧义而无需进行大规模重构的唯一方法。
最后，适度的扩展方法是很好的。然而，我目前的项目可能变得有点太“流畅”了；我们有大多数 String 静态的扩展方法包装器，例如 IsNullOrEmpty() 和 Format()，以及每个值类型的解析扩展方法（int.Parse、byte.Parse、DateTime.Parse 等的包装器）和变体（如TryParses、IsNullOrBlank、IsNotNullOrEmpty等）。您可以对字符串实例执行很多操作，在我们的项目中，大多数操作都可以附加到该实例的末尾（甚至是文字）。当您达到该时间段时，这会大大减慢 VS 的速度，并增加其内存占用量（以及 ReSharper 的内存占用量，它提供 IntelliSense 扩展和使用/参考建议）。
While many static methods, especially for value types and strings, operate on instances of themselves, there are static methods for which the extension syntax would not make sense because they do not act on their own type. ConfigurationManager, for example, is a "pure static" that has no instance component; it makes no sense to attempt to structure any such call as an extension method.
I have also gotten into situations where I had references to duplicate extension methods in different utility libraries with similar signatures; referring to the static class containing the method is the only way to resolve such ambiguities without a big refactor.
Lastly, extension methods are great in moderation. However, my current project has become perhaps a little too "fluent"; we have extension method wrappers for most of the String statics such as IsNullOrEmpty() and Format(), as well as parsing extension methods for every value type (wrappers for int.Parse, byte.Parse, DateTime.Parse, etc) and variations (such as TryParses, IsNullOrBlank, IsNotNullOrEmpty, etc.). There are a LOT of things you can do to a string instance, and in our project, most of them can be tacked on to the end of that instance (even a literal). That slows VS down considerably when you hit that period, and increases its memory footprint (and that of ReSharper, which provides IntelliSense extensions and using/reference suggestions).
扩展方法适用于对象的实例，而静态方法适用于类型本身。静态方法提供工厂或实用程序功能，而扩展方法则为特定对象添加语义值。
例如，采用
Process.Start(ProcessStartInfo)< /a>：它是在Process类型上调用的静态方法。它作为一个扩展方法会很奇怪，因为你必须在实际调用它之前创建一个 Process 实例（注意：是的，有一个Process.Start对实例进行操作的方法，但假定Process对象已填充其启动信息）。如果您想要扩展类型实例的功能并且无法更改原始源，则扩展方法很有意义。如果您希望拥有与您的类型密切相关的静态实用函数，则静态方法很有意义。它们各有各的用途。
Extension methods apply to instances of objects while static methods apply to types themselves. Static methods provide factory or utility functionality while extension methods add semantic value to specific objects.
For example, take
Process.Start(ProcessStartInfo): it is a static method that gets called on theProcesstype. It would be weird for it to be an extension method since you'd have to create an instance ofProcessbefore actually calling it (note: yes there is aProcess.Startmethod that operates on instances, but it is assumed that theProcessobject already has its start information populated).If you want to extend the functionality of instances of a type and you can't change the original source, extension methods make sense. If you want to have static utility functions that are closely related to your type, static methods make sense. They each have their uses.
所有扩展方法都是静态方法。不同之处在于，在扩展方法中，方法签名中的第一个参数必须包含
this关键字，以指示该方法是扩展的类型...从某种意义上说，该方法对于定义它的类型来说是静态的，但是，（正如克里斯在他的回答中提到的那样），它们对于第一个参数中定义的类型来说是非静态的（实例）...如果所有静态方法都是默认情况下扩展名，您会如何处理没有 thgis keywpord 的旧代码？编译器如何知道将扩展方法“附加”到什么类型？
All extension methods are static methods.. The difference is that in an extension method, the first parameter in the method's signature must include the
thiskeyword to indicate what type the method is an extension for... In a sense, the method is static to the type it is defined in, but, (as Chris mentions in his answer), they are non-static (instance) to the type defined in the first parameter...If all static methods were extension by default, what would you do about old code that doesn't have the thgis keywpord? and how would the compiler know what type to 'attach' the extension method to?
一方面，当涉及到 int.Parse(string)、double.Parse(string) 等时，会存在很大的歧义，它们都希望同时成为字符串的扩展方法。关于该方法是否应该在逻辑上扩展所操作类型的功能，而不是在逻辑上与定义静态方法的类型相关联，这是一个重要的设计决策。
For one thing, there would be massive ambiguity when it comes to int.Parse(string), double.Parse(string), etc. all wanting to become extension methods on string at the same time. It's an important design decision as to whether the method should logically be extending the functionality of the operated-upon type, rather than being logically associated with the type defining the static method.