1。隨處可見猜想。
在未來的軟件開發(fā)過程中，AOP將以一種基礎(chǔ)編程能力的形式出現(xiàn)，與OOP共同發(fā)展，成為主流開發(fā)環(huán)境的一個(gè)組成部分。而目前為止，AOP只是作為一種開發(fā)工具、或運(yùn)行時(shí)代碼而存在。到了那個(gè)時(shí)候，可能沒有哪個(gè)產(chǎn)品聲稱：“我使用了AOP”，因?yàn)闆]有哪個(gè)產(chǎn)品沒有使用AOP，就像現(xiàn)在沒有哪個(gè)產(chǎn)品沒有使用OOP一樣。就算你的源代碼中沒有應(yīng)用到編程語言的AOP能力，你也可能調(diào)用了某個(gè)應(yīng)用了AOP的基礎(chǔ)庫。事實(shí)上，AOP之父Kiczales認(rèn)為AOP可能首先在操作系統(tǒng)上有一定規(guī)模的應(yīng)用。

2。語言級猜想。
AOP的真正實(shí)現(xiàn)是在一個(gè)特定的語言基礎(chǔ)上的。比如數(shù)年之后，人類開始普遍使用K語言（K是J的后一個(gè)字母），K語言在語言本身上就可以編織和橫切。此時(shí)AOP才得到真正的成熟，因?yàn)槌绦騿T在編寫代碼時(shí)可能根本不知道自己用到的是曾經(jīng)的OO還是現(xiàn)在的AO，只有了解K語言虛擬機(jī)構(gòu)造和背后實(shí)現(xiàn)的人才知道。但是，可能由于人固有的思維方式的問題吧，AOP仍然不會比OOP要使用的更多，甚至有可能仍然是Kiczales所提到的15% Solution！但是，從語言的角度去實(shí)現(xiàn)AOP也許會給人類的編程觀念帶來巨大的變化，這種變化就像OO所帶來的一樣。

3。存在AOD/AOA猜想。
OOP對人類的影響遠(yuǎn)不如它的兩個(gè)弟弟OOA/OOD，后兩者已經(jīng)為整個(gè)軟件開發(fā)行業(yè)帶來了一次意義深遠(yuǎn)的革命，它至少使得全世界開發(fā)團(tuán)隊(duì)的人數(shù)擴(kuò)大了10倍，開發(fā)工具和平臺的復(fù)雜程度增加了10倍，完成客戶某些簡單要求的成本降低了90%，唯一的遺憾的是，軟件開發(fā)的效率幾乎沒有數(shù)量級上的變化（依據(jù)《沒有銀彈》）。既然存在AOP，我們猜想也會存在AOD/AOA，比如會存在面向方面的重構(gòu)手段，面向方面的設(shè)計(jì)模式，面向方面的最佳實(shí)踐，面向方面的過程管理，以及在UML的未來版本中看到為面向方向而專門做的改進(jìn)，甚至添加一個(gè)新的UML圖類型。當(dāng)這些東西都產(chǎn)生的時(shí)候，AOP才真正發(fā)展到了鼎盛時(shí)期。

4。可執(zhí)行用例猜想。
AOP是一個(gè)廣泛適用的充滿想象空間的新技術(shù)，但是目前人們對AOP的研究方向過于狹窄，大部分聲稱正在研究AOP的開源項(xiàng)目其實(shí)是把AOP當(dāng)成一個(gè)輔助工具來使用，這些項(xiàng)目中又有相當(dāng)一部分是在做企業(yè)開發(fā)環(huán)境下的容器，他們并沒有針對AOP本身進(jìn)行開發(fā)。事實(shí)上，依照J(rèn)acbson的說法，AOP將直接導(dǎo)致軟件的開發(fā)分為兩種形式——對模塊的開發(fā)和對用例的開發(fā)，現(xiàn)在的用例僅僅是圖紙，必須要轉(zhuǎn)變?yōu)镺O代碼才能執(zhí)行，但是一旦有了AOP，AOP可以直接依據(jù)用例的定義，將多個(gè)不同的模塊（可能來自不同的開發(fā)單位）連接起來，形成方面，而方面本身是可以執(zhí)行的（語言級猜想），所以用例也就不再是圖紙而是可以執(zhí)行的了。這對于以UML為核心的現(xiàn)代軟件過程來說，是個(gè)極好的信號。

5。標(biāo)準(zhǔn)化猜想。
OO的成功經(jīng)驗(yàn)告訴我們，要想取得最后的勝利，就要一致對外，統(tǒng)一了內(nèi)部的概念，剩下的爭論就只有實(shí)現(xiàn)問題了。我個(gè)人認(rèn)為，多數(shù)OOP語言在概念上都是一致的，這種概念被語言學(xué)稱之為語義，多數(shù)OOP的語義來自Smalltalk和C++這些早期嘗試者，少數(shù)來自Java這種在技術(shù)的成熟期涌現(xiàn)出的商業(yè)產(chǎn)品。AOP目前還面臨著這個(gè)問題。業(yè)界對AOP的標(biāo)準(zhǔn)化過程有兩個(gè)猜想，一是由AspectJ領(lǐng)頭，各大AOP實(shí)現(xiàn)都以AspectJ的語義作為研究問題的基本用語，設(shè)計(jì)和實(shí)現(xiàn)沿用現(xiàn)在的思路；另一個(gè)猜想是由權(quán)威組織，（開源、商業(yè)、或全球研究組織），如Eclipse/IBM/OOPSLA等等拿出一個(gè)統(tǒng)一的AOP語義內(nèi)核，所有AOP項(xiàng)目都以該內(nèi)核為基礎(chǔ)開發(fā)。Java虛擬機(jī)是前一種思路的成功案例，后者則以XML為代表。

6。全靜態(tài)編織猜想。
下面討論一個(gè)實(shí)際的技術(shù)問題。時(shí)下多數(shù)AOP項(xiàng)目采用的編織技術(shù)無外乎兩種：靜態(tài)編織和動態(tài)編織。前者是指在編譯前（預(yù)編譯期）、編譯期、和編譯后編織，后者是指在運(yùn)行期編織。Kiczales認(rèn)為雖然沒有明顯的技術(shù)缺陷，但動態(tài)編織可能會面臨一些發(fā)展遠(yuǎn)景的問題，他稱之為“軟件的演化問題”。不知道我對大師觀點(diǎn)的理解是不是準(zhǔn)確，我認(rèn)為由于被編織的代碼是在變化（發(fā)展）中的，我們總是希望這種變化對編織本身的影響最小，這時(shí)靜態(tài)編織面臨的問題最多就是重新編譯，而動態(tài)編織可能不會那么簡單。此外，全靜態(tài)編織會導(dǎo)致另一個(gè)優(yōu)點(diǎn)——這聽起來有點(diǎn)奇怪——就是能力較弱，因?yàn)槿o態(tài)編織繼承了OO語言本身的約束，比如Java的約束和.NET之CLR的約束等等，這對于更規(guī)范的使用開發(fā)利器是大有好處的。“應(yīng)該對人類準(zhǔn)備大規(guī)模應(yīng)用的每一種新工具小心鉗制。”

7。AOP的誕生之迷猜想。
Kiczales先生在從事AOP的研究和開發(fā)之前也曾接觸過其它對OOP的改良研究，其中包括反射和元對象技術(shù)。事實(shí)上，心平氣和的說，后兩者的變通能力和靈活程度都在前者之上，但是正因?yàn)槿绱耍Z言學(xué)家們認(rèn)為，這些技術(shù)并不能有效的改善OOP的弊端，甚至還有可能引狼入室，帶來新的“狼人問題”。后來，當(dāng)Kiczales發(fā)現(xiàn)AOP時(shí)，他明白這才是人們真正需要的，他認(rèn)為他們抓住了問題的咽喉。時(shí)至今日，AOP的實(shí)現(xiàn)技術(shù)已經(jīng)千姿百態(tài)，百家爭鳴了，但是，AOP創(chuàng)立之初的種種想法也在這種百花爭艷中漸漸被人們遺忘，現(xiàn)在利用反射、元對象技術(shù)以及種種雙刃劍式的技術(shù)來實(shí)現(xiàn)AOP的想法已經(jīng)像爭搶參院席位一樣爭奪市場的認(rèn)可，這是事物的發(fā)展還是理想的倒退？AOP何時(shí)才能回歸它的本原？上天為它安排的命運(yùn)究竟如何，我們拭目以待。

最近，我和我的幾個(gè)朋友正在組織一批開源斗士們合作編寫AOP.NET，這是一個(gè)開源軟件，在博客園上可以看到部分有關(guān)該項(xiàng)目的消息。但是由于種種原因，我們對一些基本的問題還沒有達(dá)成共識，本文來自我對AOP的一貫看法，也是我對社團(tuán)里很多問題的一個(gè)集中性回答吧。

開源泡泡
（轉(zhuǎn)載本文需注明出處：Brian Sun @ 爬樹的泡泡[http://www.aygfsteel.com/briansun]）