扩展方法的本质是什么,详细见此文 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# 扩展方法奇思妙用。