>>>  小城故事吳儂軟語溫婉人心的力量  >>>

簡體     傳統

      有一天，我問一個同學說，“如果讓你通過程序開發一個虛擬地球出來，模擬不同的人的行為，模擬天氣，地理，人文，股票漲跌，模擬情感，思考，數學，你怎么做？”那哥們眼睛一亮，馬上就說，以人為例。教師，官員，學生，工人都不一樣，都從人這個基類繼承！天氣可以定義一個天氣接口，通過工廠模式提供一組天氣的集合…

      我問，突然哪一天，你需要加一個字段，定義學生是不是程序員！他說，那加一個字段就好了。我說，代碼都發布出去了。那哥們開始冥思苦想了。總之你發現，不可能預知未來的需求！人的類型體系，根本定義不完！鬼知道黑客帝國里的那個大胡子是怎么做到的！

      如果你對這個問題感興趣，那就請繼續閱讀本文。

      先從類庫和框架說起，類庫（Library）和框架（Framework）是不同的。 類庫只提供單一方面的功能，比如網絡庫，數學分析庫。評價庫的好壞，就是其性能和易用性。易用性就是別人能看懂，上手就能用，而且最好平臺無關，框架無關，能用在桌面程序上，還能用在webservice上。

      框架更有意思，如果類庫是輪子，框架就是汽車，框架內肯定包含一組類庫，承載的應用就是乘客。我們當然希望框架越強大越好，可是你怎么定義強大呢？你當然希望它足夠普適！希望這套框架能不經修改，運行在不同的平臺上，同時通過嚴密的接口和繼承體系，滿足我們在某一方面的所有需求。哇，聽起來真不錯！

      類庫已經不夠過癮了，現在大家都喜歡搞搞自己的框架，美其名曰XXXFramework。筆者也是這類腦殘粉之一。我希望我寫的傳感器框架能包含所有與傳感器相關的場景，希望寫的數據挖掘框架包含所有可能會存在的與數據分析相關的需求。是不是很酷？但真正動手寫起來，差點把我搞死。在沒有明確需求的情況下，憑空寫出一套普適性極強的框架，簡直是不可能的任務。大家想到這里，肯定會問為什么。打個比方說，傳感器有很多種，比如最簡單的溫度，濕度，還有復雜的心電信號，甚至你可以把股票的API抽象為一個傳感器。那么，你怎么定義傳感器這樣的Entity?

      一種做法，搞一套嚴密的體系，給出一堆接口（可讀接口，可控制接口，需要進行功率控制的接口）和抽象類，有多少傳感器就寫多少種Class， 然后給別人一看，哇，漂亮的一套繼承樹結構！所有應用都面向抽象，看起來高端大氣上檔次。 我就是這么做的，但真正的情況并非如此，總有溫度傳感器同時提供了濕度，總有傳感器會有奇怪但又特重要的參數，更何況怎么去個性化的配置這些傳感器的端口，網絡連接，電源管理等等的問題？最終，筆者怒寫代碼一寒假，頭發掉了很多，發現這樣的框架極其冗余，為了框架而框架， 而不論基礎庫寫得再怎么完善，總是無法料想未來新的需求！最終走進了死胡同。

      另一種做法，是直接定義一個字典Dictionary， 鍵是屬性名，值是屬性值，想要什么屬性，就通過讀寫字典搞定了！我去！頓時發現，你原來寫的那一套東西，辛辛辛苦寫的繼承體系，愣是不如這樣的字典好用！然后怒改代碼一個月，又把所有的實體類型，都改成了Dictionary, 甚至連函數的參數，都定義成了字典！爽。。。。有人說都用Object吧？那也太簡單粗暴了。

      我們可以認為這是是強類型和弱類型的兩種極端。強類型主義者，所有的快感都來自敲鍵盤的”.”之后的自動提示，當然還有編譯器提供的編譯幫助。對弱類型主義者來說，寫框架太容易了，厚厚的文檔，告訴別人某字段叫什么名字，某方法怎么調用，稍微不小心就會出現運行時錯誤。每當我看到params object[] args這樣的函數參數，就想罵人。

      我們都知道，任何變量都可以被序列化和反序列化為字符串，字節流，所有的那些強弱類型，對計算機來說都是浮云，它們只是內存里的幾個字節而已。不同的語言和類庫，最終只是玩著字節的舞蹈，把字節串轉換成另外一種字節串。所以說C語言提供了最低級的直接訪問，沒有類和lamda等等那些奇淫技巧。但科學界搞了這么多年的編程語言和特性，肯定不是白發明的，都肯定有其自己的道理。

      程序員都有這樣的理想，你就是國王，管理著你的都城：它有著完整的排水，供暖和交通網絡，有著嚴密的組織結構，每個成員都各司其職，整個系統穩健又高效。想象這樣一套系統，真是讓人激動的戰戰發抖。可是當寫了這么多的代碼，走了這么多的彎路，最終你其實發現，你永遠在復雜性和簡單性之間做平衡，在抽象和具體之間做平衡，在繼承和組合之間做平衡，在強類型和弱類型之間做平衡。

      對絕大多數程序員來說，想寫一套好類庫可以，但寫好一套通用的基礎框架幾乎不可能。原因是，當你使用強類型構建底層時，后期的繼承體系會讓你負重不堪。用弱類型方法構建之后，卻發現你走上了中國哲學的虛空之路，一切皆虛。 越通用的“框架”，就意味著它的底層幾乎無所作為，上層開發者看著腳下的空氣，苦笑著另開爐灶。所以，框架是和需求緊密相關的，在需求不確定的情況下，覆蓋所有可能的場景？笑！

      哲學和數學是萬物之根， 程序員是現代最接近于哲學家和數學家的職業。從哲學演繹出了政治，經濟等人文知識。而自然哲學與數學結合，產生了解釋萬物運作的物理學。計算機科學從另外一種角度將人類的知識體系展示了出來，算法本身需要數學的精密，數據結構和軟件架構則無不體現著哲學的智慧。如同政治哲學指導人類建立都城和政權一樣，計算機哲學幫助程序員建立了接口抽象，松耦合，高內聚等基本觀點。本來，把理論實踐出來將花費很大的成本（想象你要蓋一座高樓），程序則成為幾乎是最低成本的實踐哲學和數學的機會。

      曾經有人說，函數式編程更接近于世界的本質，現在想來也是，每種實體的屬性，都是我們因為問題和需求人為強加進去的，世界的本質是作用和函數，是純弱類型的。我們之所以發明強類型，是因為強類型更接近人的思考模式，更方便維護。你認可這點嗎？

      回到開頭的問題，現有的編程語言和工具，幾乎根本不可能構造出一個虛擬地球！原有的那些設計模式，在這樣一種空泛而宏大的需求下如同雕蟲小技，完全無濟于事。現有的工具無法自動生成新工具（沒有自學習功能）。   再想象一下人腦，人腦從來沒有定義任何的實體類型和接口，沒有任何的屬性，純粹靠著一個網絡和網絡間的交互，卻構建出如此精密的的機器出來！ 如此看來，我們的技術，實在太原始了！

      虛擬地球的理想，只能通過弱類型來定義了，如同我喜歡用字典來表現對象，認為一般的實體對象本質就是鍵值對。某些工具能夠在某些程度構造一個虛擬地球，我猜那是矩陣，矩陣是自帶了X,Y兩種索引值的鍵值對，多個矩陣能構成物體，物體之間的作用可以表達為矩陣之間的運算，作用產生的新矩陣還可以再被處理。如同IEnumerable接口可實現運算鏈一樣，矩陣也能做到。矩陣內部還可以再鑲嵌子矩陣，以描述對象的包含結構。我們的理想，就靠矩陣了！ 想想黑客帝國， 想想matlab!!

      筆者寫到這里都要困死了，那種寫通用框架的想法，先拋到腦后吧，我不是微軟，寫不了像WPF這種牛逼的框架，那種十幾個個類串下來的繼承結構，只有閑的蛋疼的人才會去仔細分析。以后我再也不敢去寫什么框架了，只敢寫庫了，簡單好用，滿足需求提供功能就夠了。那種統一的思想，丟給那些哲學家吧，我不干了….

http://www.cnblogs.com/buptzym/

熱情的沙漠 2013-12-16 20:32:00