Posted on 2005-12-28 22:49
canonical 閱讀(995)
評論(0) 編輯 收藏 所屬分類:
Witrix開發(fā)平臺
循環(huán)結(jié)構(gòu)是imperative
language的重要組成部分,一般也是程序中比較難以理解的部分。特別是沒有軟件技術(shù)背景的朋友,明顯對于循環(huán)的理解力較弱。在Von
Neumann體系結(jié)構(gòu)中,賦值語句是必須的,因而引出了存儲概念,也引入了時間概念,因為我們可以區(qū)分出賦值前和賦值后的時刻。引入時間之后,本質(zhì)性的
影響是程序串行化,而強(qiáng)迫我們從并行思考轉(zhuǎn)入串行處理。很多時候這是一種不自然的情況,在我們的自然思維中,我們看到的或想到的也許只是一組靜態(tài)結(jié)構(gòu),但
在程序中表達(dá)的時候卻往往不可避免的需要引入一個動態(tài)過程。而我們控制動態(tài)結(jié)構(gòu)的能力總是不足的。最近對于函數(shù)式語言及處理風(fēng)格的越來越強(qiáng)烈的要求可能也
從側(cè)面反映了大家對這種結(jié)構(gòu)失配的不滿。
但是串行思維毫無疑問也是我們正常思維模式的一部分(當(dāng)然這種思維模式在多大程度上是因為Von
Neumann
體系造成的,也是個很有趣的問題)。例如在頁面渲染的時候,我們可能希望預(yù)先把所有用到的數(shù)據(jù)都轉(zhuǎn)載到內(nèi)存中,賦予不同的變量名,然后在頁面模板中我們只
要知道如何把這些數(shù)據(jù)變量表現(xiàn)出來就可以了。先做完A再做B,這是分層的思想,也是典型的串行思維。而基于數(shù)據(jù)進(jìn)行處理,也是Von
Nenuman體系的基本思想。但是如果處處要求預(yù)先計算并賦值,往往增加了很多額外的步驟(glue
code),并且增大了對內(nèi)存(計算空間)的需求。分層之后,還存在著一個各個層次之間結(jié)構(gòu)匹配的維護(hù)問題。
面向?qū)ο笤诮Y(jié)構(gòu)表達(dá)方面是一種
巨大的進(jìn)步。經(jīng)過多年的發(fā)展,我們在表達(dá)靜態(tài)結(jié)構(gòu)關(guān)系方面已經(jīng)是駕輕就熟了。通過屬性關(guān)聯(lián),我們可以沿著對象圖進(jìn)行結(jié)構(gòu)遍歷。如果使用成員函數(shù),在這種遍
歷過程中還可以包容更多的動態(tài)特性。而在數(shù)據(jù)持久化方面,ORM的盛行也在一定程度上證明了對象圖的有效性。使用對象圖可以大大降低對賦值語句的需求,減
輕了明確建模的壓力(每一次賦值都要求著一個明確的變量名,一個概念),也緩解了Von Neuman體系結(jié)構(gòu)的束縛。例如,我們不再需要
var user = loadUser(userId);
var userOrgnization = loadOrgnization(user.orgId);
var userOrgnizationName = userOrgnization.name
而是直接使用 user.orgnization.name
目前面向?qū)ο笏磉_(dá)的大多數(shù)結(jié)構(gòu)還是基于數(shù)據(jù)語義的,而我們對于函數(shù)等高階結(jié)構(gòu)的控制能力仍然較弱。設(shè)計模式在這方面提供了一些經(jīng)驗,但還是遠(yuǎn)遠(yuǎn)不夠的。
在我們經(jīng)驗不多的時候,我們需要依賴于明確的實體數(shù)據(jù),而在我們的理解逐步深入之后我們就可以通過Visitor,
Iterator等模式支撐起整個結(jié)構(gòu)。高階結(jié)構(gòu)比低階結(jié)構(gòu)難以控制,一方面是因為動態(tài)性本身比靜態(tài)性難以理解,另一方面函數(shù)對信息的使用和流動是一種主
動約束,如果約束的不正確,會造成結(jié)構(gòu)的失效。而數(shù)據(jù)的使用是完全開放的,很多決定都可以延遲到使用時刻決定。當(dāng)然,開放性帶來的問題也早就眾所周知了:
不受限制的使用將導(dǎo)致無法控制的困境。在基礎(chǔ)的數(shù)據(jù)層封裝方面,一般我并不提倡大量使用domain
model似的具有豐富語義的數(shù)據(jù)對象。因為數(shù)據(jù)是共享的,應(yīng)該存在一個開放的數(shù)據(jù)層,在其上可以建立業(yè)務(wù)對象。混雜在一起會限制系統(tǒng)的演化。