canonical

    最近聽到不少人總是叨念著"細(xì)節(jié)決定成敗"這句話，頗像是每天清晨必修的那句"all money go my home"一樣。決定成敗的因素很多，為什么細(xì)節(jié)能夠成為壓倒一切的關(guān)鍵。
    拿產(chǎn)品來說吧，產(chǎn)品的細(xì)節(jié)處很重要，可能客戶的取舍在毫厘之間。但這是否是事實(shí)之全部。其實(shí)客戶需要的是滿足自己的價(jià)值目標(biāo)，他真的那么在意主要目標(biāo)之外 的細(xì)節(jié)（甚至是刻意造作的細(xì)節(jié)）嗎。制造細(xì)節(jié)的目的只是為了制造與同類產(chǎn)品的不同，這是市場(chǎng)進(jìn)入完全競(jìng)爭(zhēng)狀況的標(biāo)志。只是有意思的是，凡是中國(guó)人涌入的領(lǐng) 域，很快就能造成完全競(jìng)爭(zhēng)的局面。就像我們小區(qū)里的煎餅攤，今天剛開張，明天周圍馬上冒出兩家一樣的，你兩元一份，我兩元一份加一個(gè)雞蛋，他兩元一份加一 個(gè)雞蛋再送一碗豆?jié){。很快，經(jīng)過一場(chǎng)血拼，幾家都難以維系，最終撤攤了事，于是小區(qū)內(nèi)就再也沒煎餅賣了。再過些時(shí)日，有人支起一個(gè)狀元餅的爐子，于是一段 新的血戰(zhàn)征程又開始了。最大的利益永遠(yuǎn)源于創(chuàng)造。當(dāng)然，創(chuàng)造是需要成本的，現(xiàn)在財(cái)大氣粗的主多半沒有創(chuàng)造的激情，而被創(chuàng)造力沖昏頭腦的家伙卻多半在社會(huì)的 底層掙扎。

    項(xiàng)目的細(xì)節(jié)處也很重要，也許見了領(lǐng)導(dǎo)少哈一個(gè)腰，過節(jié)的時(shí)候少送了一份禮，就將項(xiàng)目引至黑暗的深淵。為什么世界是如此的不穩(wěn)定，要受到細(xì)節(jié)的擺布。在國(guó) 內(nèi)，操作多不規(guī)范，因?yàn)槔骊P(guān)系，兩兩聯(lián)系，因人而異的情況很多，缺乏一種外在的制度性的保障，而個(gè)人的好惡卻能在現(xiàn)有的體系中不斷放大。結(jié)果做人優(yōu)先于 做事。

    對(duì)軟件程序來說，細(xì)節(jié)會(huì)決定程序的生死，一個(gè)不經(jīng)意的指針異常就能讓整個(gè)系統(tǒng)崩潰。但程序員也不總是戰(zhàn)戰(zhàn)兢兢，如履薄冰。一種職業(yè)的素養(yǎng)可以消解細(xì)節(jié)的危 險(xiǎn)。當(dāng)我們養(yǎng)成良好的編程習(xí)慣之后，對(duì)這樣的細(xì)節(jié)多半就視而不見了。更理想的方法是引入一種封裝機(jī)制，例如智能指針使得我們?cè)僖膊挥每紤]AddRef和 Release的精確配對(duì)了。而java引入的則是新的世界，野指針這個(gè)細(xì)節(jié)在新世界中被消滅了，我們也不需要這方面的什么個(gè)人素質(zhì)了。細(xì)節(jié)處千變?nèi)f化， 無一定之規(guī)。也許我們最需要的不要應(yīng)對(duì)細(xì)節(jié)的技巧，而是能夠屏蔽和規(guī)范細(xì)節(jié)的規(guī)則。細(xì)節(jié)不是我們的目標(biāo), 一組統(tǒng)一簡(jiǎn)明的游戲規(guī)則才決定著所有博弈參與者的成敗。

    在我看來，軟件開發(fā)就是一個(gè)從二進(jìn)制指令構(gòu)造出一些高級(jí)結(jié)構(gòu)的過程(from binary chaos to artificial intelligence)。這種構(gòu)造依賴于我們控制各種結(jié)構(gòu)的能力。結(jié)構(gòu)化編程向我們展現(xiàn)了一個(gè)機(jī)械化的分解與合成的世界，但這個(gè)世界與我們的真實(shí)世界 卻差異良多。于是，面向?qū)ο缶幊淘噲D直接跳躍到真實(shí)的世界，依賴于我們對(duì)真實(shí)世界中結(jié)構(gòu)的控制能力，直接對(duì)真實(shí)的結(jié)構(gòu)建模。早期面向?qū)ο蠹夹g(shù)的陳述中充斥 著這種烏托邦式的理想圖景。但是這種隱喻是含混的，兩個(gè)世界的巨大差異造成了必然的轉(zhuǎn)換成本，我們只能壓縮這種成本而不可能完全拋棄它，我們必須要經(jīng)歷一 系列的中間過程，經(jīng)歷一個(gè)對(duì)結(jié)構(gòu)問題進(jìn)行深刻思考的過程。近幾年軟件技術(shù)在控制抽象結(jié)構(gòu)方面有了很大進(jìn)展，模板，AOP, xml, SOA等等技術(shù)并不是傳統(tǒng)意義上的面向?qū)ο螅袷菍?duì)結(jié)構(gòu)化編程時(shí)代的回歸。而我們對(duì)于面向?qū)ο蠹夹g(shù)的應(yīng)用也不再僅僅關(guān)注于對(duì)真實(shí)世界的建模，而是將這 種技術(shù)作為一種普適的建模方法應(yīng)用于軟件的方方面面。我們?cè)诰幊痰臅r(shí)候不再斤斤計(jì)較于一個(gè)Class的定義是否反映了事物的本質(zhì)特征，而僅僅在意它是否有 助于我們對(duì)于程序結(jié)構(gòu)的控制。這就象是神經(jīng)網(wǎng)絡(luò)和演化計(jì)算等所謂人工智能技術(shù)，早期的興起源于一個(gè)讓人心血澎湃的理想：向生物世界億萬年的智慧學(xué)習(xí)，但近 幾年的發(fā)展則越來越明顯的表現(xiàn)為一種對(duì)數(shù)學(xué)的回歸。
    EJB和JSP Tag都是很好的技術(shù)，它們的最終形態(tài)都使我們擁有了更強(qiáng)的結(jié)構(gòu)控制能力。但問題是，它們的構(gòu)造成本過高，而限制了其意義的進(jìn)一步引申。輕量級(jí)容器的興起 才真正開發(fā)了AOP技術(shù)的潛力，使得Meta Object Protocol的思想得到真正的發(fā)揮。witrix平臺(tái)中的tpl模板技術(shù)將自定義tag的構(gòu)建成本降到了最低：沒有配置文件，使用tpl自身來構(gòu)造 tag。這些努力使得tpl技術(shù)不再是象是一個(gè)幫助庫(kù)，而成為一種獨(dú)立的語(yǔ)言。應(yīng)用tpl模板，我們可以隨意的將小段html文本封裝為有意義的tag （這在jsp tag中是被明確反對(duì)的實(shí)踐）, 從而獲得一種嶄新的抽象能力。實(shí)際上，我認(rèn)為JSF基于jsp tag技術(shù)，在基本結(jié)構(gòu)的構(gòu)造方面成本過高，無論它的IDE怎樣發(fā)展，最終只能成為一種界面庫(kù)而不會(huì)是真正引領(lǐng)未來方向的技術(shù)。只有突破成本閾值，才能發(fā) 展出新的天地。

    代碼復(fù)用包括兩個(gè)方面：概念復(fù)用和實(shí)現(xiàn)復(fù)用。這兩者在C++的虛擬函數(shù)設(shè)計(jì)中是合二為一的，結(jié)果概念上的模糊往往造成繼承機(jī)制的濫用。為了復(fù)用我們往往在 基類中塞入過多的職責(zé)，并在程序中制造了過多的層次。java的interface是純粹的概念復(fù)用機(jī)制，實(shí)現(xiàn)方面的復(fù)用我們一般通過Impls類或者 Utils類來進(jìn)行，即將代碼片斷寫為靜態(tài)函數(shù)。一般應(yīng)該避免在類中寫特別多的幫助性成員函數(shù)，因?yàn)槌蓡T函數(shù)隱含的通過成員變量相關(guān)著，比靜態(tài)函數(shù)要更加 難以控制。
    類是一個(gè)整體的概念，整體概念失效了，類也就不存在了。從這一點(diǎn)上來說，它未必是比靜態(tài)函數(shù)更加穩(wěn)定。概念與實(shí)現(xiàn)是兩個(gè)不同層面的東西。實(shí)際上它們一般也 是多對(duì)多的關(guān)系。同一個(gè)概念可能換用多種不同的實(shí)現(xiàn)，而同一段功能代碼也可能在多個(gè)類中使用。
    代碼復(fù)用的意義不僅僅在于減少工作量。實(shí)際上復(fù)用是對(duì)軟件的一種真正的檢驗(yàn)，而測(cè)試僅僅是一種模擬的檢驗(yàn)而已。每一次復(fù)用都是對(duì)代碼的一次拷問。在不斷使 用中感受到不同使用環(huán)境中的各種壓力，才能實(shí)現(xiàn)概念的不斷精化并確保實(shí)現(xiàn)的正確性。

    我們開發(fā)程序的目的是為了完成業(yè)務(wù)功能, 理想的情況下程序中的每一條語(yǔ)句都應(yīng)該是與業(yè)務(wù)直接相關(guān)的, 例如程序中不應(yīng)該出現(xiàn)連接數(shù)據(jù)庫(kù), 讀取某個(gè)字段等純技術(shù)性的操作, 而應(yīng)該是得到用戶A的基本信息等具有業(yè)務(wù)含義的操作. dao(data access object)層存在的意義在于將與數(shù)據(jù)持久化相關(guān)的函數(shù)調(diào)用剝離出去, 提供一個(gè)具有業(yè)務(wù)含義的封裝層. 原則上說, dao層與utils等幫助類的功能非常類似, 只是更加復(fù)雜一些, 需要依賴更多的對(duì)象(如DataSource, SessionFactory)等. 如果不需要在程序中屏蔽我們對(duì)于特定數(shù)據(jù)持久層技術(shù)的依賴, 例如屏蔽對(duì)于Hibernate的依賴, 在dao層我們沒有必要采用接口設(shè)計(jì). 一些簡(jiǎn)單的情況下我們甚至可以取消整個(gè)dao層, 而直接調(diào)用封裝好的一些通用dao操作函數(shù), 或者調(diào)用通用的EntityDao類等.
    程序開發(fā)的過程應(yīng)該是從業(yè)務(wù)對(duì)象層開始的, 并逐步將純技術(shù)性的函數(shù)調(diào)用剝離到外部的幫助類中, 同時(shí)我們會(huì)逐漸發(fā)現(xiàn)一些業(yè)務(wù)操作的特定組合也具有明確的含義, 為了調(diào)用的方便, 我們會(huì)把它們逐步補(bǔ)充到service層中. 在一般的應(yīng)用中, 業(yè)務(wù)邏輯很難穩(wěn)定到可以抽象出接口的地步, 即一個(gè)service接口不會(huì)對(duì)應(yīng)于兩個(gè)不同的實(shí)現(xiàn), 在這種情況下使用接口往往也是沒有必要的.
    
    在使用spring的情況下原則上應(yīng)該避免使用getBean的調(diào)用方式, 應(yīng)該盡量通過注入來獲得依賴對(duì)象, 但有時(shí)我們難免需要直接獲取業(yè)務(wù)對(duì)象, 在不使用接口的情況下可以采用如下方式

    class TaskService{
        public static TaskService getInstance(){
            return (TaskService)BeanLoader.getBean(TaskService.class);
        }
    }

    在程序中我們可以直接使用TaskService.getInstance()來得到TaskService對(duì)象.通過命名規(guī)范的約定, 我們可以從類名推導(dǎo)出spring配置文件中的對(duì)象名, 因而不需要使用一個(gè)額外的硬編碼字符串名.

    jsp模型為web程序提供了page/request/session/application這四個(gè)基礎(chǔ)性的變量域. 這種變量域的劃分很大程度上是純技術(shù)性的, 與我們的業(yè)務(wù)應(yīng)用中需要的scope支持相去甚遠(yuǎn). 當(dāng)我們把業(yè)務(wù)對(duì)象的生命周期映射到這些變量域的時(shí)候, 經(jīng)常出現(xiàn)不適應(yīng)的情況. 例如我們可能被迫選擇把與某項(xiàng)業(yè)務(wù)相關(guān)的所有數(shù)據(jù)放置在session中并在各處硬編碼一些資源清理代碼. 為了實(shí)現(xiàn)與愈來愈復(fù)雜的應(yīng)用開發(fā)的契合, 我們需要能夠在程序中定義與應(yīng)用相關(guān)的變量域并實(shí)現(xiàn)對(duì)這些變量域的管理, 即我們需要一種自定義scope的支持而不是使用幾個(gè)固定的scope.
    JBoss的Seam項(xiàng)目http://www.jboss.com/products/seam 中引入了一種所謂declarative application state management的機(jī)制
    http://blog.hibernate.org/cgi-bin/blosxom.cgi/Gavin%20King/components.html, 其中的關(guān)鍵是增加了business process和conversation這兩個(gè)應(yīng)用直接相關(guān)的scope, 它們都是可以根據(jù)需要自由創(chuàng)建的. business process context使用jBPM支持long running的狀態(tài)保持. 而conversation context是對(duì)session使用的一種精細(xì)化, 與beehive項(xiàng)目中的page flow所需的scope支持非常類似 http://beehive.apache.org/docs/1.0m1/pageflow/pageflow_overview.html. 但目前seam中的scope支持仍是非常原始的, 不支持嵌套的context, 這意味著對(duì)于復(fù)雜應(yīng)用尚無控制和管理能力.

    在無侵入性的前臺(tái)頁(yè)面控件設(shè)計(jì)方案中, 我們需要一種簡(jiǎn)便的方法迅速定位頁(yè)面中的某一節(jié)點(diǎn)(dom node). 使用xpath是非常誘人的一個(gè)技術(shù)選擇, 但是在實(shí)際使用中, 我們卻發(fā)現(xiàn)xpath并不是那么方便. xpath的能力非常強(qiáng)大, 它支持絕對(duì)定位, 例如//input[@id='3'], 也支持相對(duì)定位, 例如 ./input[0], 甚至支持根據(jù)節(jié)點(diǎn)內(nèi)容定位, 例如//a[contains(., 'partial text')].
    問題是在一個(gè)復(fù)雜的界面控件中, html節(jié)點(diǎn)本身的結(jié)構(gòu)與界面展現(xiàn)結(jié)構(gòu)并不是一致的,例如一個(gè)特定效果的邊框可能需要多個(gè)html元素互相嵌套才能夠?qū)崿F(xiàn), 因此xpath的相對(duì)路徑選擇能力往往派不上用場(chǎng)(除非是提供http://www.backbase.com/那 樣的界面抽象層), 而根據(jù)內(nèi)容定位的方式過于靈活, 難以維護(hù)一個(gè)穩(wěn)定的概念層. 相比較而言, css的選擇符所提供的節(jié)點(diǎn)定位方式要比xpath更加簡(jiǎn)單直觀, 它的適用性也早已在大量的實(shí)踐中得到了證實(shí). 基于css選擇符實(shí)現(xiàn)behaviour機(jī)制是一種更加可行的方案. 參見 http://prototype.conio.net/

    在軟件設(shè)計(jì)中分層應(yīng)該是越少越好, 過度分解一般都是有害的. 雖然說復(fù)雜的事物分解之后一般可以得到一些較簡(jiǎn)單的組成成分, 但這并不是必然有用的. 分析學(xué)成功的關(guān)鍵在于分解之后的組分能夠出現(xiàn)大量重疊的情況, 參見軟件中的分析學(xué) http://canonical.blogdriver.com/canonical/555330.html
    當(dāng)分解到一定程度之后我們未必能夠發(fā)現(xiàn)可以重用的部分. 而且即使分解后系統(tǒng)中所有的基元都是簡(jiǎn)單的, 也并不意味著整個(gè)系統(tǒng)就是簡(jiǎn)單的. 生物遺傳密碼由四種堿基構(gòu)成, 但是我們理解了ATGC決不意味著我們理解了生命. 在理論上存在一種連接主義, 認(rèn)為真正的復(fù)雜性蘊(yùn)含在元素之間的關(guān)系之中而不在于元素自身的復(fù)雜性. 例如神經(jīng)網(wǎng)絡(luò)的研究中可調(diào)的參數(shù)多半是神經(jīng)元之間的連接權(quán)重,而不是神經(jīng)元本身的模型參數(shù).
    在理想中, 我們希望系統(tǒng)的功能劃分能夠涇渭分明, 一個(gè)類負(fù)責(zé)一個(gè)獨(dú)立的功能實(shí)現(xiàn)或者一個(gè)功能側(cè)面(aspect). 但是這只是一種烏托邦式的理想. 在物理的世界中, 我們未必能夠?yàn)槊恳粋€(gè)我們思維中獨(dú)立的概念找到一個(gè)穩(wěn)定的物質(zhì)載體. 就像是水中的漩渦, 看上去它也有固定的形狀, 一定的穩(wěn)定存在時(shí)間, 但是你無法說是哪些水分子參與了漩渦的構(gòu)成, 實(shí)際上波的傳播掠過了整個(gè)水面. 同樣, 在軟件中功能的歸屬和聚合很多時(shí)候并不是那么穩(wěn)定的.

    敏捷(Agile)開發(fā)的靈魂是演化（evolution）,其具體的過程表現(xiàn)為迭代(iteration)，迭代的每一步就是重構(gòu) (refactor)，而單元測(cè)試(unit test)與持續(xù)集成(continuous integration)模擬了程序生存的環(huán)境（約束），是merciless refactoring的技術(shù)保障。從數(shù)學(xué)上我們知道迭代總有個(gè)收斂問題。一些重型方法將變化（無論是正方向還是反方向的）等價(jià)于風(fēng)險(xiǎn)，而傾向于消除開發(fā) 中的不確定性，其中的迭代是趨于迅速收斂的。敏捷的迭代是開放式的，強(qiáng)調(diào)擁抱變化。敏捷編程排斥過度設(shè)計(jì)，除了過度設(shè)計(jì)會(huì)增加成本之外，另一個(gè)原因就是過 度設(shè)計(jì)會(huì)阻礙重構(gòu)，阻礙變化。敏捷的目標(biāo)不是僵化的穩(wěn)定性而是靈活的適應(yīng)性。當(dāng)然敏捷迭代本身并不能保證系統(tǒng)持久的適應(yīng)性，即使是自然界中的迭代和演化， 失敗的案例也是比比皆是。大量的生物物種在經(jīng)歷了歷史的輝煌之后最終仍然難免被歲月所埋葬。
    在哲學(xué)上，一個(gè)悖論式說法是有存在于無中，或者說簡(jiǎn)單才能更復(fù)雜。杯子是空的，所以能包容萬物。現(xiàn)在什么都沒做，將來才能根據(jù)需要決定如何去做。所謂魚與 熊掌不可兼得，一旦做出了選擇，可能意味著必須放棄將來進(jìn)行其他選擇的機(jī)會(huì)。簡(jiǎn)單的目的不僅僅是為了最快的完成當(dāng)前的任務(wù)，而且要為將來保留變化的可能。 過分強(qiáng)調(diào)目的性，我想是違背了演化的本質(zhì)。高手過招，最忌把招數(shù)用老。我們所要做的是盡量推遲決定的時(shí)刻，并切實(shí)的保證自己隨時(shí)擁有選擇的權(quán)利。
    多樣性是在演化中生存的關(guān)鍵。但多樣性不是后天的。生物學(xué)的實(shí)驗(yàn)證實(shí)，物種的變異并不是環(huán)境變化后發(fā)生的，而是始終存在著并隱藏著，環(huán)境僅僅起了檢選和倍 增的作用。適應(yīng)性的系統(tǒng)總要允許一定的灰色地帶，有時(shí)do something for nothing.

     Agile批評(píng)過度設(shè)計(jì)(over-engineering)的聲音很大，但對(duì)于設(shè)計(jì)不足(under-engineering)同樣是持堅(jiān)決的否定態(tài)度 的。修改過度設(shè)計(jì)的應(yīng)用比修改設(shè)計(jì)不足的程序要容易的多。因?yàn)楹?jiǎn)化的途徑是明確的，而走向復(fù)雜的途徑卻往往是難以控制的。Refactoring To Patterns試圖引入一些經(jīng)驗(yàn)，但這些可預(yù)見的調(diào)整多半只在細(xì)節(jié)處，其影響是局部的。一個(gè)復(fù)雜性低層次的設(shè)計(jì)要支持一個(gè)復(fù)雜性高的應(yīng)用，所需的代碼量 不是線性的堆砌，而是幾何級(jí)數(shù)式的增長(zhǎng)，重構(gòu)的時(shí)候需要做出的改變往往也是影響全局的。而事實(shí)上，設(shè)計(jì)不足是比過度設(shè)計(jì)更加常見的情況。真實(shí)的情況也許 是，在真正需要我們做出創(chuàng)造性設(shè)計(jì)的地方我們因?yàn)闊o知和無能而設(shè)計(jì)不足，而在那些渴求簡(jiǎn)單的地方，我們卻自詡為先知而加上很多華麗的設(shè)計(jì)來維護(hù)虛幻的可擴(kuò) 展性。這里的度是很難把握的。高段位的棋手可以比低段位的棋手預(yù)見到更多的步數(shù)，而一個(gè)優(yōu)秀的軟件架構(gòu)師也需要比普通的程序員更早的預(yù)見到系統(tǒng)發(fā)展的障 礙。在我們明確可預(yù)見的范圍內(nèi)，當(dāng)然是要把所有的設(shè)計(jì)做好，而在我們思維的邊界處，"行"就變得比"思"重要了。
    大談"over-engineering"的主多半都有著豐富的過度設(shè)計(jì)的經(jīng)驗(yàn)，千萬不要把他們回顧時(shí)的話語(yǔ)當(dāng)成是普遍的真理。所謂大巧若拙，精煉的小詩(shī) 可比長(zhǎng)篇大論難寫的多了。有時(shí)采用一種簡(jiǎn)單的處理方式，是因?yàn)槲覀兏杏X到它不會(huì)成為障礙，雖然此時(shí)并沒有明確的設(shè)計(jì)過程。你必須有能力進(jìn)行過度設(shè)計(jì)，才能 真正理解簡(jiǎn)單設(shè)計(jì)的精妙之處

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