AOP Here, There and Everywhere

Kazzzの「JとNの狭間で」より

AOPで実施する処理の注入の手法は現時点で可能な技術により、大きく二つに分類できる。

  • コードの命令呼び出しの前後をインターセプトして、アドバイスを割り込ませる方式
  • コード自身を書換えて、アドバイスを任意のポイントにウィーブ(編み込む)する方式

どちらも、特に後者はテストが完了して動作が検証されたコードを変えることになるのは、確かにそうであり、動的にAOPが適用できる環境では簡単にコードの改竄が可能になるのは否定できない。しかし、AOP(な考えかた)のメリットは氏も認識している訳で、デメリットを技術的に解決したAOP(氏はそれをAOPとは呼ばないかもしれない)が出てくるのだろう。

私も会場にいた一人です.
これについては「オブジェクト指向の定義」に関する混乱に近いものがあるのかもしれませんが,例えば『属性』や『partial class』を見て「ああこれはAOPだ」と思う人もいれば,「これはそれぞれ技術の一種だ」と思う人もいて,Andersは後者の要素還元タイプの立場かなという印象を受けました.「AOP」として実行時に想定外のロジックが割り込んでくることを随分と嫌がっていたご様子.
また,id:NyaRuRu:20060203#p3での萩原さんのセッションでも「アスペクトに注目した分析が有効な領域はあまり広くはない」という話が出ていたのが興味深かったです.有効な領域に挙げられていたもののなかに「フレームワーク」があってなるほどなと思ったのですが,だとすれば「フレームワーク」設計で日々悩んでいる人々が集まるコミュニティでの「AOPの評価」というものがいくらかのバイアスを持っていても頷ける話です.