【讨论】早有扩展函数了，那么过多的静态函数是否提倡？
如题所示。我常常可以将许多常用，频繁的东西封装成一个扩展函数。

那么，我想知道，过多的静态函数会不会对系统带来什么影响？

对于这种行为（做法），应当是提倡，还是避免这种语法糖？

当然，我仅是站在讨论，求职的视角，欢迎拍砖，言论自由，但请尊重任何人。

------解决方案--------------------
扩展方法和静态函数压根儿不是一个层次的东西...你的论题都站不住脚...

再说扩展方法只是一种打补丁的手段...
------解决方案--------------------
打补丁通常都是无奈之举，你没见过有人穿全是补丁片缝成的衣服吧...

扩展方法破环了已有源代码的结构和稳定，并可能带来不可预见的问题...当然不会被提倡...

官方解释就是MSDN的扩展方法通用准则...

探讨

通常，建议您只在不得已的情况下才实现扩展方法，并谨慎地实现。只要有可能，必须扩展现有类型的客户端代码都应该通过创建从现有类型派生的新类型来达到这一目的。

在使用扩展方法来扩展您无法更改其源代码的类型时，您需要承受该类型实现中的更改会导致扩展方法失效的风险。

如果您确实为给定类型实现了扩展方法，请记住以下两点：

1.如果扩展方法与该类型中定义的方法具有相同的签名，则扩展方法永远不会被调用。

2.扩展方法被在命名空间级别放入范围中。例如，如果您在同一个名为 Extensions 的命名空间中具有多个包含扩展方法的静态类，则这些扩展方法将全部由 using Extensions; 指令放入范围中。

类库的实施者不应使用扩展方法来避免创建程序集的新版本。如果您要向库中添加重要的新功能，并且您拥有源代码，则应该遵循标准 .NET Framework 程序集版本控制准则。

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

或许是不是可以理解成对接口使用扩展方法？
------解决方案--------------------

探讨

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

或许是不是可以理解成对接口使用扩展方法？

------解决方案--------------------

探讨

扩展方法是可以继承的，假如扩展了一个基类，所有扩展方法在派生类中也可以使用。
但是，和所有扩展方法一样，这里有优先问题，如果在继承链中出现了一个相同的签名(方法名)，那么就会优先于扩展方法，也就是会将现有的扩展方法覆盖，而且不会发出警告。

------解决方案--------------------

探讨

比如我可以将我所有的扩展方法“规范化”。

public static void __DoSomething(){}

或

public static void DoSomething__(){}

当然了，这个一个比较“恶俗”的解决办法。

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

------解决方案--------------------
[讨论]关于.NET3.5中新增的扩展方法功能
------解决方案--------------------
过犹不及！有些东西是替代不了的，所以对于新事物，我提倡，但是不能一味排斥旧事物。就像网络教程无论如何也替代不了书本一样！