軟件開發(fā)作為一種工程技術(shù)，它所研究的一個(gè)重點(diǎn)就是如何才能有效降低軟件產(chǎn)品的研發(fā)成本。在這一方向上，組件技術(shù)取得了空前的成功。它所提供的基本圖景是
像搭積木一樣從無到有的組裝出最終的產(chǎn)品。在某種意義上，這是對現(xiàn)代建筑工業(yè)的模仿和致敬。新材料，預(yù)制件，框架結(jié)構(gòu)，這些建筑學(xué)的進(jìn)展在軟件領(lǐng)域被一一
復(fù)制，建筑工地上的民工自然也成為了程序員們學(xué)習(xí)的楷模。畢竟，在組件的世界中碼代碼，基本上也是一種“搬磚”的行為。
值得慶幸的是，軟件開發(fā)作為一種智力活動(dòng)，它天生具有一種“去民工化”的傾向。信息產(chǎn)品有著與物質(zhì)世界產(chǎn)品完全不同的抽象本質(zhì)。在物理空間中，建造100
棟房屋，必須付出100倍的努力，老老實(shí)實(shí)的干上100遍。而在概念空間中建造100棟房屋，我們卻可以說其他房屋與第一棟一模一樣，加點(diǎn)平移旋轉(zhuǎn)變換即
可。一塊磚填了地基就不能用來蓋屋頂，而一段寫好的代碼卻可以在任何可用的場合無損耗的被使用。一棟建好的房屋發(fā)現(xiàn)水管漏水要大動(dòng)干戈，而在完成的軟件中
補(bǔ)個(gè)局部bug卻是小菜一碟。在抽象的世界中有效的進(jìn)行生產(chǎn)，所依賴的不應(yīng)該是大干,苦干的堆砌，而應(yīng)該是發(fā)現(xiàn)某種可用于推導(dǎo)的原理，基于這些原理，輸入
信息可以立刻轉(zhuǎn)換為最終的結(jié)果，而不需要一個(gè)逐步構(gòu)造的過程。即我們有可能超越組裝性生產(chǎn)，實(shí)現(xiàn)某種類似于數(shù)學(xué)的原理性生產(chǎn)。http://canonical.javaeye.com/blog/325051
代碼復(fù)用是目前軟件業(yè)中鼓吹降低生產(chǎn)成本的主要口號(hào)之一。但是在組件技術(shù)的指向下，一般所復(fù)用的只是用于構(gòu)建的磚塊，而并不是某種構(gòu)造原理。即使在所有信
息已經(jīng)確定的情況下，我們?nèi)匀徊豢赡軓男枨罅⒖痰玫娇蓤?zhí)行的產(chǎn)品。很多代碼即使我們在想象中已經(jīng)歷歷在目，卻仍然需要一行行把它們謄寫下來。當(dāng)我們發(fā)現(xiàn)系
統(tǒng)中已經(jīng)沒有任何組件值得抽象的時(shí)候，仍然留下來眾多的工作需要機(jī)械化的執(zhí)行。代碼復(fù)用的理想國距離我們?nèi)匀环浅５倪b遠(yuǎn)。
子例程(subroutine)是最早的代碼重用機(jī)制。這就像是將昨天已經(jīng)完成的工作錄制下來，在需要的時(shí)候重新播放。函數(shù)(function)相對于子
例程更加強(qiáng)大。很多代碼看起來并不一樣，但是如果把其中的差異部分看作是變量，那么它們的結(jié)構(gòu)就可以統(tǒng)一了。再加上一些判斷和循環(huán)，很多面目迥異的東西其
實(shí)是存在著大量共享信息的。面向?qū)ο蠹夹g(shù)是一次飛躍性的發(fā)展。眾多相關(guān)信息被打包到一個(gè)名稱（類型）中，復(fù)用的粒度和復(fù)雜度都大大提升。派生類從基類繼
承，可以通過重載實(shí)現(xiàn)對原有代碼的細(xì)致調(diào)整。不過，這種方式仍然無法滿足日益增長的復(fù)用需求。很多時(shí)候，一個(gè)名稱并不足以標(biāo)定我們最終需要的代碼結(jié)構(gòu)，在
實(shí)際使用的時(shí)候還需要補(bǔ)充更多的信息。類型參數(shù)化，即泛型技術(shù)，從事后的角度看其實(shí)是一種明顯的解決方案。根據(jù)參數(shù)動(dòng)態(tài)的生成基類自然可以吸納更多的變
化。經(jīng)歷了所謂Modern
C++的發(fā)展之后，我們現(xiàn)在已經(jīng)非常明確，泛型并非僅僅能夠?qū)崿F(xiàn)類型共變，而是可以從類型參數(shù)中引入更豐富的結(jié)構(gòu)信息，它的本質(zhì)是一種代碼生成的過程。http://canonical.javaeye.com/blog/57244
認(rèn)清了這一點(diǎn)，它的擴(kuò)展就非常明顯了
BaseClass<ArgClass> --> CodeGenerator<DSL>
DSL（或者某種模型對象）相對于普通的類型(Class)，信息密度要大很多，它可以提供更豐富也更完整的輸入信息。而CodeGenerator也不必拘泥于基礎(chǔ)語言本身提供的各種編譯機(jī)制，而是可以靈活應(yīng)用各種文本生成技術(shù)。http://canonical.javaeye.com/blog/309395
CodeGenerator在這里所提供的正是根據(jù)輸入模型推導(dǎo)出完整實(shí)現(xiàn)代碼的構(gòu)造原理。
現(xiàn)在很多人熱衷于開發(fā)自己的簡易代碼生成工具，這些工具也許可以在簡單的情形下減輕一些體力工作，但是生成的代碼一般不能直接滿足需求，仍然需要手工執(zhí)行
大量的刪改工作。當(dāng)代碼生成之后，它成為一種固化的物質(zhì)產(chǎn)品，不再能夠隨著代碼生成工具的改進(jìn)而同步改進(jìn)，在長期的系統(tǒng)演化過程中，這些工具并不一定能夠
減少累積的工作量。
修正過程 ==> CodeGenerator<DSL>
為了改進(jìn)以上代碼生產(chǎn)過程，一些人試圖在CodeGenerator中引入越來越多的可配置性，將各種變化的可能內(nèi)置在構(gòu)造原理中。顯然這會(huì)造成CodeGenerator的不正常的腫脹。當(dāng)更多的偶然性被包含在原理中的時(shí)候，必然會(huì)破壞原理的簡單性和普適性。
輸入信息 + 一段用于推導(dǎo)的原理 + 修正補(bǔ)充 = 真實(shí)模型
必須存在[修正補(bǔ)充]這一項(xiàng)才能維持以上方程的持久平衡。
為了擺脫人工修正過程，將模型調(diào)整納入到概念世界中，我們需要超越繼承機(jī)制的，更加強(qiáng)大的，新的技術(shù)手段。其實(shí)在當(dāng)前的技術(shù)背景下，這一技術(shù)已經(jīng)是呼之欲出了。這就是AOP, Aspect Oriented Programming。http://canonical.javaeye.com/blog/34941
Biz ==[AOP extends]==> CodeGenerator<DSL>
繼承僅僅能夠?qū)崿F(xiàn)同名方法之間的簡單覆蓋，而AOP所代表的技術(shù)原理卻是在代碼結(jié)構(gòu)空間中進(jìn)行任意復(fù)雜的刪改操作,它潛在的能力等價(jià)于人工調(diào)整。
為了實(shí)現(xiàn)上述生產(chǎn)模式，需要對編程語言，組件模型，框架設(shè)計(jì)等方面進(jìn)行一系列改造。目前通用的AOP實(shí)現(xiàn)和元編程技術(shù)其實(shí)并不足以支持以上模式。http://canonical.javaeye.com/blog/275015
這一生產(chǎn)模式將會(huì)如何演化，也是一個(gè)有趣的問題。按照級(jí)列理論，我們立刻可以得到如下發(fā)展方向：
Context0 + DSL1 + EXT0 = DSL0
Context1 + DSL2 + EXT1 = DSL1
http://canonical.javaeye.com/blog/33824
Witrix平臺(tái)中BizFlow可以看作是對DaoWebAction的修正模型，但是它本身具有完整的意義，可以直觀的被理解。在BizFlow的基礎(chǔ)上可以逐步建立SeqFlow，StateFlow等模型。http://canonical.javaeye.com/blog/126467
現(xiàn)在有些人試圖深挖函數(shù)式語言，利用模式匹配之類的概念，做符號(hào)空間的全局優(yōu)化。但是我們需要認(rèn)識(shí)到通用的機(jī)制是很少的，能夠在通用語言背景下被明確提出
的問題更是很少的。只有在特定領(lǐng)域中，在掌握更多局部信息的情況下，我們才能提出豐富的問題，并作出一定背景下的解答。DSL的世界中待做的和可做的工作
很多。http://canonical.javaeye.com/blog/147065
對于程序員而言，未來將變得越來越豐富而復(fù)雜，它將持續(xù)拷問我們的洞察力。我們不是一行行的編寫代碼，把需求一條條的翻譯到某種實(shí)現(xiàn)上，而是不斷發(fā)明局部的生產(chǎn)原理，依靠自己制定的規(guī)則在抽象的空間中不斷的創(chuàng)造新的表象。