1。隨處可見猜想。
在未來的軟件開發過程中，AOP將以一種基礎編程能力的形式出現，與OOP共同發展，成為主流開發環境的一個組成部分。而目前為止，AOP只是作為一種開發工具、或運行時代碼而存在。到了那個時候，可能沒有哪個產品聲稱：“我使用了AOP”，因為沒有哪個產品沒有使用AOP，就像現在沒有哪個產品沒有使用OOP一樣。就算你的源代碼中沒有應用到編程語言的AOP能力，你也可能調用了某個應用了AOP的基礎庫。事實上，AOP之父Kiczales認為AOP可能首先在操作系統上有一定規模的應用。

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

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

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

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

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

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

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

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