canonical

 Ivar Jacobson 在其著作"Aspect-Oriented Software Development with Use Cases"中將AOP(Aspect-Oriented Programming)上升為一種貫穿軟件開發全生命周期的設計技術，由建筑學的隱喻引出了decoration overlay（existion + extensions）的策略。在建筑學中，首先基礎設計圖規劃了房間的空間劃分，電氣工程師基于這張基礎圖決定電氣設施排布圖，而裝修設計師可能依據基 礎設計圖決定裝修方案。所有這些擴展(extension)設計圖疊加到基礎設計圖之上構成的最終設計方案決定了房間每個部分的最終功能。這也有些象是中 國傳統彩畫的印制技術：每次印刷一種顏色，多重疊加之后構成成品。
 Jacobson指出傳統的面向對象設計將會產生兩個問題: tangling和scattering。tangling指的是一個組件要參與多個業務， 因而組件具有的功能是所有業務所需功能的超集， 雖然很多功能只在某一項特殊業務中使用，并無重用需求， 但組件開發者在設計和開發時卻無法局域化， 必須同時理解所有需求。 scattering指的是某一特定需求可能需要多個組件協同操作來完成， 這要求實現代碼分散在多個組件之中，而沒有一個整體概念。這兩個問題的產生是因為缺乏一種全局的separation of concern。AOSD(Aspect-Oriented Software Development)正是Jacobson指出的解決方案。
 AOP 在基本的技術含義上可以認為是實現了基本動作與修飾語之間的正交分解，Jacobson將其擴大化為基礎架構(architecture)與擴展 (extension)之間的正交分解，將architecture centric設計與use case, AOP等概念聯系起來。 Jacobson指出程序中在兩個不同的層面上存在著獨立的正交分解結構，一個是組件結構（具體化為Class），一個是業務邏輯結構(具體化為use case)。The element structure identifies where elements of the system are located in the element namespace. It structures the elements hierarchically in terms of layers, packages, classes, and the features within these classes. The use case structure defines how you overlay functionality onto the element structure. 因為use case需要多個組件的參與，當我們將use case結構疊加到組件結構之上時就會產生tangling和scattering。Jacobson指出每一個use case是一個功能切片(slice), 并為use case中的概念找到了相應的程序對應物，因而可以在后期通過AOP技術將use case slice織入到系統基礎架構中，從而構成一種全程建模技術。use case中的generalization可以對應于對象繼承， 包含(include)可以對應于對象組合和調用, 而擴展(entension)就對應于AOP。某些use case具有共性，如常見的CURD(Create,Update,Read, Delete)操作，可以被抽象為參數化的use case, 這可以對應于模板(template)概念。
 我在數年前也注意到了tangling現象，一些類的功能不斷膨脹而完備性卻始終無法保證。在概念 上我們可以將功能集正交分解為不同的接口，但實現時卻需要集中實現，因為它們對應于同一個對象實體。當時我主要通過interface的 aggregation來解決這個問題，例如采用IDynamicInterfaceSupport接口，動態注入接口實現.
     interface IDynamicInterfaceSupport{
      Object queryInterface(Class interfaceClass, Object user);
   void addInterface(Class inf, Object impl);
  }
  使用接口來處理這些問題很多時候效果并不好。首先接口要求預先有一個明確的定義，要求明確標注出功能的獨特性，這樣在合成的時候具有一定的困難。例如在C ++中我們將對象如果分解為大量的接口，則使用的時候需要不斷的queryInterface，十分麻煩。只有弱化種類型區別，才能消除這種合成障礙。例 如在腳本語言中，我們可以自由的使用對象的所有函數，而不需要知道它是哪個接口具體提供的。我在C++中主要通過代碼生成技術構造一個合成代理對象來解決 這個問題，在java中主要使用interface的extends。接口意味著某個明確的定義，而模板(template)在這方面的要求則弱得多，模 板只要求對象具有需要的函數，有時可以做到更好的可重用性。接口的另一個困難在于無法捕獲cross-cutting concern。在沒有AOP的代碼注入技術之前我們主要是通過繼承來構造擴展點，這些都是所謂侵入性(intrusive)的設計，要求不必要的附加層 次，而且具有很強的事前假定。
  在jsplet中WebObject的注冊格式可以認為是實現了action slice。WebObject具有的全部功能可以通過多個action集合組裝出來，而這多個action slice共享一個對象名和成員變量空間。
 <type name="Demo">
  <!-- 如果未指定object, 則缺省為WebObject類型 -->
  <object class="demo.MyWebObject" />
  <listener>
   <url-listener url="/demo/ActionSliceA.jsp" />
   <url-listener url="/demo/ActionSliceB.jsp" />
  </listener>
 </type>
       在tpl模板中，因為xml格式定義了明確的結構信息，所以我們比較容易的定義擴展點，并注入新的功能，例如<c:decorator>標簽。這也類似于AOP的操作。