扩展方法是C＃的面向对象特性吗？
扩展方法是否遵循C＃中面向对象的范例？
使用扩展方法是一种好习惯吗？
在软件开发生命周期中，我们应该如何在设计阶段考虑这个问题？
扩展方法不是面向对象的语言function。 （比较：类，inheritance，多态等）。
与每种语言function一样，它应该在适当的地方使用，并且应该用于它的设计目的。 关于何时以及如何使用Extension方法已经有很多问题。
- 在.Net中使用扩展方法的最佳实践是什么？
- 扩展方法的可能过度使用
- 扩展方法是否隐藏依赖关系？
埃里克·利珀特（Eric Lippert）在博客中发表了这篇文章 ，我怀疑自己做得比引用他要好得多：
所以，是的，经常听到的批评“扩展方法不是面向对象”是完全正确的，但也是无关紧要的。 扩展方法当然不是面向对象的。 他们将操纵数据的代码放在远离声明数据的代码的位置，它们不能破坏封装并与它们看起来是方法的对象的私有状态对话，它们不能很好地inheritance，等等。 它们是一种方便的面向对象服装的程序编程。
它们也非常方便，使LINQ成为可能，这就是我们添加它们的原因。 事实上，他们不符合某种forms的面向对象语言的哲学理想并不是这个决定的重要因素。
但是，我会补充一点，它们除了LINQ之外还有用 – 因为它们在 LINQ中很有用 。 能够表达适用于特定接口的任意实现的算法（例如LINQ to Obhects中的IEnumerable ）真的很棒。 这些算法通常没有超出您正在处理的接口的任何上下文，因此它们通常是自然静态的。
如果你接受你有一些静态实用方法，你会使用哪种语法？
// Traditional CollectionUtils.Sort(collection); // Extension methods collection.Sort();
在我看来，后者更具可读性。 它简明扼要地表达了你想要做的事情。 它并不清楚你想怎么做，但这在大多数时候都不那么重要 – 当然，当你调试那条特定的线时更重要。
它有两个部分。
-
当我们使用它时它是OO吗？ 它会让你觉得你在特定类型上调用方法
-
它是基于如何编译/构建的OO
是; 编译代码有一个静态方法，使用调用扩展方法的对象
扩展方法只是一种语言function。 他们在对象实例上工作，是非常好的工具。
将它们视为扩展类function的不同方式。 您可以向类添加新function：
-
通过添加部分类声明。 然后，该类立即获得一堆新的方法和属性。
-
通过在扩展方法持有者类中包含命名空间。 然后，该类再次获得一堆新方法。
而是组织/语言function。 不以任何方式破坏面向对象的概念。 正如C / C ++中的头/源文件划分与面向对象无关，只是语言/框架function。
这取决于。 扩展方法只是一种工具。 如果使用得当，它们非常有用。 但是如果你使用它们太多，它可能会掩盖你的代码。
扩展方法只是与特定类或类层次结构一起使用的静态方法。 Python是OO但有模块，Ruby有mixins。 我认为它更像是一种语言function。 我很确定它仍然是OO友好的