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

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

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就可以得出结论。
Creative Commons License本文基于 Creative Commons Attribution 2.5 China Mainland License发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 http://www.cnblogs.com/luminji(包含链接)。如您有任何疑问或者授权方面的协商,请给我留言。
目录
相关文章
|
API 图形学
【Unity细节】RigidBody中Dynamic和Kinematic的区别
【Unity细节】RigidBody中Dynamic和Kinematic的区别
117 0
|
BI C#
一起谈.NET技术,C#特性Attribute的实际应用之:代码统计分析
  日常工作中,需要为程序集提供统计分析:   1:程序集方法数;   2:开发人员数目及各自所开发或REVIEW的方法数;   3:测试中,被标注有BUG的数目;   4:直接查看方法的IL代码;   鉴于以上统计的需要,特开发本EXE。
1156 0
|
BI C#
C#特性Attribute的“.NET研究”实际应用之:代码统计分析
  日常工作中,需要为程序集提供统计分析:   1:程序集方法数;   2:开发人员数目及各自所开发或REVIEW的方法数;   3:测试中,被标注有BUG的数目;   4:直接查看方法的IL代码;   鉴于以上统计的需要,特开发本EXE。
801 0
|
XML Java 数据格式
Attribute(特性),怎么用才更好?
前几年:   2008年的某一天,我坐火车去北京。硬卧上铺,一晚上就到北京了。爬到上铺之后发现,旁边上铺有一老兄抱着一个笔记本,一开始还以为是看电影呢,仔细一看才发现——老天呀,居然在写代码!     这老兄也太工作狂了,当时可是晚上九点多了呀。
1018 0
|
程序员 C#
艾伟:.NET,你忘记了么?(八)-- 从dynamic到特性误用
1. 摘要 每个程序员都想写出漂亮的代码,但是什么是漂亮,这个我想每个人都有着自己的看法。那么我就说几种典型的想法: A. 写出别人看不懂的代码,让别人觉得很高深。 B. 写出简短的代码 C. 用最新的语言特性写出代码 这个我不发表评论,毕竟每个人有着自己的观点,我也不能证明自己的就是对的。
988 0
一起谈.NET技术,改善代码设计 —— 优化物件之间的特性(Moving Features Between Objects)
  系列博客       1. 改善代码设计 —— 优化函数的构成(Composing Methods)       2. 改善代码设计 —— 优化物件之间的特性(Moving Features Between Objects)       3.
685 0
改善代码设计 —— “.NET研究”优化物件之间的特性(Moving Features Between Objects)
  系列博客       1. 改善代码设计 —— 优化函数的构成(Composing Methods)       2. 改善代码设计 —— 优化物件之间的特性(Moving Features Between Objects)       3.
923 0
|
JavaScript 前端开发 Java
使用 ES6 编写更好的 JavaScript Part II:深入探究 [类]
本文讲的是使用 ES6 编写更好的 JavaScript Part II:深入探究 [类],从功能上来讲,class 声明就是一个语法糖,它只是比我们之前一直使用的基于原型的行为委托功能更强大一点。本文将从新语法与原型的关系入手,仔细研究 ES2015 的 class 关键字。文中将提及以下内容:
1439 0