canonical

  AOP(Apsect Oriented Programming)概念的正式出現(xiàn)也有一些時(shí)日了，但是它在程序構(gòu)造過(guò)程中似乎仍未找到合適的切入點(diǎn)，一般系統(tǒng)的設(shè)計(jì)實(shí)現(xiàn)很少將AOP作為必要的技術(shù)元素。AOP作為一種普適的技術(shù)思想，它所代表的是程序結(jié)構(gòu)空間中的定位和組裝技術(shù)。http://canonical.javaeye.com/blog/34941 AOP使我們可以通過(guò)非侵入性的方式動(dòng)態(tài)修改“任意”已經(jīng)構(gòu)建好的程序，而不需要事前有大量的設(shè)計(jì)準(zhǔn)備。原則上說(shuō),這種技術(shù)思想是可以在任何程序語(yǔ)言基礎(chǔ)上進(jìn)行表達(dá)的，并不是只有java, C#這樣的面向?qū)ο笳Z(yǔ)言才允許AOP操作. Witrix平臺(tái)中所應(yīng)用的部分技術(shù)與AOP有些類似，只是大量的結(jié)構(gòu)調(diào)整表現(xiàn)為xml生成和xml變換，在具體的使用方式上也有一些微妙的差異。http://canonical.javaeye.com/blog/126467

  相對(duì)于通用程序語(yǔ)言，xml語(yǔ)言其實(shí)是AOP技術(shù)的一個(gè)更加合適的形式載體。
1. xml格式特殊的規(guī)范性確保了在最細(xì)的邏輯粒度上，程序結(jié)構(gòu)也是可識(shí)別的，可操縱的（在這一點(diǎn)上非常類似于函數(shù)式語(yǔ)言）。而所有的命令式語(yǔ)言(imperative language)中，函數(shù)內(nèi)部的結(jié)構(gòu)都是很難采用統(tǒng)一方式進(jìn)行描述和定位的。

2. xml節(jié)點(diǎn)的坐標(biāo)可以采用xpath或者css選擇符等通用方式進(jìn)行描述，而一般程序結(jié)構(gòu)無(wú)法達(dá)到xml格式這樣的均一性，其中的坐標(biāo)定位方式要復(fù)雜得多。
3. xml節(jié)點(diǎn)上可以增加任意屬性，不同的屬性可以屬于不同的命名空間(namespace)，這些屬性可以輔助AOP的定位機(jī)制。而一般程序語(yǔ)言中如果沒(méi)有Annotation機(jī)制, 則定位只能依賴于函數(shù)名和類名（函數(shù)參數(shù)只有類型沒(méi)有名稱），而類名和函數(shù)名隨時(shí)可能因?yàn)闃I(yè)務(wù)變化而調(diào)整（不是專為定位而存在）, 由此構(gòu)建的切點(diǎn)描述符是不穩(wěn)定的。
 
4. xml節(jié)點(diǎn)的增刪改查顯然要比字節(jié)碼生成技術(shù)要簡(jiǎn)單和直觀得多。
   

   AOP技術(shù)難以找到應(yīng)用的一個(gè)重要原因在于很多人機(jī)械式的將它定位為一種橫切技術(shù)，認(rèn)為它的價(jià)值完全在于某個(gè)確定的切面可以插入到多個(gè)不同的切點(diǎn)，實(shí)現(xiàn)系統(tǒng)的橫向分解。而在實(shí)際應(yīng)用中，業(yè)務(wù)層面上很少具有可抽象的固定的共同性，我們所迫切需要的一般是對(duì)已有程序結(jié)構(gòu)進(jìn)行動(dòng)態(tài)擴(kuò)展的一種能力。橫切是AOP的一種特殊的應(yīng)用，但不是它的全部。相對(duì)于繼承(inheritance)等依賴于概念詮釋的結(jié)構(gòu)擴(kuò)展機(jī)制，AOP所代表正是對(duì)程序結(jié)構(gòu)空間進(jìn)行任意操縱的一種能力。AOP可以為基礎(chǔ)結(jié)構(gòu)增加功能，改變?cè)泄δ軐?shí)現(xiàn)，也可以取消原有功能實(shí)現(xiàn)，它不需要把所有的擴(kuò)展邏輯按照樹(shù)形結(jié)構(gòu)進(jìn)行組織，不要求在基礎(chǔ)結(jié)構(gòu)中為擴(kuò)展編寫特殊的代碼。這種自由的結(jié)構(gòu)擴(kuò)展能力在Witrix平臺(tái)中被發(fā)展為“實(shí)現(xiàn)業(yè)務(wù)代碼與平臺(tái)基礎(chǔ)架構(gòu)之間的動(dòng)態(tài)融合”。

   在Witrix平臺(tái)的實(shí)際應(yīng)用中，AOP的切點(diǎn)匹配能力并不是十分重要。一般情況下我們主要通過(guò)整體結(jié)構(gòu)規(guī)劃來(lái)確保控制點(diǎn)意義明確且相對(duì)集中，因此不需要額外通過(guò)切點(diǎn)匹配進(jìn)行業(yè)務(wù)功能的再組織，不需要再次從雜亂的程序邏輯中重新發(fā)現(xiàn)特殊的控制點(diǎn)。例如在Witrix平臺(tái)的Jsplet框架中所有后臺(tái)事件響應(yīng)都通過(guò)objectName和objectEvent參數(shù)觸發(fā)，在觸發(fā)后臺(tái)事件響應(yīng)函數(shù)之前都會(huì)調(diào)用bizflow文件中的beforeAction段。
   在bizflow文件中，aop操作是明確指定到具體函數(shù)的，使用模糊匹配在一般情況下只會(huì)使問(wèn)題變得不必要的復(fù)雜化。例如擴(kuò)展actQuery函數(shù)

   
   在Witrix平臺(tái)中結(jié)構(gòu)組裝主要是通過(guò)自定義標(biāo)簽庫(kù)和extends算子來(lái)實(shí)現(xiàn)，它們都依賴于xml格式的規(guī)范性。
1. 通過(guò)在custom目錄下實(shí)現(xiàn)同名的自定義標(biāo)簽，即可覆蓋Witrix平臺(tái)所提供的缺省標(biāo)簽實(shí)現(xiàn)，這里所依賴的并不是復(fù)雜的匹配過(guò)程，而是自然直觀的映射過(guò)程。http://canonical.javaeye.com/blog/196826
2. 所有的xml配置文件支持extends操作，它允許定制兩個(gè)具有業(yè)務(wù)含義的xml節(jié)點(diǎn)之間的結(jié)構(gòu)融合規(guī)則。例如<biz-flow extends="docflow">。

   實(shí)際使用中, AOP技術(shù)的一個(gè)應(yīng)用難點(diǎn)在于狀態(tài)空間的管理問(wèn)題。一般interceptor中所能訪問(wèn)的變量局限為this指針?biāo)鶖y帶的成員變量，以及函數(shù)調(diào)用時(shí)傳入的調(diào)用參數(shù)。interceptor很難在狀態(tài)空間中創(chuàng)建新的變量，也很難讀取在其他地方所產(chǎn)生的狀態(tài)變量。例如對(duì)于如下擴(kuò)展 A(arg1); B(arg2); C(arg3); =〉 Ax(arg1); B(arg2); Cx(arg3); 因?yàn)樵械恼{(diào)用序列中沒(méi)有傳遞額外的參數(shù)，因此A和C的擴(kuò)展函數(shù)之間很難實(shí)現(xiàn)共享內(nèi)部變量x。在TPL模板語(yǔ)言中，tpl本身是無(wú)狀態(tài)的，狀態(tài)變量通過(guò)外部的$thisContext對(duì)象統(tǒng)一管理。通過(guò)這種行為與狀態(tài)的分離，結(jié)合靈活的變量作用域控制機(jī)制，可以以比較簡(jiǎn)單的方式實(shí)現(xiàn)擴(kuò)展函數(shù)之間的信息共享。

    說(shuō)到分解，很多人心中的意象大概只有正交分解。正交分解無(wú)疑是最重要的一種分析方法，它也是所謂“分而治之”思想最常見(jiàn)的實(shí)現(xiàn)策略。但是正交分解一般潛在的假定是分解后的子部分是大致均衡的，它們是相對(duì)具有獨(dú)立價(jià)值的，可以彼此脫離獨(dú)立發(fā)展。這是分解后實(shí)現(xiàn)系統(tǒng)解耦的重要原因。http://canonical.javaeye.com/blog/33885 但是物理學(xué)中另一種重要的分析學(xué)思想是微擾論(Perturbation). 針對(duì)一個(gè)復(fù)雜的物理現(xiàn)象，首先建立一個(gè)全局的規(guī)范的模型，然后考慮各種微擾條件對(duì)原有模型的影響。在小擾動(dòng)情況下，模型的變化部分往往可以被線性化，被局域化，因而問(wèn)題得到簡(jiǎn)化。微擾分析得到的解依賴于全局模型的解而存在，因而這是一種主從關(guān)系的分解方式。但是如果主體模型是我們已經(jīng)熟知的物理現(xiàn)象，則我們關(guān)注的重點(diǎn)可以全部放在擾動(dòng)解上，認(rèn)為所有特定的物理規(guī)律都體現(xiàn)在擾動(dòng)解中。如果微擾分析得到的物理元素足夠豐富，則微擾模型本身可以成為獨(dú)立的研究對(duì)象，在其中我們同樣可以發(fā)現(xiàn)某種普適的結(jié)構(gòu)規(guī)律。
    Witrix平臺(tái)中系統(tǒng)化的應(yīng)用主從分解模式，通過(guò)類似AOP的技術(shù)實(shí)現(xiàn)了業(yè)務(wù)模型與平臺(tái)技術(shù)的自然結(jié)合。http://canonical.javaeye.com/blog/126467 最近我們的一個(gè)產(chǎn)品的新版本即將在全國(guó)范圍內(nèi)部署，如何有效的控制眾多相近的二次開(kāi)發(fā)版本，同時(shí)確保主版本的快速升級(jí)，是在架構(gòu)層面必須解決的問(wèn)題。http://canonical.javaeye.com/blog/73265 在Witrix平臺(tái)中，各部署版本并不是直接修改主版本源代碼得到，而是將差異化代碼放在單獨(dú)的目錄中進(jìn)行管理，由系統(tǒng)運(yùn)行平臺(tái)負(fù)責(zé)將差異化定制代碼與主版本代碼進(jìn)行動(dòng)態(tài)融合，實(shí)現(xiàn)部署版本的客戶化。在這一過(guò)程中，系統(tǒng)模型本身支持逆元結(jié)構(gòu)至關(guān)重要，否則某些多余的元素?zé)o法通過(guò)差異性描述去除，則將出現(xiàn)局部模型失效的情況。
    Witrix平臺(tái)定義了特殊的_custom目錄，它的內(nèi)部目錄結(jié)構(gòu)與defaultroot目錄相同，系統(tǒng)平臺(tái)優(yōu)先使用該目錄下文件所提供的功能實(shí)現(xiàn)。同時(shí)定義了系統(tǒng)參數(shù)global.app_id和global.default_app_id，它們分別用來(lái)區(qū)分當(dāng)前程序版本以及程序主版本代碼。例如當(dāng)global.app_id=beijing,global.default_app_id=main的時(shí)候，系統(tǒng)中裝載ui.xml這個(gè)標(biāo)簽庫(kù)時(shí)經(jīng)歷如下過(guò)程，
1.    裝載平臺(tái)內(nèi)置的標(biāo)簽庫(kù)，文件路徑為 /_tpl/ui.xml.
2.    根據(jù)global.default_app_id設(shè)置，裝載/_custom/main/_tpl/ui.xml, 其中定義的標(biāo)簽實(shí)現(xiàn)將覆蓋平臺(tái)缺省提供的標(biāo)簽實(shí)現(xiàn)。對(duì)于那些不需要特殊定制的標(biāo)簽，繼續(xù)使用平臺(tái)提供的缺省實(shí)現(xiàn)。
3.    根據(jù)global.app_id設(shè)置，裝載/_custom/beijing/_tpl/ui.xml, 其中定義的標(biāo)簽實(shí)現(xiàn)將覆蓋產(chǎn)品主版本的標(biāo)簽實(shí)現(xiàn)。

基礎(chǔ)平臺(tái)中對(duì)于代碼動(dòng)態(tài)融合定義了精細(xì)的融合策略，將通過(guò)編譯技術(shù)檢查擴(kuò)展標(biāo)簽的接口與缺省實(shí)現(xiàn)的接口相兼容，由此確保代碼擴(kuò)展后不會(huì)破壞主版本中的已有調(diào)用代碼。
    在基礎(chǔ)平臺(tái)的實(shí)現(xiàn)中，很多實(shí)現(xiàn)代碼都是類似

這樣的類似廢話的標(biāo)簽調(diào)用。但是通過(guò)這些標(biāo)簽的標(biāo)記，我們確立了系統(tǒng)的邏輯結(jié)構(gòu)，標(biāo)定了系統(tǒng)中可以被安全替換的邏輯片斷。

     在與一些年歲較大的C程序員接觸的過(guò)程中，可以比較明顯的感受到C的思維方式與面向?qū)ο笏枷氲牟煌的世界很清澈，先做A, 再做B, 我們所期待發(fā)生的計(jì)算過(guò)程與源代碼的結(jié)構(gòu)是直接一一對(duì)照的。這意味著程序?qū)⒁獔?zhí)行的計(jì)算過(guò)程在編寫代碼的時(shí)刻就已經(jīng)確定下來(lái)。面向?qū)ο笫紫刃枰_定的是類，對(duì)象等中間元素，而并不是最終的計(jì)算過(guò)程。對(duì)象可以之間可以產(chǎn)生很復(fù)雜的結(jié)構(gòu)關(guān)系，透過(guò)這種中間邏輯結(jié)構(gòu)我們來(lái)理解最終要發(fā)生的計(jì)算過(guò)程。在事件驅(qū)動(dòng)的應(yīng)用場(chǎng)景下，面向?qū)ο笫且环N更加有效的描述，
  o.someFunc()                  o.onEventA();
    sub1.someFunc();      ==>     sub1.onEventA();
    sub2.someFunc();              sub2.onEventB();
如果把對(duì)象看作是函數(shù)+狀態(tài)的集合，則對(duì)象組裝的關(guān)系實(shí)際上是函數(shù)集合之間的一種組裝關(guān)系。當(dāng)具體的事件發(fā)生的時(shí)候，將觸發(fā)對(duì)象上確定的響應(yīng)函數(shù)，此時(shí)在各個(gè)層面上所實(shí)際發(fā)生的計(jì)算才能被確定下來(lái)。

   所謂WebMVC即Model2模型是目前Web開(kāi)發(fā)領(lǐng)域的主流模型，Struts/Struts2框架是其典型實(shí)現(xiàn)。在概念層面上，這種程序組織模型是怎樣建立起來(lái)的?與其他Web開(kāi)發(fā)模型(如面向?qū)ο竽Ｐ?具有怎樣的聯(lián)系? 它未來(lái)可能的發(fā)展方向在哪里? 結(jié)合Witrix開(kāi)發(fā)平臺(tái)的具體實(shí)踐，基于級(jí)列設(shè)計(jì)理論我們可以看到一條概念發(fā)展的脈絡(luò)。http://canonical.javaeye.com/blog/33824

   1. 外部視角：原始的servlet規(guī)范提供了一個(gè)簡(jiǎn)單的面向IO的程序響應(yīng)模型。一次前臺(tái)訪問(wèn)由一個(gè)特定的servlet負(fù)責(zé)響應(yīng)，它從request中讀取輸入流，在全局session中保持臨時(shí)狀態(tài)，向response中寫入輸出流。在此基礎(chǔ)上，JSP提供的模板概念翻轉(zhuǎn)了程序和輸出文本之間的相對(duì)地位，簡(jiǎn)化了文本輸出過(guò)程。至此，這種整體的程序模型基本上只是規(guī)范化了外部系統(tǒng)訪問(wèn)Web服務(wù)器的響應(yīng)模型，并沒(méi)有對(duì)后臺(tái)程序的具體實(shí)現(xiàn)制定明確的約束條件。因此在最粗野的后臺(tái)實(shí)現(xiàn)中，讀取參數(shù)，業(yè)務(wù)處理，生成頁(yè)面等處理步驟是糾纏在一起的，很難理解，也很難重用。每一個(gè)后臺(tái)頁(yè)面都是一個(gè)不可分析的整體。


2. 自發(fā)分離：在復(fù)雜的程序?qū)嵺`中，我們會(huì)自發(fā)的對(duì)業(yè)務(wù)處理代碼和界面代碼進(jìn)行一定程度的分離。因?yàn)槲覀兛梢灾庇^的感受到這兩種代碼的穩(wěn)定性并不匹配。例如不同業(yè)務(wù)處理過(guò)程產(chǎn)生的結(jié)果都可以用一個(gè)html表格來(lái)展現(xiàn)，而同一個(gè)業(yè)務(wù)處理過(guò)程產(chǎn)生的結(jié)果頁(yè)面可能經(jīng)常發(fā)生變化。一般我們傾向于將業(yè)務(wù)代碼寫在頁(yè)面上方，而界面代碼寫在頁(yè)面下方，并使用一些原始的分解機(jī)制，例如include指令。這種分離是隨意的，缺乏形式邊界的。例如我們無(wú)法表達(dá)被包含的頁(yè)面需要哪些參數(shù)，也難以避免全局變量名沖突。需要注意的是，分層的一般意義在于各個(gè)層面可以獨(dú)立發(fā)展，它的隱含假定是各層面之間的交互是規(guī)范化的，只使用確定的數(shù)據(jù)結(jié)構(gòu)，按照確定的方式進(jìn)行交互。例如業(yè)務(wù)層和界面層通過(guò)標(biāo)準(zhǔn)的List/Map等數(shù)據(jù)結(jié)構(gòu)交互，而不是使用具有無(wú)限多種樣式的特殊的數(shù)據(jù)結(jié)構(gòu)。(在弱類型語(yǔ)言環(huán)境中，實(shí)體對(duì)象的結(jié)構(gòu)和Map是等價(jià)的).


   3. 規(guī)范分離：JSP所提供的useBean和tag機(jī)制，即所謂的Model1模型，是對(duì)程序結(jié)構(gòu)分離的一種規(guī)范化。業(yè)務(wù)代碼封裝在java類中，一般業(yè)務(wù)函數(shù)與web環(huán)境無(wú)關(guān)，即不使用request和response對(duì)象, 允許單元測(cè)試。tag機(jī)制可以看作是對(duì)include指令的增強(qiáng)，是一種代碼重用機(jī)制。tld描述明確了調(diào)用tag時(shí)的約束關(guān)系。調(diào)用tag時(shí)需要就地指定調(diào)用參數(shù)，而include頁(yè)面所依賴的參數(shù)可能是在此前任意地方指定的，是與功能實(shí)現(xiàn)分離的。此外tag所使用的參數(shù)名是局部對(duì)象上的屬性名，從而避免了對(duì)全局變量的依賴。很遺憾的是，jsp tag所封裝的仍然是原始的IO模型，對(duì)程序結(jié)構(gòu)缺乏精細(xì)的定義，在概念層面上只是對(duì)文本片段的再加工，難以支撐復(fù)雜的控件結(jié)構(gòu)。早期jsp tag無(wú)法利用jsp模板本身來(lái)構(gòu)造，無(wú)法構(gòu)成一個(gè)層層遞進(jìn)的概念抽象機(jī)制，更是讓這種孱弱的重用模型雪上加霜。在其位卻無(wú)能謀其政，這直接造成了整個(gè)j2ee前臺(tái)界面抽象層的概念缺失，以致很多人認(rèn)為一種前臺(tái)模板重用機(jī)制是無(wú)用的。在Witrix平臺(tái)中所定義的tpl模板語(yǔ)言，充分利用了xml的結(jié)構(gòu)特點(diǎn)，結(jié)合編譯期變換技術(shù)，成為Witrix平臺(tái)中進(jìn)行結(jié)構(gòu)抽象的基本手段。實(shí)際上，xml能夠有效表達(dá)的語(yǔ)義比一般人所想象的要多得多。

  
  4. 框架分離：在Model1模型中，頁(yè)面中存在著大量的粘結(jié)性代碼，它們負(fù)責(zé)解析前臺(tái)參數(shù)，進(jìn)行類型轉(zhuǎn)換和數(shù)據(jù)校驗(yàn)，定位特定的業(yè)務(wù)處理類，設(shè)置返回結(jié)果，控制頁(yè)面跳轉(zhuǎn)等。一種自然的想法是定義一個(gè)全局的程序框架，它根據(jù)集中的配置文件完成所有的粘結(jié)性操作。這也就是所謂面向action的WebMVC模型。這一模型實(shí)現(xiàn)了服務(wù)器端業(yè)務(wù)層和界面層在實(shí)現(xiàn)上的分離，但是對(duì)于外部訪問(wèn)者而言，它所暴露的仍然是原始的自動(dòng)機(jī)模型：整個(gè)網(wǎng)站是一個(gè)龐大的自動(dòng)機(jī)，每次訪問(wèn)都觸發(fā)一個(gè)action，在action中可能更改自動(dòng)機(jī)的狀態(tài)（作為全局狀態(tài)容器的session對(duì)象或者數(shù)據(jù)庫(kù)）。struts作為面向action框架的先驅(qū)，它也很自然的成為了先烈。struts中所引入的FormBean, 鏈接管理等概念已經(jīng)在實(shí)踐中被證明是無(wú)益的。一些新興的框架開(kāi)始回歸到通用的Map結(jié)構(gòu)，直接指定跳轉(zhuǎn)頁(yè)面，或者利用CoC(Convention Over Configuration)缺省映射.

  
5. 橫向延展：分層之后必然導(dǎo)向各個(gè)層面的獨(dú)立發(fā)展，我們的視野自然也會(huì)擴(kuò)大到單個(gè)頁(yè)面之外，看到一個(gè)層面上更多元素之間的相互作用．在面向?qū)ο笳Z(yǔ)言大行其道的今天，繼承(inheritance)無(wú)疑是多數(shù)人首先想到的程序結(jié)構(gòu)組織手段．后臺(tái)action可以很自然的利用java語(yǔ)言自身的繼承機(jī)制，配置文件中也可以定義類似的extends或者parent屬性．但是對(duì)于前臺(tái)頁(yè)面一般卻很少有適用的抽象手段，于是便有人致力于前臺(tái)頁(yè)面的對(duì)象語(yǔ)言化：首先將前臺(tái)頁(yè)面采用某種對(duì)象語(yǔ)言表達(dá)，然后再利用對(duì)象語(yǔ)言內(nèi)置的結(jié)構(gòu)抽象機(jī)制．放棄界面的可描述性，將其轉(zhuǎn)化為某種活動(dòng)對(duì)象，在我看來(lái)是一種錯(cuò)誤的方向．而JSF(JavaServerFace)規(guī)范卻似乎想在這個(gè)方向上越走越遠(yuǎn)．JSF早期設(shè)計(jì)中存在的一個(gè)嚴(yán)重問(wèn)題是延續(xù)了面向?qū)ο笳Z(yǔ)言中的狀態(tài)與行為綁定的組織方式．這造成每次訪問(wèn)后臺(tái)頁(yè)面都要重建整個(gè)Component Tree, 無(wú)法實(shí)現(xiàn)頁(yè)面結(jié)構(gòu)的有效緩存．而Witrix平臺(tái)中的tpl模板語(yǔ)言編譯出的結(jié)構(gòu)是無(wú)狀態(tài)的，可以在多個(gè)用戶之間重用．

  6. 相關(guān)聚合：對(duì)象化首先意味著相關(guān)性的局域化，它并不等價(jià)于對(duì)象語(yǔ)言化. 當(dāng)面對(duì)一個(gè)大的集合的時(shí)候，最自然的管理手段便是分組聚合：緊密相關(guān)的元素被分配到同一分組，相關(guān)性被局域化到組內(nèi)．例如，針對(duì)某個(gè)業(yè)務(wù)對(duì)象的增刪改查操作可以看作屬于同一分組. struts中的一個(gè)最佳實(shí)踐是使用DispatchAction, 它根據(jù)一個(gè)額外的參數(shù)將調(diào)用請(qǐng)求映射到Action對(duì)象的子函數(shù)上．例如/book.do?dispatchMethod=add. 從外部看來(lái)，這種訪問(wèn)方式已經(jīng)超越了原始的servlet響應(yīng)模型，看起來(lái)頗有一些面向?qū)ο蟮臉幼樱矁H僅局限于樣子而已．DispatchAction在struts框架中無(wú)疑只是一種權(quán)宜之計(jì)，它與form, navigation等都是不協(xié)調(diào)的，而且多個(gè)子函數(shù)之間并不共享任何狀態(tài)變量（即不發(fā)生內(nèi)部的相互作用），并不是真正對(duì)象化的組織方式．按照結(jié)構(gòu)主義的觀點(diǎn)，整體大于部分之和．當(dāng)一組函數(shù)聚集在一起的時(shí)候，它們所催生的一個(gè)概念便是整體的表征：this指針．Witrix平臺(tái)中的Jsplet框架是一個(gè)面向?qū)ο蟮腤eb框架，其中同屬于一個(gè)對(duì)象的多個(gè)Action響應(yīng)函數(shù)之間可以共享局部的狀態(tài)變量（thisObj），而不僅僅是通過(guò)全局的session對(duì)象來(lái)發(fā)生無(wú)差別的全局關(guān)聯(lián)．http://canonical.javaeye.com/blog/33873 需要注意的是，thisObj不僅僅聚集了后臺(tái)的業(yè)務(wù)操作，它同時(shí)定義了前后臺(tái)之間的一個(gè)標(biāo)準(zhǔn)狀態(tài)共享機(jī)制，實(shí)現(xiàn)了前后臺(tái)之間的聚合．而前臺(tái)的add.jsp, view.jsp等頁(yè)面也因此通過(guò)thisObj產(chǎn)生了狀態(tài)關(guān)聯(lián)，構(gòu)成頁(yè)面分組．為了更加明確的支持前臺(tái)頁(yè)面分組的概念，Witrix平臺(tái)提供了其他一些輔助關(guān)聯(lián)手段．例如標(biāo)準(zhǔn)頁(yè)面中的按鈕操作都集中在std.js中的stdPage對(duì)象上，因此只需要一條語(yǔ)句stdPage.mixin(DocflowOps);即可為docflow定制多個(gè)頁(yè)面上的眾多相關(guān)按鈕操作．此外Witrix平臺(tái)中定義了標(biāo)準(zhǔn)的url構(gòu)建手段，它確保在多個(gè)頁(yè)面間跳轉(zhuǎn)的時(shí)候，所有以$字符為前綴的參數(shù)將被自動(dòng)攜帶．從概念上說(shuō)這是一種類似于cookie，但卻更加靈活，更加面向應(yīng)用的狀態(tài)保持機(jī)制．



  7. 描述分離：當(dāng)明確定義了Action所聚集而成的對(duì)象結(jié)構(gòu)之后，我們?cè)俅位氐絾?wèn)題的原點(diǎn)：如何簡(jiǎn)化程序基元（對(duì)象）的構(gòu)建？繼承始終是一種可行的手段，但是它要求信息的組織結(jié)構(gòu)是遞進(jìn)式的，而很多時(shí)候我們實(shí)際希望的組織方式只是簡(jiǎn)單的加和。通過(guò)明確定義的meta(元數(shù)據(jù))，從對(duì)象中分離出部分描述信息，在實(shí)踐中被證明是一種有效的手段。同樣的后臺(tái)事件響應(yīng)對(duì)象(ActionObject)，同樣的前臺(tái)界面顯示代碼(PageGroup)，配合不同的Meta，可以產(chǎn)生完全不同的行為結(jié)果, 表達(dá)不同的業(yè)務(wù)需求。http://canonical.javaeye.com/blog/114066 從概念上說(shuō)，這可以看作是一種模板化過(guò)程或者是一種復(fù)雜的策略模式 ProductWebObject = DaoWebObject<ProductMeta>。當(dāng)然限于技術(shù)實(shí)現(xiàn)的原因，在一般框架實(shí)現(xiàn)中，meta并不是通過(guò)泛型技術(shù)引入到Web對(duì)象中的。目前常見(jiàn)的開(kāi)發(fā)實(shí)踐中，經(jīng)常可以看見(jiàn)類似BaseAction<T>, BaseManager<T>的基類，它們多半僅僅是為了自動(dòng)實(shí)現(xiàn)類型檢查。如果結(jié)合Annotation技術(shù)，則可以超越類型填充，部分達(dá)到Meta組合的效果。使用meta的另外一個(gè)副作用在于，meta提供了各個(gè)層面之間新的信息傳遞手段，它可以維系多個(gè)層面之間的共變(covariant)。例如在使用meta的情況下，后臺(tái)代碼調(diào)用requestVars(dsMeta.getUpdatableFields())得到提交參數(shù)，前臺(tái)頁(yè)面調(diào)用forEach dsMeta.getViewableFields()來(lái)生成界面. 則新增一個(gè)字段的時(shí)候，只需要在meta中修改一處，前后臺(tái)即可實(shí)現(xiàn)同步更新，自動(dòng)維持前后臺(tái)概念的一致性。有趣的是，前后臺(tái)在分離之后它們之間的關(guān)聯(lián)變得更加豐富。

8. 切面分離: Meta一般用于引入外部的描述信息，很少直接改變對(duì)象的行為結(jié)構(gòu)。AOP(Aspect Oriented Programming)概念的出現(xiàn)為程序結(jié)構(gòu)的組織提供了新的技術(shù)手段。AOP可以看作是程序結(jié)構(gòu)空間中定位技術(shù)和組裝技術(shù)的結(jié)合，它比繼承機(jī)制和模板機(jī)制更加靈活，也更加強(qiáng)大。http://canonical.javaeye.com/blog/34941 Witrix平臺(tái)中通過(guò)類似AOP的BizFlow技術(shù)實(shí)現(xiàn)對(duì)DaoWebAction和前臺(tái)界面的行為擴(kuò)展，它可以在不擴(kuò)展DaoWebAction類的情況下，增加/修正/減少web事件響應(yīng)函數(shù)，增加/修正/減少前臺(tái)界面展現(xiàn)元素。當(dāng)前臺(tái)發(fā)送的$bizId參數(shù)不同的時(shí)候，應(yīng)用到WebObject上的行為切片也不同，從而可以自然的支持同一業(yè)務(wù)對(duì)象具有多個(gè)不同應(yīng)用場(chǎng)景的情況（例如審核和擬制）。在BizFlow中定義了明確的實(shí)體化過(guò)程，前臺(tái)提交的集合操作將被分解為針對(duì)單個(gè)實(shí)體的操作。例如前臺(tái)提交objectEvent=Remove&id=1&id=2,將會(huì)調(diào)用兩次<action id="Remove-default">操作。注意到AOP定位技術(shù)首先要求的就是良好的坐標(biāo)定義, 實(shí)體化明確定義了實(shí)體操作邊界，為實(shí)體相關(guān)切點(diǎn)的構(gòu)造奠定了基礎(chǔ)。http://canonical.javaeye.com/blog/33784

9. 背景消除：在Witrix平臺(tái)中, (DaoWebAction + StdPageGroup + Meta + BizFlow)構(gòu)成完整的程序模型，因此一般情況下并不需要繼承DaoWebAction類，也不需要增加新的前臺(tái)頁(yè)面文件，而只需要在BizFlow文件中對(duì)修正部分進(jìn)行描述即可。在某種程度上DaoWebAction+StdPageGroup所提供的CRUD(CreateReadUpdateDelete)模型成為了默認(rèn)的背景知識(shí)。如果背景信息極少泄漏，則我們可以在較高抽象層次上進(jìn)行工作，而不再理會(huì)原始的構(gòu)造機(jī)制。例如在深度集成hibernate的情況下，很少會(huì)有必須使用SQL語(yǔ)句的需求。BizFlow是對(duì)實(shí)體相關(guān)的所有業(yè)務(wù)操作和所有頁(yè)面展現(xiàn)的集中描述，在考慮到背景知識(shí)的情況下，它定義了一個(gè)完整的自給自足的程序模型。當(dāng)我們的建模視角轉(zhuǎn)移到BizFlow模型上時(shí)，可以發(fā)展出新的程序構(gòu)造手段。例如BizFlow之間可以定義類似繼承機(jī)制的extends算子，可以定義實(shí)體狀態(tài)驅(qū)動(dòng)的有限自動(dòng)機(jī)，可以定義不同實(shí)體之間的鉤稽關(guān)系（實(shí)體A發(fā)生變化的時(shí)候自動(dòng)更新實(shí)體B上的相關(guān)屬性），也可以定義對(duì)Workflow的自然嵌入機(jī)制。從表面上看，BizFlow似乎回歸到了前后臺(tái)大雜燴的最初場(chǎng)景（甚至更加嚴(yán)重，它同時(shí)描述了多個(gè)相關(guān)頁(yè)面和多個(gè)相關(guān)操作），但是在分分合合的模型建立過(guò)程中，大量信息被分解到背景模型中，同時(shí)發(fā)展了各種高級(jí)結(jié)構(gòu)抽象機(jī)制, 確保了我們注意力的關(guān)注點(diǎn)始終是有限的變化部分。而緊致的描述提高了信息密度，簡(jiǎn)化了程序構(gòu)造過(guò)程。http://canonical.javaeye.com/blog/126467

  自從離開(kāi)學(xué)校就基本上不再使用C++了，最近卻又因?yàn)轫?xiàng)目上的原因重新走入這一迷失的世界, 感覺(jué)很是缺乏一些順手的工具。首先就是做配置管理有點(diǎn)麻煩, 因?yàn)槿狈Ψ瓷錂C(jī)制, 無(wú)法直接映射, 所以一般需要手工書寫配置設(shè)置功能.
  我們希望配置類在配置階段能夠支持動(dòng)態(tài)屬性名，

    但是內(nèi)部使用時(shí)支持直接的屬性訪問(wèn)，便于編譯器檢查， 也提高運(yùn)算速度。


所幸C++的類型系統(tǒng)能夠偷偷的去干很多見(jiàn)不得人的勾當(dāng)，因此便有了下面這個(gè)簡(jiǎn)易機(jī)制。


_variant_t是VC++在<comdef.h>中提供的對(duì)變體數(shù)據(jù)類型的封裝。使用S_P和G_P這樣的宏可以由編譯器檢查變量名的正確性。

    關(guān)系數(shù)據(jù)庫(kù)模型在理論上主要解決的是消除數(shù)據(jù)冗余的問(wèn)題。關(guān)系模型的數(shù)學(xué)基礎(chǔ)是所謂的集合論，而集合的基本含義正是一組具有某種原子性的互不相同的元素。面向?qū)ο蠹夹g(shù)是對(duì)相關(guān)性進(jìn)行局域化的一種手段（相關(guān)的數(shù)據(jù)和操作聚集到同一對(duì)象名義下），在這一局域化過(guò)程中，相同的元素被識(shí)別出來(lái)，成為獨(dú)立的對(duì)象。從某種意義上說(shuō)，關(guān)系模型與對(duì)象模型是殊途同歸的過(guò)程，是從不同側(cè)面對(duì)同一事物的反映。關(guān)系模型中，我們關(guān)注的重點(diǎn)是元素組成的集合，允許的連接關(guān)系定義在集合之上。而在對(duì)象模型中，我們關(guān)注的首先是橫向關(guān)聯(lián)的實(shí)體，實(shí)體之間具有穩(wěn)定的聯(lián)系。在概念層面上，從對(duì)象模型映射到一種關(guān)系存儲(chǔ)模型只是一個(gè)分組問(wèn)題。為了斷開(kāi)實(shí)體之間的直接聯(lián)系，關(guān)系模型創(chuàng)造了一個(gè)id字段，而對(duì)象模型并不是需要顯式id的。在關(guān)系模型中，關(guān)聯(lián)并不是通過(guò)某種存在的結(jié)構(gòu)來(lái)表達(dá)的（一個(gè)實(shí)體持有另一個(gè)實(shí)體的指針，擁有直接聯(lián)系），而是將直接關(guān)聯(lián)問(wèn)題弱化為某種計(jì)算過(guò)程，我們必須檢查id的值（不是某種直接的存在性），通過(guò)某種運(yùn)算過(guò)程才能重新發(fā)現(xiàn)數(shù)據(jù)之間的關(guān)聯(lián)。
   
    通過(guò)id（伴隨一個(gè)匹配計(jì)算過(guò)程）來(lái)進(jìn)行間接關(guān)聯(lián)對(duì)于保證模型的一致性是非常關(guān)鍵的。在ORM中恢復(fù)了對(duì)象的強(qiáng)關(guān)聯(lián)其實(shí)會(huì)造成很多潛在的復(fù)雜性。例如為了維護(hù)對(duì)象層面結(jié)構(gòu)的一致性，在更新父子關(guān)系的時(shí)候，我們需要同時(shí)調(diào)用 child.setParent(parent); parent.getChildren().remove(child); 當(dāng)關(guān)聯(lián)結(jié)構(gòu)更加復(fù)雜的時(shí)候，這里所需要的維護(hù)工作是隨之增加的。不過(guò)，在ORM中，對(duì)象的形態(tài)是暫時(shí)性的。在ORM的一次session的操作過(guò)程中，對(duì)于對(duì)象狀態(tài)的修改可以是不一致的。例如我們可以只調(diào)用child.setParent(parent); 而不需要同時(shí)  parent.getChilren().remove(child); 只要我們?cè)诖舜蝧ession操作中，不需要同時(shí)用到parent.getChildren(). 這種關(guān)聯(lián)的暫時(shí)性對(duì)于很多ORM應(yīng)用來(lái)說(shuō)是必不可少的。
   
    對(duì)象模型中可以直接表達(dá)的結(jié)構(gòu)關(guān)系比關(guān)系模型要豐富一些，例如繼承關(guān)系，many-to-many, one-to-list等。但是所有這些都不是真正本質(zhì)性的差異。拋棄概念詮釋，基類與眾多派生類之間的關(guān)系基本上可以等價(jià)于一組one-to-one關(guān)系。而當(dāng)關(guān)聯(lián)對(duì)象本身的重要性凸現(xiàn)出來(lái)的時(shí)候，當(dāng)我們無(wú)法把它約化為對(duì)象上的一些附屬特性的時(shí)候（例如數(shù)組的下標(biāo)），我們必然要建立相應(yīng)的關(guān)聯(lián)對(duì)象，而這正對(duì)應(yīng)于關(guān)系模型中的中間關(guān)聯(lián)表。中間關(guān)聯(lián)表上增加額外的字段是一個(gè)自然的擴(kuò)展過(guò)程，而對(duì)象模型上做這樣的擴(kuò)充往往表現(xiàn)為形態(tài)上的重大的不兼容的變化，例如從getManyToManyEntity() -> getToManyRelation(), 這實(shí)際上意味著這里的對(duì)象形式是偶然的，簡(jiǎn)化的。
   
    在原始的關(guān)系數(shù)據(jù)庫(kù)模型中，所有的表之間的地位是平等的，所有字段之間的地位是平等的（主鍵和外鍵在參與數(shù)據(jù)關(guān)聯(lián)時(shí)和其他字段的處理方式一致）。這種概念上的均一性和普遍性往往被認(rèn)為是理論的優(yōu)美之處。但是現(xiàn)實(shí)世界是復(fù)雜的，發(fā)展的方向就是逐步識(shí)別出不同之處，并找出自然的表達(dá)形式將這些不同表達(dá)出來(lái)。均勻的關(guān)系模型是對(duì)稱性最高的，最簡(jiǎn)化的模型。在面對(duì)物理約束時(shí)，它隱含的假設(shè)是集合之間很少發(fā)生相互作用，單表（表單到數(shù)據(jù)表之間的映射）和主從表是最廣泛的情況。試著想象一下關(guān)系模型，在思維中一般我們只能看到兩個(gè)數(shù)據(jù)表，當(dāng)考慮到多個(gè)表的時(shí)候，因?yàn)檫@些表之間沒(méi)有明確的可區(qū)分性，因此它們的意象是模糊的。只有明確意識(shí)到主鍵，外鍵，主表，從表，字典表，事實(shí)表，緯度表這些不同的概念的時(shí)候，當(dāng)對(duì)稱性出現(xiàn)破缺的時(shí)候，我們思維中的模型才能夠豐富化起來(lái)。
   
    關(guān)系模型理論應(yīng)用到數(shù)據(jù)庫(kù)具體應(yīng)用中時(shí)，并不需要死守關(guān)系范式教條，它們只是描述了某種極端化的對(duì)唯一性的追求。面對(duì)具體應(yīng)用的時(shí)候，理論本身也在不斷豐富化。我并不把現(xiàn)實(shí)應(yīng)用中必然需要增加冗余字段看作是關(guān)系理論失效的結(jié)果。從關(guān)系完全分解，到關(guān)系完全不分解之間，我們可以建立大量的模型。建立冗余字段的時(shí)候，我們存在著大量可能的選擇，到底哪一種選擇是最優(yōu)的，理論方面仍然可以給我們以具體的指導(dǎo)。理論在各種不同純化程度的關(guān)系模型中都可以給我們以直觀的建議。數(shù)據(jù)倉(cāng)庫(kù)理論中建立的snowflake模式和star模式，強(qiáng)調(diào)了針對(duì)主題域的允許部分冗余的關(guān)系分解。這里實(shí)際上是強(qiáng)調(diào)了表之間的不同性。不再是所有的表都處于同一地位。Fact Table和Dimension Table之間的區(qū)別被識(shí)別出來(lái)，并被明確處理。在我看來(lái)，這是原始關(guān)系模型的一種自然發(fā)展，它也是關(guān)系模型理論的一部分。理論不應(yīng)該是單一的，而是提供一個(gè)模型級(jí)列，在不同的復(fù)雜性層次上，我們可以根據(jù)理論的指導(dǎo)選擇具體的實(shí)現(xiàn)模型。
   
    關(guān)于ORM http://canonical.javaeye.com/blog/111500
    關(guān)系模型中的所謂關(guān)系是在使用時(shí)刻才定義的，所有建立關(guān)系的方式在某種程度上都是等價(jià)的，也是外在的。而在ORM中主鍵與外鍵之間的關(guān)聯(lián)被獨(dú)立出來(lái)，成為模型內(nèi)置的部分。這在很多時(shí)候簡(jiǎn)化了數(shù)據(jù)查詢的結(jié)構(gòu)構(gòu)造過(guò)程。
    在ORM中主鍵因?yàn)榫彺娴拇嬖诙@出與其他字段的區(qū)別。ORM的使用使得數(shù)據(jù)存儲(chǔ)的分解策略得到擴(kuò)充。并不是所有的表的更新頻度都是一致的，而且表中的數(shù)據(jù)量大小也不同。字典表一般較小，而且很少更新，可以安全的復(fù)制。在整個(gè)數(shù)據(jù)存儲(chǔ)框架中，ORM作為獨(dú)立的技術(shù)元素參與數(shù)據(jù)存儲(chǔ)過(guò)程，通過(guò)主鍵提供緩存服務(wù)，產(chǎn)生了新的數(shù)據(jù)分布模型，提供了新的性能優(yōu)化契機(jī)。

    我平時(shí)Kill Time的主要方式是閱讀各類學(xué)術(shù)書籍。但是學(xué)習(xí)本身只是了解前人的發(fā)現(xiàn)，間或鍛煉一下自己的思維能力，對(duì)自己的工作和生活并沒(méi)有什么直接的助益。學(xué)習(xí)本身無(wú)論如何深入，多半也只是采用前人的話語(yǔ)復(fù)現(xiàn)前人思考的歷程。在我們通過(guò)獨(dú)立的思考獲得直觀的體驗(yàn)之前，在我們將所學(xué)到的知識(shí)應(yīng)用到書本之外的場(chǎng)景之前，我們所學(xué)習(xí)的知識(shí)只是考試的工具，只是可供欣賞的對(duì)象，卻不能成為我們思考中活躍的因素，無(wú)法參與我們思維的進(jìn)程。別人只能給你思想的引子，并不能給你真正的思想。只有自己找到了所學(xué)知識(shí)的超出書本的非顯然的應(yīng)用，只有獨(dú)立建立了不同概念之間未曾闡明的聯(lián)系，我們才能真正獲得對(duì)于真理的體悟。無(wú)論我們自己的發(fā)現(xiàn)是如何的微不足道，無(wú)論它是否只是重復(fù)發(fā)現(xiàn)了劣質(zhì)的輪子，它唯一的意義只在于它是我們獨(dú)立思考的結(jié)果，是我們自己的創(chuàng)造。即使它是卑微的，是重復(fù)的，它對(duì)我們的理解的作用仍然是任何外在的教誨都無(wú)法比擬的。

    現(xiàn)代社會(huì)中創(chuàng)造所需的成本已經(jīng)被空前降低了。想想百年前的天才們，他們?nèi)鄙傩畔?lái)源，只能一頁(yè)頁(yè)翻查文獻(xiàn)，反復(fù)謄寫文稿來(lái)保存知識(shí)，大量的時(shí)間被花費(fèi)在了與思考完全無(wú)關(guān)的事情上。同時(shí)，他們所處的時(shí)代存在著更多的不確知性，他們的思考所能夠憑依的事實(shí)更少，做出錯(cuò)誤判斷的可能性與今天相比也更大。即使Bill Gates這樣的掙錢能手在1981年也能放出"640k ought to be enough for anybody"的厥詞，顯示出我們?cè)陬A(yù)測(cè)未來(lái)的時(shí)候是何等的乏力。當(dāng)我們今天站在人類文明的巔峰，擁有前人無(wú)法想象的工具，并不斷制造著從未經(jīng)歷過(guò)的實(shí)踐的時(shí)候，我們理應(yīng)擁有超越歷史上任何天才的，更加寬廣的眼界。

    現(xiàn)代社會(huì)中的創(chuàng)造看似簡(jiǎn)單了，但從另一個(gè)方面看，卻又是大大的復(fù)雜化了。前人的成就成為了難以逾越的豐碑，而為了進(jìn)入科學(xué)殿堂，我們需要的準(zhǔn)備工作也變得異常的繁復(fù)。這里有科學(xué)內(nèi)在的規(guī)律，但也有人為制造的障礙，而這其中最主要的是數(shù)學(xué)障礙。只要想一想，針對(duì)軟件工程，經(jīng)濟(jì)運(yùn)行，企業(yè)管理，每個(gè)參與其中的實(shí)踐者都可以提出一些自己的意見(jiàn)，但是如果涉及到數(shù)學(xué)，為什么大多數(shù)人只有三緘其口了？現(xiàn)代抽象數(shù)學(xué)取得了輝煌的成就，但是它也可能毀掉了更多學(xué)生創(chuàng)造的激情。宏偉精深的大廈讓人敬畏，卻無(wú)法激發(fā)我們?nèi)魏沃庇^的共鳴。甚至Arnold這樣的數(shù)學(xué)大師也坦承讀不懂當(dāng)代數(shù)學(xué)家們的著述：因?yàn)樗麄儚牟徽f(shuō)“彼嘉洗了手”，而只是寫道：存在一個(gè)t1<0，使得t1在自然的映射t1->彼嘉(t1)之下的像屬于臟手組成的集合，并且還存在一個(gè)t2，t1<t2<=0，使得t2在上面提到的映射之下的像屬于前一句中定義的集合的補(bǔ)集。當(dāng)Bourbaki學(xué)派致力于在課本上消滅所有圖示的時(shí)候，理性達(dá)到了非理性的彼岸。

    有時(shí)我在想為什么現(xiàn)在的程序員似乎對(duì)于程序的理解能力降低了。排除教學(xué)水平的降低和個(gè)人努力的不足之外，是否是因?yàn)楝F(xiàn)在需要學(xué)習(xí)的內(nèi)容過(guò)多，以至于喪失了自我思考的勇氣？在C的時(shí)代，每個(gè)程序員對(duì)于程序的理解都是直接的，原始的，對(duì)程序結(jié)構(gòu)的把握都是充滿自信的。當(dāng)新的概念不斷涌現(xiàn)的時(shí)候，人們總是說(shuō)，Object不過(guò)是..., Component不過(guò)是..., AOP不過(guò)是..., ORM不過(guò)是..., IoC不過(guò)是.... 這體現(xiàn)了人們?cè)噲D把新的概念融入自己原有知識(shí)體系的一種努力。雖然仔細(xì)考究起來(lái)，這里的理解很多時(shí)候都是似是而非的，未必掌握了新技術(shù)真正創(chuàng)新的思想方向，但是這里的思考總是獨(dú)立進(jìn)行的，總是對(duì)我們的理解和工作有所助益的。而新一代的程序員生活在Object, Pattern等概念已經(jīng)無(wú)需饒舌來(lái)證明自己的時(shí)代，他們是否在思想中獨(dú)自評(píng)估過(guò)所有概念的意義，是否建立了概念和實(shí)現(xiàn)之間直觀的聯(lián)系，是否在統(tǒng)一的思維世界中為所有的概念找到了合適的坐標(biāo)？這一切，我不得而知。
    
推薦：Arnold 論數(shù)學(xué)教育 http://www.ieee.org.cn/dispbbs.asp?boardID=64&ID=25892

    我在各種場(chǎng)合一直都在強(qiáng)調(diào)結(jié)構(gòu)問(wèn)題是獨(dú)立的，在程序語(yǔ)言之外存在著獨(dú)立的，可研究的，富有成效的結(jié)構(gòu)問(wèn)題。http://canonical.javaeye.com/blog/147424 在這個(gè)方向上更進(jìn)一步，我們注意到所有的代碼并不是天然出現(xiàn)的，而是由人所編制的，因此代碼世界內(nèi)部并不構(gòu)成封閉的，自足的某個(gè)世界。代碼中的結(jié)構(gòu)問(wèn)題并不是由代碼本身完全解決的，即在代碼之外仍然存在著技術(shù)上可研究的結(jié)構(gòu)問(wèn)題。
    我們?cè)诰幹拼a的同時(shí)也在編制著大量的說(shuō)明文檔。這些文檔描述了代碼片斷之間的相互關(guān)系，描述了代碼未來(lái)的擴(kuò)展方向，描述了代碼之間的可能的交互方式，同時(shí)也描述了針對(duì)現(xiàn)有代碼實(shí)現(xiàn)的很多具體約束。例如我們?cè)谖臋n中約定某個(gè)量要在10和20之間，但在代碼中卻不一定顯式進(jìn)行了判斷。針對(duì)代碼結(jié)構(gòu)的很多具體約束條件和相關(guān)性描述可能只在文檔中體現(xiàn)，只在程序員的頭腦中存在，而并不一定忠實(shí)的在代碼結(jié)構(gòu)中得到表達(dá)。
    我在設(shè)計(jì)領(lǐng)域基本持有一種物理實(shí)在論，即某種技術(shù)相關(guān)的約束應(yīng)該在技術(shù)世界中通過(guò)技術(shù)手段得到表達(dá)。只是這里的技術(shù)手段卻不一定指在應(yīng)用中加上特定的代碼實(shí)現(xiàn)，雖然我們?cè)诖a實(shí)現(xiàn)中更直接的表達(dá)設(shè)計(jì)要求無(wú)疑是需要提倡的。為了在程序中有效的維護(hù)結(jié)構(gòu)相關(guān)性，我們并不一定需要抽象出所有可能重用的代碼，并不一定需要確保某一概念在程序中只有精確的唯一的表達(dá)。程序中難以直接精確表達(dá)的弱關(guān)聯(lián)，仍然可以通過(guò)開(kāi)發(fā)/設(shè)計(jì)工具等技術(shù)手段得到有效的維護(hù)。我們需要保證的是代碼世界中知識(shí)的自恰性，而自恰性并不等于唯一性。http://canonical.javaeye.com/blog/33788
    在Witrix中我們采用一種物理模型驅(qū)動(dòng)的開(kāi)發(fā)方式，http://canonical.javaeye.com/blog/29412 由pdm模型出發(fā)，自動(dòng)生成hibernate的hbm文件，java實(shí)體類，元數(shù)據(jù)meta文件，前臺(tái)Action注冊(cè)文件等。生成的配置文件通過(guò)syncWithModel標(biāo)記與模型保持著穩(wěn)定的關(guān)聯(lián)。所有配置文件都支持手工修改，開(kāi)發(fā)工具識(shí)別syncWithModel標(biāo)記，當(dāng)pdm模型發(fā)生變化的時(shí)候，工具自動(dòng)將變化信息同步到各個(gè)配置文件中。注意到這里并不是采用一個(gè)統(tǒng)一的元數(shù)據(jù)模型的方式，各個(gè)配置文件所表達(dá)的信息在一定程度上是重復(fù)的，也可能是不一致的。例如后臺(tái)數(shù)據(jù)庫(kù)允許保存100個(gè)字節(jié)，但是前臺(tái)meta中我們可能配置只允許錄入20個(gè)字節(jié)。根據(jù)不同應(yīng)用場(chǎng)景的需要，我們可以在各個(gè)層面對(duì)每個(gè)配置文件進(jìn)行獨(dú)立的調(diào)節(jié). 當(dāng)然,在一般情況下并不存在這種需要。整個(gè)開(kāi)發(fā)過(guò)程中，信息表達(dá)的自恰性并不是在應(yīng)用程序代碼中得到定義的,而是因?yàn)殚_(kāi)發(fā)工具的存在而在技術(shù)上得到保證的。放松模型之間的唯一匹配要求，我們可以得到更加豐富，更加靈活的軟件結(jié)構(gòu)。實(shí)際上我認(rèn)為RoR(RubyOnRails)采用直接映射的ActiveRecord的方式雖然有效保證了系統(tǒng)變動(dòng)中知識(shí)的一致性，但是如果不允許在各個(gè)層面上都能夠自然的定義某種偏離，它在復(fù)雜應(yīng)用中的價(jià)值就要打上大大的折扣。

   設(shè)計(jì)考慮的是最終需要什么，最終我們要提供的調(diào)用接口是什么，我們所直接需要的某個(gè)有價(jià)值的，直接存在的，直接可以接觸的結(jié)構(gòu)是什么，而不是它所依據(jù)的原理是什么，不是它的具體構(gòu)造過(guò)程或者構(gòu)造方法是什么。比如說(shuō)我們?cè)诔绦蛑型耆恍枰獌?nèi)置Map這一結(jié)構(gòu)，因?yàn)樗梢酝ㄟ^(guò)列表等結(jié)構(gòu)組合構(gòu)建出來(lái)，但是很顯然，Map這一概念的直接存在對(duì)我們來(lái)說(shuō)是方便的，是經(jīng)濟(jì)的，是有效的。我們?cè)谒伎嫉臅r(shí)候并不需要考慮它是采用List實(shí)現(xiàn)還是采用Set實(shí)現(xiàn)，或者任何它本身的構(gòu)造結(jié)構(gòu)。這一概念在我們的思想中成為某種原子化的東西。

    那么，我們到底需要構(gòu)建哪些概念，才能夠最方便的基于這些概念應(yīng)對(duì)萬(wàn)千應(yīng)用系統(tǒng)的開(kāi)發(fā)呢。 這是我們需要在結(jié)構(gòu)空間作出探索的。 這里的思維方向不是把系統(tǒng)推向某種純粹化，某種極致的簡(jiǎn)單化，而是讓它更加物理化，揭示出更多的層次，更加關(guān)切在物理約束情況下如何實(shí)現(xiàn)靈活性的最大化。一種概念在物理上如果被證明能夠在很多場(chǎng)景下成為不變的基元，則它便是有價(jià)值的，是可以進(jìn)行物理詮釋的。

   很多人習(xí)慣于接受語(yǔ)言存在的現(xiàn)實(shí)，接受設(shè)計(jì)后的結(jié)果，但是作為程序語(yǔ)言設(shè)計(jì)者，他們又是如何工作的？他們是否真的是從純粹的數(shù)學(xué)關(guān)系推演得到所有的語(yǔ)法特征，還是他們預(yù)先已經(jīng)在心中設(shè)定了應(yīng)該出現(xiàn)的語(yǔ)法特征，然后去尋找它的數(shù)學(xué)表達(dá)，只是借此清除思維中潛在存在的矛盾性呢？

    語(yǔ)言中存在的所有特征是經(jīng)過(guò)全局考慮的，是清除了所有概念的矛盾沖突的。但是在現(xiàn)實(shí)中，我們偶然構(gòu)造的結(jié)構(gòu)卻可能是局限于當(dāng)下的信息構(gòu)造的，因此它們相會(huì)的時(shí)候，可能會(huì)出現(xiàn)不協(xié)調(diào)，可能會(huì)出現(xiàn)結(jié)構(gòu)障礙。例如同樣是關(guān)閉操作，有些人命名為close, 另一些人命名為destroy. 可能一個(gè)具有額外參數(shù)，另外一個(gè)沒(méi)有。這里可能需要一種adaptor接口的封裝，也可能使用ruby那種method-missing的動(dòng)態(tài)判斷。對(duì)于更加錯(cuò)綜復(fù)雜的結(jié)構(gòu)問(wèn)題，其解決方案就不是那么顯然的了，但這并不意味著我們無(wú)辦法可想。究竟設(shè)計(jì)何種結(jié)構(gòu)邊界才能最小化結(jié)構(gòu)融合時(shí)所要付出的代價(jià)呢？結(jié)構(gòu)被識(shí)別并表征出來(lái)以后，是否允許它在一定范圍內(nèi)有所變形？在變形中我們需要保持的拓?fù)洳蛔兞渴鞘裁矗拷Y(jié)構(gòu)動(dòng)態(tài)調(diào)整的時(shí)候，我們是否需要定義調(diào)整的物理代價(jià)，是否能夠定義某種動(dòng)力學(xué)？

   我所闡述的只是在計(jì)算機(jī)理論中從數(shù)學(xué)視角向物理視角的轉(zhuǎn)換，它不是必然給你提供某種超越當(dāng)下的能力，而是提供一種不同的眼光看待所有的一切。視角變換后，我們發(fā)現(xiàn)了一些新的命題，而在原先的視角下在我們的話語(yǔ)體系中原本是無(wú)法表達(dá)這些命題的。串行程序假設(shè)了只有1顆CPU, 而函數(shù)式語(yǔ)言假設(shè)了可以有無(wú)限多個(gè)CPU, 你不覺(jué)得1至無(wú)窮之間缺點(diǎn)什么嗎。我們可以創(chuàng)造一些東西把1至無(wú)窮之間的空白補(bǔ)齊，概念空間是連續(xù)的。
 

    沒(méi)有人否認(rèn)抽象的意義，但是抽象是否就是抽象到無(wú)窮大，這是個(gè)可以明確定義的問(wèn)題，也是數(shù)學(xué)領(lǐng)域正在解決的問(wèn)題。在我們的思考中沒(méi)有明確定義何處是邊界， 沒(méi)有明確的限制，這便是導(dǎo)向無(wú)窮的一種思維方式，它和現(xiàn)實(shí)中是否真的允許消耗無(wú)限多的資源，創(chuàng)建無(wú)限多的對(duì)象無(wú)關(guān)。當(dāng)我們認(rèn)為自己明白了終極的意義，明白 了一種推向無(wú)窮的抽象，這并不是理解了世界的全部，我們?nèi)匀灰靼兹绾谓鉀Q一些更加小范圍，但是卻又普遍發(fā)生的事情。
例如現(xiàn)在我的系統(tǒng)中只需要10個(gè)相互依賴的線程，如果我們定死了10這個(gè)數(shù)字，顯然我們可以發(fā)展一種這個(gè)領(lǐng)域特有的高效的一些算法結(jié)構(gòu)。而抽象到通用語(yǔ)言 中的時(shí)候，顯然我們只能假設(shè)線程數(shù)是任意大，或者是充分大的，而無(wú)法充分利用10這一領(lǐng)域信息，因此在這個(gè)意義上我說(shuō)通用語(yǔ)言不是有效的。
說(shuō)到10這個(gè)確定的數(shù)字，不過(guò)是一種極端化的比喻。我常說(shuō)概念是連續(xù)的，并不是非此即彼的，因此并不是從一種普遍情況到一種最特殊的情況之間不再有其他情 況了。在這中間環(huán)節(jié)，存在著非常深刻的復(fù)雜的物理事實(shí)。但是這些事實(shí)卻又是某種有限性向我們揭示出來(lái)的。（請(qǐng)不要把這里的有限性理解為算術(shù)中的10以內(nèi)）

現(xiàn)在來(lái)一個(gè)理論推演吧：
1. 任何系統(tǒng)都在一定約束下運(yùn)行，即它們需要符合某些約束條件
2. 通用語(yǔ)言描述了某些結(jié)構(gòu)，但是這些結(jié)構(gòu)是充分通用的，能夠應(yīng)用到盡可能廣泛的領(lǐng)域的
3. 線程數(shù)=10這個(gè)約束過(guò)份特殊，顯然通用語(yǔ)言是不會(huì)考慮這個(gè)約束。實(shí)際上目前在通用語(yǔ)言設(shè)計(jì)中，無(wú)限資源假定基本都是默認(rèn)的。
4. 我們承認(rèn)某些現(xiàn)實(shí)的約束通用語(yǔ)言是不會(huì)考慮的
5. 在最特殊的，明顯不會(huì)考慮的約束以及非常通用，一般通用語(yǔ)言必然考慮的約束之間，是否存在著更多的，非平凡的結(jié)構(gòu)呢
6. 假如10年以內(nèi)我們所有的硬件都只能支持10個(gè)內(nèi)核，在我的產(chǎn)品研發(fā)中假定10個(gè)線程有問(wèn)題嗎。難道我在開(kāi)發(fā)的時(shí)候就不再需要抽象了嗎。我在其他方面仍然是需要建立抽象的。
7. n個(gè)抽象約束+1個(gè)具體約束，以及 n個(gè)無(wú)限約束+1個(gè)有限約束 仍然是有效的抽象形式。原諒我在這里又使用了有效一詞，它真的很難理解嗎。
8. 不是在我們的思維中存在著具體的或者有限的物理量,就意味著這種思維是不抽象的.

函數(shù)式語(yǔ)言或者任何一種其他我們已知的與Turing機(jī)等價(jià)的語(yǔ)言，它們?cè)谀撤N數(shù)學(xué)的含義上說(shuō)是"沒(méi)有差別的"。但是在我們的實(shí)際使用過(guò)程中，顯然我們是 能夠感受到它們之間的結(jié)構(gòu)差異的。否則那些不斷發(fā)明新的函數(shù)式語(yǔ)言的人的大腦都進(jìn)水了嗎？在具體使用中，總有人偏好這個(gè)語(yǔ)言,有人偏好那個(gè)語(yǔ)言, 總是某種情況下應(yīng)用某個(gè)語(yǔ)言會(huì)方便一些,另一些麻煩一些。難道在所有函數(shù)式語(yǔ)言中開(kāi)發(fā)類似ErLang解決的那些程序結(jié)構(gòu)都是一樣方便的嗎？

有些人的論調(diào)是無(wú)論啥都逃不出函數(shù)式語(yǔ)言的思想。但是假如現(xiàn)在限定你必須使用java語(yǔ)言來(lái)開(kāi)發(fā)商業(yè)應(yīng)用，難道你罷工嗎？如果你不使用函數(shù)式語(yǔ)言，你所做 的工作就不是程序工作了？你所解決的難道不是程序結(jié)構(gòu)問(wèn)題了嗎？現(xiàn)在就是有一個(gè)結(jié)構(gòu)問(wèn)題要解決, 它是和語(yǔ)言無(wú)關(guān)的. 語(yǔ)言提供了就可以直接用, 語(yǔ)言沒(méi)有提供我們可以寫代碼構(gòu)造. 難道除了語(yǔ)言直接體現(xiàn)的結(jié)構(gòu)之外, 程序本身就無(wú)法構(gòu)造任何具有通用價(jià)值的結(jié)構(gòu)了嗎？

我在說(shuō)到函數(shù)式語(yǔ)言的時(shí)候，基本的態(tài)度只是說(shuō)不要太沉迷于一種特殊的抽象方式，應(yīng)該多看看別的視角。在不同的情況下存在著做事情的不同的最優(yōu)方式。思維中不要只允許永遠(yuǎn)，而容不下現(xiàn)在。

非此即彼，天下唯我,是我們思維中經(jīng)常陷入的一個(gè)誤區(qū)。現(xiàn)在計(jì)算機(jī)領(lǐng)域所謂的理論主要是基于數(shù)學(xué)視角的，沒(méi)有考慮物理世界因?yàn)槲覀冇^察的有限性，因?yàn)橘Y源 的有限性所造成的種種約束，此外數(shù)學(xué)中目前也沒(méi)有考慮到物理世界真實(shí)的各種復(fù)雜性的存在。在我們想到一種計(jì)算機(jī)理論的時(shí)候，圖像過(guò)于簡(jiǎn)單化，這種簡(jiǎn)單化被 認(rèn)為是優(yōu)美的全部。其實(shí)我們應(yīng)該思維更加開(kāi)放一些。