扩展方法的本质是什么,详细见此文 C#扩展方法，爱你在心口难开

重点如下:
扩展方法使您能够向现有类型“添加”方法，而无需创建新的派生类型、重新编译或以其他方式修改原始类型。扩展方法是一种特殊的静态方法，但可以像扩展类型上的实例方法一样进行调用。对于用 C# 和 Visual Basic 编写的客户端代码，调用扩展方法与调用在类型中实际定义的方法之间没有明显的差异。

虽然扩展方法通过实例方法语法进行调用的，但是他们却被定义为静态方法。从定义中我们可以看到，它们的第一个参数指定该方法作用于哪个类型，并且该参数以 this 修饰符为前缀。

扩展方法与其扩展的类之间并没有什么本质的联系，只是编译器跟我们玩的把戏罢了，最终编译器还是将扩展方法转化成静态类的静态方法调用，所以扩展方法不能访问相应类的私有字段和私有方法；至于为什么使用静态类的静态方法，我考虑可能是这样效率相对较高，同时扩展方法作为其他类的扩展，本身类的实例化没有什么意义.

综上进行总结
扩展方法不改变被扩展类的代码，不用重新编译、修改、派生被扩展类
扩展方法不能访问被扩展类的私有成员
扩展方法会被被扩展类的同名方法覆盖，所以实现扩展方法我们需要承担随时被覆盖的风险
扩展方法看似实现了面向对象中扩展对修改说不的特性，但是也违背了面向对象的继承原则，被扩展类的派生类是不能继承扩展扩展方法的，从而又违背了面向对象的多态性。
在我们稳定的引用同一个版本的类库，但是我们没有该类库的源代码，那么我们可以使用扩展方法；但是从项目的可扩展、可维护和版本控制方面来说，都不建议使用扩展方法进行类的扩展。

************************************************************************************

那么现在谈谈我对扩展方法的理解: 

我认为扩展方法是对现实世界一种常见范式的模拟，这种方式违背了面向对象的一些基本原则，但是这也是C#走向动态语言的一大步。

本质上来说： 扩展方法是破坏原来的层次结构，通过网络结构加快业务逻辑处理.

举例来说：

public class 手电筒

{

   public void 照射()

}

村里的老刘是个电子爱好者，他从商场购买的手电筒只能照射用，他买回来改装后，这手电筒还能做喇叭用，他将改装的手电筒在村里卖。

public static class 改装室  //扩展方法实现

{

    public static void 喇叭叫(this 手电筒 手电筒1)

   { }

}

public class 新手电筒: 手电筒  //继承实现

{

   public void 喇叭叫(){}

}

村里不少人都买了，他们拿着手电筒，知道这个手电筒不仅能照射,还能喇叭叫

手电筒1.照射()

手电筒1.喇叭叫()

这种方式扩展和继承都能实现，但是在使用时，继承方式引入了新的变量体，可以认为继承会使得调用时，整个事务逻辑更复杂。

当我们确定先前的手电筒被完全密封不可见时，继承方式更适合，而当手电筒一直可见时，使用扩展方法可以减少一个新类的概念体。

对于.NET中一些常见类，String,Dictionary,List,Random

我们可能都会对他们进行一些特殊的调用，一般情况下，

我们可能会用继承：StringME,DictionaryME,ListME,RandomME

也可能直接调用对象: ME.str(String sone),ME.dic(Dictionary<>  done),ME.str(List<> lone)

上面的两种方式都意味着你不仅需要知道String,Dictionary,List,Random,还需要知道新的StringME,DictionaryME,ListME,RandomME或者ME.str(String sone),ME.dic(Dictionary<>  done),ME.str(List<> lone).

从事务逻辑说: 每次处理时需要处理的信息量已经增大一倍。

而如果我们使用扩展方法后，通过String,Dictionary,List,Random的实例对象,即可调用。这降低了处理一个问题时所需要汇聚的信息量，所以回归到整个问题的本质，扩展方式的优势使得我们处理一些问题时能消耗更少的注意力。但是扩展方法可能和原来的方法以及继承类有冲突，存在调用的安全性问题，所以大项目一般不会采用。而小项目则可以快速开发应用。

更多的应用见c# 扩展方法奇思妙用。