從WPF想開去

作者: noslopforever  發布時間: 2010-03-29 15:14  閱讀: 1333 次  推薦: 0   原文鏈接   [收藏]  

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

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

  Windows Presentation Foundation,這是微軟2006年提出的,雖然看似比Forms簡單,但其實發展潛力很大。

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

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

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

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

  當然最后一句是開玩笑的。契約的意思就是我不管你怎么做,我只要你提供給我什么結果,或者我告訴你我要給你什么通知——約定最好的實現方式就是接口,而不是實體類,因為類帶有了數據,這就難免影響實現者對于一個問題的判斷。

  WPF和2006年出現的其他一些技術一樣,就是對這個問題的一個回答。數據——其實就是概念——你愛變不變,愛怎么變怎么變,對于WPF而言,需要的就是你去實現一個接口,就可以把你的概念容納到我的系統中來。

  在工作中,我發現很多人很可能忽視了UI系統的重要性——UI系統其實就是一個最簡化的游戲系統,設計UI系統的方案中間包括了你游戲系統中可能面對的基本問題和基本思路。很多人喜歡從一些具體的細枝末節去考慮這個問題,比如誰的UI實現了訂閱者模式,誰的UI實現了數據驅動,誰的UI實現了腳本驅動,誰的UI酷,炫。但其實更核心的是來參考這個UI系統的構成——基于白盒理念(繼承)的設計還是基于黑盒理念(訂閱者)的設計,兩者如何融合?是否區分了設計時(Designer)和運行時。等等之類的問題。

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

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

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

  你可以不知道,并非你無權知道,而是因為你有權不知道。

0
0
 
標簽:WPF
 
 

文章列表

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()