从.NET中委托写法的演变谈开去（上）：委托与匿名方法
2009-08-05 12:50 by 老赵, 18539 visits在《关于最近面试的一点感想》一文中，Michael同学谈到他在面试时询问对方“delegate在.net framework1.1,2.0,3.5各可以怎么写”这个问题。于是乎，有朋友回复道“请问楼主，茴香豆的茴有几种写法”，“当代孔乙己”，独乐，众乐。看了所有的评论，除了某些朋友认为“的确不该不知道这个问题”之外，似乎没有什么人在明确支持楼主。
不过我支持，为什么？因为我也提过出这样的问题。
这样，我们暂且不提应聘“高级开发人员”的人，在“自称熟悉各版本.NET框架”的前提下，是否应该知道这个答案。我们也暂且不提Michael同学提问的“目的”是什么。老赵就先单独针对这个问题进行解释，然后谈谈自己为什么会提出这个问题吧。
可能有一件事情需要说在前面，那就是：委托本身其实从来没有改变过，改变的一直都是委托的“写法”。因此更确切地说，改变的只是“编译器”。而本文所有内容都用C#来实现，其实谈得也都是C#编译器本身——但是其实VB.NET也有变化啊。再由于.NET版本和C#版本的关系也是非常密切的，因此全文就使用.NET版本进行指代了。
.NET 1.x中委托的写法
委托，如果不追究细节，从表面上来看我们可以将其通俗地理解为一个安全的“函数指针”。当然，这个函数指针其实也是一个对象，有自己的成员，也会封装了被调用方的上下文等等。至于委托的定义和使用方式，则是这样的：
public delegate int SomeDelegate(string arg1, bool arg2); public static int SomeMethod(string arg1, bool arg2) { return 0; } public class SomeClass { public int SomeMethod(string a1, bool a2) { return 0; } public event SomeDelegate SomeEvent; } static void Main(string[] args) { SomeClass someClass = new SomeClass(); SomeDelegate someDelegate = new SomeDelegate(someClass.SomeMethod); someClass.SomeEvent += new SomeDelegate(SomeMethod); }
可见，在.NET 1.x中需要使用new DelegateType(...)的方式来创建一个委托对象。不过，作为委托对象内部的方法它既可以是实例方法，也可以是静态方法。此外，方法只需要匹配委托类型的签名和返回值即可，方法参数的名称不会成为约束。
嗯，就是这么简单。
匿名方法及回调简化
.NET 2.0中的委托引入了范型，且写法略有简化：
public delegate TResult MyFunc<T1, T2, TResult>(T1 a1, T2 a2); public static int SomeMethod(string a1, bool a2) { return 0; } static void Main(string[] args) { MyFunc<string, bool, int> myFunc = SomeMethod; }
在.NET 2.0中，new DelegateType已经可以省略，开发人员可以直接将方法赋值给一个委托对象的引用。当然，这个改进不值一提，C# 2.0中委托写法的关键在于引入了“匿名方法”：
public static void TestRequest(string url) { WebRequest request = HttpWebRequest.Create(url); request.BeginGetResponse(delegate(IAsyncResult ar) { using (WebResponse response = request.EndGetResponse(ar)) { Console.WriteLine("{0}: {1}", url, response.ContentLength); } }, null); }
匿名方法，简单地说就是内联在方法内部的委托对象，它的关键便在于形成了一个闭包（委托执行时所需的上下文）。如上面的代码中，BeginGetResponse的第一个参数（委托）可以直接使用TestRequest方法的参数url，以及方法内的“局部”变量request。如果没有匿名函数这个特性的话，代码写起来就麻烦了，例如在.NET 1.x中您可能就必须这么写：
展开
此时，我们往往会发现，开发人员需要花费大量的精力，为一小部分代码维护一大段上下文。例如在这段代码中，我们会将url和request对象塞入一个object数组中，在回调函数中再通过危险的Cast操作恢复数据。如果您希望“强类型”，那么只能为每个回调创建一个新的上下文对象，维护起来可能更加麻烦——要知道，在并行编程，异步调用越来越重要的今天，如果没有匿名方法自动保留上下文的特性，开发人员会为这些“额外工作”疲于奔命的。
可能您会说，匿名方法的可读性不佳，因为需要“内联”。一个方法中内联太多，维护成本就上去了，所以匿名方法并不推荐使用。我想说的是，您错了。如果为了可维护性，要将方法独立拆开，也可以利用匿名方法的优势：
public static void TestRequest(string url) { WebRequest request = HttpWebRequest.Create(url); request.BeginGetResponse(delegate(IAsyncResult ar) { TestAsyncCallback(ar, request, url); }, null); } public static void TestAsyncCallback(IAsyncResult ar, WebRequest request, string url) { using (WebResponse response = request.EndGetResponse(ar)) { Console.WriteLine("{0}: {1}", url, response.ContentLength); } }
如果借助.NET 3.5中的Lambda表达式，代码可以写的更简单易读：
public static void TestRequest(string url) { WebRequest request = HttpWebRequest.Create(url); request.BeginGetResponse(ar => TestAsyncCallback(ar, request, url), null); }
匿名方法使用案例：延迟初始化器
千万不要小看匿名方法的作用，有些时候您认为它的作用仅限于上文描述，只是因为没有在某些问题上踏前一步。例如，对于那些只需要“按需创建”，且要“线程安全”的对象，您会怎么做呢？没错，可以使用Double Check：
private object m_mutex = new object(); private bool m_initialized = false; private BigInstance m_instance = null; public BigInstance Instance { get { if (!this.m_initialized) { lock (this.m_mutex) { if (!this.m_initialized) { this.m_instance = new BigInstance(); this.m_initialized = true; } } } return this.m_instance; } }
嗯，做的很漂亮！那么……这样的属性再来一个，再来三个，再来五个呢？可能有些朋友就会开始大段地Copy & Paste，于是错误便难免了。这里有一件真人真事，以前某位同学在一堆这样的代码中迷茫了，说为什么用了这种方法，还是初始化了多次对象了？检查了半天没有看出问题来。最后发现，原因是访问了错误的initialized变量（例如，在某个应该访问artistInitialized的地方访问了articleInitialized）。可惜，大段时间已经被浪费了——更糟的是，心情也随之变差了。
其实，Copy & Paste很明显没有遵守DRY原则啊。为什么不把它们封装在一处呢？例如：
展开
于是，之前的代码就可以简化成这样了：
private Lazy<BigInstance> m_lazyInstance = new Lazy<BigInstance>(delegate { return new BigInstance(); }); public BigInstance Instance { get { return this.m_lazyInstance.Value; } }
还是太丑，上Lambda表达式！
private Lazy<BigInstance> m_lazyInstance = new Lazy<BigInstance>(() => new BigInstance()); public BigInstance Instance { get { return this.m_lazyInstance.Value; } }
如果没有匿名方法，许多容易使用的编程模型和方式都难以开展。例如，我们就不会有CacheHelper，也不会有AsyncTaskDispatcher（上，下），也很难利用“延迟”所带来的便利，更难以出现微软并行扩展、CCR等优秀框架。可以这么说，如果您不善于使用委托，您如果不知道如何合适地使用匿名方法，您在不自知的情况下可能就已经编写了大量额外的代码了。
老赵平时的工作之一，便是为项目提供各种扩展API，可以让程序员们更愉快地进行开发工作，得到更好的生产力，让代码变得更加美好。如今C#有了匿名方法、Lambda表达式、表达式树、扩展方法等优秀的语言特性，真让我有“如鱼得水”的感觉。因此，我对于Java这样不思进取的语言可以说深恶痛绝（Java朋友们赶快学习Scala吧）。在看阅读大量Java开源项目代码时，我常有这样的感觉：“如果是C#的话，利用匿名方法，这个类不就可以不写，那个类就可以省略……”。没错，为了保留回调函数的上下文而创建一些类，对于C#程序员来说，的确是一件有些不可思议的事情。
至于Lambda表达式以及其他话题，我们下次再说吧。
匿名方法的缺点
匿名方法的优势在于自动形成闭包，而它的缺点也是让程序员“不自觉”地创建了闭包，这会让某些对象的生命周期加长。例如在一开始的TestRequest方法中，表面上看起来url是参数，request是局部变量，有些朋友可能会认为它们在方法退出后就已经准备回收了。不过因为形成了闭包，url和request已经“升级”为一个对象的域变量，它的生命周期延长了，延长至回调函数执行完毕。因此，一不注意可能就会产生一些莫名其妙的情况。
其实，这些都是“延迟”所带来的陷阱，作为一个优秀的开发人员，除了知道某个东西的作用和优势，也要知道它的问题，不是吗？
总结
您现在还觉得.NET中的“委托”是一个简单的，只适合“初学者”，一搜就都知道的概念吗？
您可能会说“是”，不过对我来说这真不简单，我也是慢慢才意识到这些的。虽然关于委托的大量内容可以在互联网上搜索而来，但还是有太多东西是需要在大量编程实践中积累下来的——等一下，这不就是“高级开发人员”和“初学者”的主要区别之一吗？
嘲笑孔乙己的朋友们，你们在一味鄙视“茴”的四种写法的同时，说不定也失去了一个了解中国传统文化的机会呢！
剩下的下次再说吧，Lambda表达式还等着我们。
相关文章
- 从.NET中委托写法的演变谈开去（上）：委托与匿名方法
- 从.NET中委托写法的演变谈开去（中）：Lambda表达式及其优势
- 从.NET中委托写法的演变谈开去（下）：性能相关
居然这么快就出来了