【讨论】早有扩展函数了，那么过多的静态函数是否提倡？

Question

如题所示。我常常可以将许多常用，频繁的东西封装成一个扩展函数。那么，我想知道，过多的静态函数会不会对系统带来什么影响？对于这种行为（做法），应当是提倡，还是避免这种语法糖？当然，我仅是站在讨论，求职的视角，欢迎拍砖，言论自由，但请尊重任何人。

Answer 1

当然需要。比如：
Thread.Sleep
这种函数你说能扩展到谁身上去？更不要说一些无参的静态函数了。

Answer 2

1.msdn:
建议您只在不得已的情况下才实现扩展方法，并谨慎地实现。只要有可能，必须扩展现有类型的客户端代码都应该通过创建从现有类型派生的新类型来达到这一目的。
2.
扩展方法无法帮助我们建立一个清楚的版本控制机制，因为一旦在被扩展的类型中添加了一个匹配的签名，就会将现有的扩展方法覆盖，而且不会发出警告。如果对被扩展的类的源代码没有控制权，这个问题还会变得更加突出。
另外一个问题在于，虽然Visual Studio的“智能感知”功能支持扩展方法，但假如只是查看调用代码(也就是调用了扩展方法的代码)，是不易看出一个方法是不是扩展方法的。总而言之，要慎用扩展方法。---- 《C#本质论》

Answer 3

打补丁通常都是无奈之举，你没见过有人穿全是补丁片缝成的衣服吧...扩展方法破环了已有源代码的结构和稳定，并可能带来不可预见的问题...当然不会被提倡...官方解释就是MSDN的扩展方法通用准则...

Answer 4

既然不提倡扩展方法，那为什么mvc里却把那些html方法都改成了扩展方法，还有linq也大量用扩展方法，虽然集合类出现的比linq早，不过我觉得即使同时出现，也会设计为扩展方法吧或许是不是可以理解成对接口使用扩展方法？

Answer 5

扯到继承链多少有些牵强，sealed类就该滥用扩展方法吗？问题还是破环结构和稳定性，扩展方法通用准则已经说明了...无法更改源代码时(如CLR类库或第三方不能修改的类库)，你使用了一个扩展方法带来一时便利...如果该类库升级后恰好新增了一个同样签名的方法，你的扩展方法就被无声无息地取代了...假如不幸新方法的执行结果和你的扩展方法不同，那么你的程序就会出现莫名其妙的问题而不会有任何警告提示...假如你这些扩展方法是某个应用框架的一部分，出现这问题你的用户(他们也是程序员)将会抓狂...假如团队有多个小组分别编写自己的扩展方法，那更是版本控制的灾难...

Answer 6

扩展方法是可以继承的，假如扩展了一个基类，所有扩展方法在派生类中也可以使用。
但是，和所有扩展方法一样，这里有优先问题，如果在继承链中出现了一个相同的签名(方法名)，那么就会优先于扩展方法，也就是会将现有的扩展方法覆盖，而且不会发出警告。代码如下：
主函数：Program.cs
 public class PdaItem
    {
        public void Write()
        {
            Console.WriteLine("PdaItem");
        }
    }    class Appointment : PdaItem
    {    }    class Contact : PdaItem
    {
        public void Extnesion()
        {
            Console.WriteLine("Contact");
        }
    }    class Program
    {
        static void Main(string[] args)
        {
            Appointment a = new Appointment();
            a.Extnesion();  //结果：Extnesion            //这个继承链中有相同的签名
            Contact c = new Contact();
            c.Extnesion();  //結果：Contact            Console.ReadLine();
        }
    }扩展方法类：MyExtnesion.cs
    public static class MyExtnesion
    {
        public static void Extnesion(this PdaItem p)
        {
            Console.WriteLine("Extnesion");
        }
    }这样会导致继承的破坏  

Answer 7

这不是破坏继承链，这是继承链暗杀了扩展方法...即MSDN中的“该类型实现中的更改会导致扩展方法失效的风险”...

Answer 8

诸位精彩之论，鄙人无比感谢。既然破坏了稳定性，继承链等诸多问题，那么解决办法也是有的（针对我个人而言）。比如我可以将我所有的扩展方法“规范化”。public static void __DoSomething(){}或public static void DoSomething__(){}当然了，这个一个比较“恶俗”的解决办法。

Answer 9

别这么直接比如我一个很简单的例子，我有一个扩展方法：public static int? ToInt32<T>(this T val);我本意是希望在处理数据的时候可以便利 的使用这个方法，可惜，我常常在一个普通的类实例中，看到这个函数，这是相当的“不爽”。

Answer 10

1.msdn:
建议您只在不得已的情况下才实现扩展方法，并谨慎地实现。只要有可能，必须扩展现有类型的客户端代码都应该通过创建从现有类型派生的新类型来达到这一目的。
2.
扩展方法无法帮助我们建立一个清楚的版本控制机制，因为一旦在被扩展的类型中添加了一个匹配的签名，就会将现有的扩展方法覆盖，而且不会发出警告。如果对被扩展的类的源代码没有控制权，这个问题还会变得更加突出。
另外一个问题在于，虽然Visual Studio的“智能感知”功能支持扩展方法，但假如只是查看调用代码(也就是调用了扩展方法的代码)，是不易看出一个方法是不是扩展方法的。总而言之，要慎用扩展方法。

Answer 11

[讨论]关于.NET3.5中新增的扩展方法功能

Answer 12

扩展方法貌似在.NET Framework 3.0之后才支持啊~~你自己的静态函数，里面也是独立型的吧，相互没有太多关系，那么是没关系的，因为系统对对资源调度的基本单位是线程，并不是函数

Answer 13

学习学习 中国c#讨论群9134476 欢迎c# 爱好者加入 加入时请备注 csdn论坛

Answer 14

通用准则通常，建议您只在不得已的情况下才实现扩展方法，并谨慎地实现。只要有可能，必须扩展现有类型的客户端代码都应该通过创建从现有类型派生的新类型来达到这一目的。在使用扩展方法来扩展您无法更改其源代码的类型时，您需要承受该类型实现中的更改会导致扩展方法失效的风险。 如果您确实为给定类型实现了扩展方法，请记住以下两点： 1.如果扩展方法与该类型中定义的方法具有相同的签名，则扩展方法永远不会被调用。 2.扩展方法被在命名空间级别放入范围中。例如，如果您在同一个名为 Extensions 的命名空间中具有多个包含扩展方法的静态类，则这些扩展方法将全部由 using Extensions; 指令放入范围中。 类库的实施者不应使用扩展方法来避免创建程序集的新版本。如果您要向库中添加重要的新功能，并且您拥有源代码，则应该遵循标准 .NET Framework 程序集版本控制准则。
——MSDN

Answer 15

当然需要。比如：
Thread.Sleep
这种函数你说能扩展到谁身上去？更不要说一些无参的静态函数了。