一看，又4個月沒發(fā)文章了，這4個月除去春節(jié)奔波，基本上一直在加班，在中國做程序員總是與外國同行不一樣，起跑線上輸?shù)煤軈柡?。其?shí)按照《人件》統(tǒng)計，程序員一天如果能順流超過3個小時，基本上就可以秒殺絕大多數(shù)問題了。問題是在我們現(xiàn)行的工作環(huán)境下，經(jīng)常是一天連一分鐘順流都進(jìn)入不了，必須是各種打擾，各種打斷，看似提升了效率，事實(shí)上是降低了效率。而且，絕大多數(shù)時間，我們可能花在了調(diào)試錯誤上，而非本身的邏輯問題上。這樣，一天比老外多工作幾個小時——以完成同樣的目的——就是很正常的了。

　　呵呵，說著要說WPF的，怎么發(fā)了一堆牢騷，其實(shí)論環(huán)境，比起很多人來，我可能已經(jīng)是蒙受了很多恩惠了。每天至少有一些充電的時間和機(jī)會，不說廢話了，接下來還是進(jìn)入正題吧，WPF。

　　Windows Presentation Foundation，這是微軟2006年提出的，雖然看似比Forms簡單，但其實(shí)發(fā)展?jié)摿艽蟆?/p>

　　MFC對我是噩夢，System.Windows.Forms沒有好多少（當(dāng)然，有朋友說我連Forms的1%都沒發(fā)揮出來）。這兩個庫一個比較大的問題是在于表現(xiàn)與內(nèi)容是分開的。Forms已經(jīng)添加了數(shù)據(jù)綁定，這個還不錯，但是也沒有能從根本上解決問題，很多時候我們把精力花在了處理數(shù)據(jù)的表現(xiàn)上。這其實(shí)引入了很多不確定的因素，并導(dǎo)致了潛在的錯誤增加。

　　WPF我一開始是很排斥的，當(dāng)看到它的數(shù)據(jù)綁定之后，感覺非常好用——在編寫XAML的時候，只需要很簡單的語法，就可以把一個控件真正的變成一個數(shù)據(jù)本身。數(shù)據(jù)變化則控件的表現(xiàn)形態(tài)變化，而且這一切是以比Forms和MFC更好的方式來做的——調(diào)用約定。實(shí)現(xiàn)一個接口，就可以讓控件知道它如何去反映一個數(shù)據(jù)本身。這樣，對于“從數(shù)據(jù)到表現(xiàn)”，就是若干約定，人們信守了約定，就可以把數(shù)據(jù)真正映射成為表現(xiàn)，而更關(guān)鍵的是這些約定的重用就成為了可能。

　　我們看《設(shè)計模式》，一個最大的感覺就是，這不是具體的編碼方法，而是一種約定的方法。一定要有這樣幾個組成部分，它們之間如何通信，如何交互，但是每個組成部分本身的自由自在，是沒有人去限制的。

　　我感覺，程序是用來描述“客觀實(shí)在”的，也就是說程序是用來描述其所面對的一個體系的特性的。這些特性包括，體系包含著哪些概念？概念與概念之間的相互關(guān)系如何？一開始，我們認(rèn)為一個體系有若干流程，數(shù)據(jù)是在流動的，控制是在流動的——因此有了基于過程的程序設(shè)計，這是一切的根本。后來，我們發(fā)現(xiàn)，體系內(nèi)部的概念往往本身就代表了一系列的數(shù)據(jù)和控制集合——因此就有了基于對象的程序設(shè)計。后來，我們發(fā)現(xiàn)，為了增加擴(kuò)展性，體系內(nèi)部可以有一些小概念來描述一個個獨(dú)立個體，然后由這些獨(dú)立個體多態(tài)組合為一個真正的行為個體——因此有了面向?qū)ο蟮某绦蛟O(shè)計。最后，我們發(fā)現(xiàn)對象爆炸了，數(shù)據(jù)也會變化，控制也會變化，世界上的一切都在變化，還有什么是不變化的呢？契約。——于是就有了WPF。

　　當(dāng)然最后一句是開玩笑的。契約的意思就是我不管你怎么做，我只要你提供給我什么結(jié)果，或者我告訴你我要給你什么通知——約定最好的實(shí)現(xiàn)方式就是接口，而不是實(shí)體類，因?yàn)轭悗в辛藬?shù)據(jù)，這就難免影響實(shí)現(xiàn)者對于一個問題的判斷。

　　WPF和2006年出現(xiàn)的其他一些技術(shù)一樣，就是對這個問題的一個回答。數(shù)據(jù)——其實(shí)就是概念——你愛變不變，愛怎么變怎么變，對于WPF而言，需要的就是你去實(shí)現(xiàn)一個接口，就可以把你的概念容納到我的系統(tǒng)中來。

　　在工作中，我發(fā)現(xiàn)很多人很可能忽視了UI系統(tǒng)的重要性——UI系統(tǒng)其實(shí)就是一個最簡化的游戲系統(tǒng)，設(shè)計UI系統(tǒng)的方案中間包括了你游戲系統(tǒng)中可能面對的基本問題和基本思路。很多人喜歡從一些具體的細(xì)枝末節(jié)去考慮這個問題，比如誰的UI實(shí)現(xiàn)了訂閱者模式，誰的UI實(shí)現(xiàn)了數(shù)據(jù)驅(qū)動，誰的UI實(shí)現(xiàn)了腳本驅(qū)動，誰的UI酷，炫。但其實(shí)更核心的是來參考這個UI系統(tǒng)的構(gòu)成——基于白盒理念（繼承）的設(shè)計還是基于黑盒理念（訂閱者）的設(shè)計，兩者如何融合？是否區(qū)分了設(shè)計時（Designer）和運(yùn)行時。等等之類的問題。

　　WPF在這個方面可能能帶來一些新的想法和思路——不同于我們浪費(fèi)唇舌于MFC的繼承機(jī)制和Forms的繼承+訂閱機(jī)制誰更優(yōu)秀的新的思路，基于約定而設(shè)計一個體系的思路，基于契約而設(shè)計一個體系的思路，基于組件和模塊而設(shè)計一個體系的思路。

　　因?yàn)轶w系，之所以要提出體系，就是為了能容納更多的人進(jìn)入到體系之中。這就好比原始的工廠和流水線工廠的區(qū)別。原始的工廠體系下，一個人需要處理一個零件從頭到尾的全過程。而流水線下面，一個人只需要完成確定模塊的確定任務(wù)。如果說流水線極大地提升了人類的勞動生產(chǎn)率，那么我相信一套優(yōu)秀的體系設(shè)計同樣能帶來這樣的好處——如果它可以讓每個模塊的參與者不知道其它模塊的存在，那么這樣的理想境界至少是降低了大量的學(xué)習(xí)和調(diào)試的成本。無數(shù)次的實(shí)踐證明，模塊內(nèi)部的錯誤很好抓，跨模塊的錯誤將是致命的。

　　參與項目的人越來越多，牛人也越來越多，現(xiàn)在的游戲開發(fā)已經(jīng)不再是那個連找人都困難的時代了。接下來的問題，難道還是誰能做個好效果，誰能做個酷編輯器的問題么？在目前所從事的這個項目中，我感受到了一次深刻的碰撞，我看到一個構(gòu)架堪稱完美的服務(wù)器，在需求的沖擊面前屹立不倒，也看到過一個崩潰的UI，對新需求近乎沒有耐受能力。我認(rèn)為，好的體系的設(shè)計并非只是空中樓閣，它不過就是程序設(shè)計到了一定階段，接近于社會化大生產(chǎn)之前，必然而然所面對的客觀規(guī)律。如果認(rèn)識到了這個規(guī)律，并且在實(shí)際的生產(chǎn)生活中應(yīng)用了這些規(guī)律，至少能得到一些必要的收益。

　　你可以不知道，并非你無權(quán)知道，而是因?yàn)槟阌袡?quán)不知道。

NET技術(shù)：從WPF想開去，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。