匿名方法的作用與缺點(diǎn)
匿名方法的作用
千萬不要小看匿名方法的作用，有些時(shí)候您認(rèn)為它的作用僅限于上文描述，只是因?yàn)闆]有在某些問題上踏前一步。例如，對(duì)于那些只需要“按需創(chuàng)建”，且要“線程安全”的對(duì)象，您會(huì)怎么做呢？沒錯(cuò)，可以使用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;
- }
- }
嗯，做的很漂亮！那么……這樣的屬性再來一個(gè)，再來三個(gè)，再來五個(gè)呢？可能有些朋友就會(huì)開始大段地Copy & Paste，于是錯(cuò)誤便難免了。這里有一件真人真事，以前某位同學(xué)在一堆這樣的代碼中迷茫了，說為什么用了這種方法，還是初始化了多次對(duì)象了？檢查了半天沒有看出問題來。***發(fā)現(xiàn)，原因是訪問了錯(cuò)誤的initialized變量（例如，在某個(gè)應(yīng)該訪問artistInitialized的地方訪問了articleInitialized）。可惜，大段時(shí)間已經(jīng)被浪費(fèi)了——更糟的是，心情也隨之變差了。
其實(shí)，Copy & Paste很明顯沒有遵守DRY原則埃為什么不把它們封裝在一處呢？例如：
- public class Lazy<T>
- {
- public Lazy(Func<T> func)
- {
- this.m_initialized = false;
- this.m_func = func;
- this.m_mutex = new object();
- }
- private Func<T> m_func;
- private bool m_initialized;
- private object m_mutex;
- private T m_value;
- public T Value
- {
- get
- {
- if (!this.m_initialized)
- {
- lock (this.m_mutex)
- {
- if (!this.m_initialized)
- {
- this.m_value = this.m_func();
- this.m_func = null;
- this.m_initialized = true;
- }
- }
- }
- return this.m_value;
- }
- }
- }
于是，之前的代碼就可以簡化成這樣了：
- private Lazy<BigInstance> m_lazyInstance =
- new Lazy<BigInstance>(delegate { return new BigInstance(); });
- public BigInstance Instance { get { return this.m_lazyInstance.Value; } }
還是太丑，上Lambda表達(dá)式！
- private Lazy<BigInstance> m_lazyInstance =
- new Lazy<BigInstance>(() => new BigInstance());
- public BigInstance Instance { get { return this.m_lazyInstance.Value; } }
如果沒有匿名方法，許多容易使用的編程模型和方式都難以開展。例如，我們就不會(huì)有CacheHelper，也不會(huì)有AsyncTaskDispatcher（上，下），也很難利用“延遲”所帶來的便利，更難以出現(xiàn)微軟并行擴(kuò)展、CCR等優(yōu)秀框架?？梢赃@么說，如果您不善于使用委托，您如果不知道如何合適地使用匿名方法，您在不自知的情況下可能就已經(jīng)編寫了大量額外的代碼了。
老趙平時(shí)的工作之一，便是為項(xiàng)目提供各種擴(kuò)展API，可以讓程序員們更愉快地進(jìn)行開發(fā)工作，得到更好的生產(chǎn)力，讓代碼變得更加美好。如今C#有了匿名方法、Lambda表達(dá)式、表達(dá)式樹、擴(kuò)展方法等優(yōu)秀的語言特性，真讓我有“如魚得水”的感覺。因此，我對(duì)于Java這樣不思進(jìn)取的語言可以說深惡痛絕（Java朋友們趕快學(xué)習(xí)Scala吧）。在看閱讀大量Java開源項(xiàng)目代碼時(shí)，我常有這樣的感覺：“如果是C#的話，利用匿名方法，這個(gè)類不就可以不寫，那個(gè)類就可以省略……”。沒錯(cuò)，所以匿名方法的作用就是，為了保留回調(diào)函數(shù)的上下文而創(chuàng)建一些類，對(duì)于C#程序員來說，的確是一件有些不可思議的事情。
至于Lambda表達(dá)式以及其他話題，我們下次再說吧。
匿名方法的缺點(diǎn)
匿名方法的優(yōu)勢在于自動(dòng)形成閉包，而它的缺點(diǎn)也是讓程序員“不自覺”地創(chuàng)建了閉包，這會(huì)讓某些對(duì)象的生命周期加長。例如在一開始的TestRequest方法中，表面上看起來url是參數(shù)，request是局部變量，有些朋友可能會(huì)認(rèn)為它們?cè)诜椒ㄍ顺龊缶鸵呀?jīng)準(zhǔn)備回收了。不過因?yàn)樾纬闪碎]包，url和request已經(jīng)“升級(jí)”為一個(gè)對(duì)象的域變量，它的生命周期延長了，延長至回調(diào)函數(shù)執(zhí)行完畢。因此，一不注意可能就會(huì)產(chǎn)生一些莫名其妙的情況。
其實(shí)，這些都是“延遲”所帶來的陷阱，作為一個(gè)優(yōu)秀的開發(fā)人員，除了知道某個(gè)東西的作用和優(yōu)勢，也要知道它的問題，不是嗎？
【編輯推薦】
