改善C#程序的建议2:C#中dynamic的正确用法

原文:改善C#程序的建议2:C#中dynamic的正确用法

dynamic是FrameWork4.0的新特性。dynamic的出现让C#具有了弱语言类型的特性。编译器在编译的时候不再对类型进行检查,编译期默认dynamic对象支持你想要的任何特性。比如,即使你对GetDynamicObject方法返回的对象一无所知,你也可以像如下那样进行代码的调用,编译器不会报错:

 


dynamic dynamicObject = GetDynamicObject();
Console.WriteLine(dynamicObject.Name);
Console.WriteLine(dynamicObject.SampleMethod());

说到正确用法,那么首先应该指出一个错误用法:

常有人会拿var这个关键字来和dynamic做比较。实际上,var和dynamic完全是两个概念,根本不应该放在一起做比较。var实际上是编译期抛给我们的“语法糖”,一旦被编译,编译期会自动匹配var 变量的实际类型,并用实际类型来替换该变量的申明,这看上去就好像我们在编码的时候是用实际类型进行申明的。而dynamic被编译后,实际是一个object类型,只不过编译器会对dynamic类型进行特殊处理,让它在编译期间不进行任何的类型检查,而是将类型检查放到了运行期。

这从visual studio的编辑器窗口就能看出来。以var声明的变量,支持“智能感知”,因为visual studion能推断出var类型的实际类型,而以dynamic声明的变量却不支持“智能感知”,因为编译器对其运行期的类型一无所知。对dynamic变量使用“智能感知”,会提示“此操作将在运行时解析”。

关于dynamic变量是一个object变量这一点,可以通过IL代码得到验证,这里不再贴出IL代码。当然,编译器也对dynamic声明进行了处理,以区别直接object变量。

dynamic是做为简化互操作性而被MSDN中大肆渲染,我感觉正是基于这一点,才被部分开发人员误解:因为很多开发人员不会接触COM+、OFFICE二次开发之类的编码,所以急需要一个dynamic的应用理由。那么,在日常开发中,我认为dynamic很有价值的一点是:

dynamic可以简化反射

以前我们这样使用反射:

 


public class DynamicSample
{
public string Name { get; set; }

public int Add(int a, int b)
{
return a + b;
}
}
DynamicSample dynamicSample = new DynamicSample(); //create instance为了简化演示,我没有使用反射
var addMethod = typeof(DynamicSample).GetMethod("Add");
int re = (int)addMethod.Invoke(dynamicSample, new object[] { 1, 2 });

现在,我们有了简化的写法:


dynamic dynamicSample2 = new DynamicSample();
int re2 = dynamicSample2.Add(1, 2);

我们可能会对这样的简化不以为然,毕竟看起来代码并没有减少多少,但是,如果考虑到效率兼优美两个特性,那么dynamic的优势就显现出来了。编译器对dynamic进行了优化,比没有经过缓存的反射效率快了很多。如果非要比较,可以将上面两者的代码(调用Add方法部分)运行1000000就可以得出结论。

时间: 2024-07-31 10:41:48

改善C#程序的建议2:C#中dynamic的正确用法的相关文章

改善C#程序的建议6:在线程同步中使用信号量

原文:改善C#程序的建议6:在线程同步中使用信号量 所谓线程同步,就是多个线程之间在某个对象上执行等待(也可理解为锁定该对象),直到该对象被解除锁定.C#中对象的类型分为引用类型和值类型.CLR在这两种类型上的等待是不一样的.我们可以简单的理解为在CLR中,值类型是不能被锁定的,也即:不能在一个值类型对象上执行等待.而在引用类型上的等待机制,则分为两类:锁定和信号同步. 锁定,使用关键字lock和类型Monitor.两者没有实质区别,前者其实是后者的语法糖.这是最常用的同步技术: 本建议我们讨论

改善C#程序的建议7:正确停止线程

原文:改善C#程序的建议7:正确停止线程 开发者总尝试对自己的代码有更多的控制."让那个还在工作的线程马上停止下来"就是诸多要求中的一种.然而事与愿违,这里面至少存在两个问题: 第一个问题是:正如线程不能立即启动一样,线程也并不能说停就停.无论采用何种方式通知工作线程需要停止,工作线程都会忙完手头最紧要的活,然后在它觉得合适的时候退出.以最传统的Thread.Abort方法为例,如果线程当前正在执行的是一段非托管代码,那么CLR就不会抛出ThreadAbortException,只有当

改善C#程序的建议8:避免锁定不恰当的同步对象

原文:改善C#程序的建议8:避免锁定不恰当的同步对象 在C#中让线程同步的另一种编码方式就是使用线程锁.所谓线程锁,就是锁住一个资源,使得应用程序只能在此刻有一个线程访问该资源.可以用下面这句不是那么贴切的话来理解线程锁的作用:锁,就是让多线程变成单线程.在C#中,可以将被锁定的资源理解成new出来的普通对象. 既然需要锁定的资源就是一个C#中的对象,我们就该仔细思考,到底什么样的对象能够成为一个锁对象(也叫同步对象)?在选择同步对象的时候,应当始终注意以下几点:     q同步对象在需要同步

改善C#程序的建议4:C#中标准Dispose模式的实现

原文:改善C#程序的建议4:C#中标准Dispose模式的实现 需要明确一下C#程序(或者说.NET)中的资源.简单的说来,C#中的每一个类型都代表一种资源,而资源又分为两类: 托管资源:由CLR管理分配和释放的资源,即由CLR里new出来的对象: 非托管资源:不受CLR管理的对象,windows内核对象,如文件.数据库连接.套接字.COM对象等: 毫无例外地,如果我们的类型使用到了非托管资源,或者需要显式释放的托管资源,那么,就需要让类型继承接口IDisposable.这相当于是告诉调用者,该

改善C#程序的建议1:非用ICloneable不可的理由

原文:改善C#程序的建议1:非用ICloneable不可的理由 好吧,我承认,这是一个反标题,实际的情况是:我找不到一个非用ICloneable不可的理由.事实上,接口ICloneable还会带来误解,因为它只有一个Clone方法. 我们都知道,对象的拷贝分为:浅拷贝和深拷贝.ICloneable仅有一个Clone方法使我们无法从命名的角度去区分到底是哪个拷贝. 浅拷贝:将对象的字段复制到副本(新的对象)中,同时将字段的值也赋值过去,但是引用类型字段只复制引用,而不是引用类型本身.这意味着,源对

改善C#程序的建议5:引用类型赋值为null与加速垃圾回收

原文:改善C#程序的建议5:引用类型赋值为null与加速垃圾回收 在标准的Dispose模式中(见前一篇博客"C#中标准Dispose模式的实现"),提到了需要及时释放资源,却并没有进一步细说让引用等于null是否有必要. 有一些人认为等于null可以帮助垃圾回收机制早点发现并标识对象是垃圾.其他人则认为这没有任何帮助.是否赋值为null的问题首先在方法的内部被人提起.现在,为了更好的阐述提出的问题,我们来撰写一个Winform窗体应用程序.如下: privatevoid button

编写高质量代码改善C#程序的建议:泛型集合、选择集合和集合的安全

前言 软件开发过程中,不可避免会用到集合,C#中的集合表现为数组和若干集合类.不管是数组还是集合类,它们都有各自的优缺点.如何使用好集合是我们在开发过程中必须掌握的技巧.不要小看这些技巧,一旦在开发中使用了错误的集合或针对集合的方法,应用程序将会背离你的预想而运行. 本文已更新至http://www.cnblogs.com/aehyok/p/3624579.html .本文主要学习记录以下内容: 建议20.使用泛型集合来替代非泛型集合 建议21.选择正确的集合 建议22.确保集合的线性安全 建议

编写高质量代码改善C#程序的157个建议[优先考虑泛型、避免在泛型中声明静态成员、为泛型参数设定约束]

原文:编写高质量代码改善C#程序的157个建议[优先考虑泛型.避免在泛型中声明静态成员.为泛型参数设定约束] 前言 泛型并不是C#语言一开始就带有的特性,而是在FCL2.0之后实现的新功能.基于泛型,我们得以将类型参数化,以便更大范围地进行代码复用.同时,它减少了泛型类及泛型方法中的转型,确保了类型安全.委托本身是一种引用类型,它保存的也是托管堆中对象的引用,只不过这个引用比较特殊,它是对方法的引用.事件本身也是委托,它是委托组,C#中提供了关键字event来对事件进行特别区分.一旦我们开始编写

编写高质量代码改善C#程序的157个建议[4-9]

原文:编写高质量代码改善C#程序的157个建议[4-9] 前言 本文首先亦同步到http://www.cnblogs.com/aehyok/p/3624579.html.本文主要来学习记录一下内容: 建议4.TryParse比Parse好 建议5.使用int?来确保值类型也可以为null 建议6.区别readonly和const的使用方法 建议7.将0值设为枚举的默认值 建议8.避免给枚举类型的元素提供显式的值 建议9.习惯重载运算符 建议4.TryParse比Parse好 如果注意观察,除st