DIとアスペクト指向は、似ているところもある。
どちらも、後から実体を注入することが出来る点だ。
DIは、「依存性の注入」なので、出来るのはもちろんだけど、
アスペクト指向でも、aroundとかを使うと、後からプログラムの実体を入れることが出来る。
しかし、決定的な違いがある。
DIは、実体を後から入れるが、構造は、前もってinterfaceで定義し、実体とインターフェースの関係を、設定ファイル（Springだとbean-conf.xml,Seasar2の場合diconファイル）で記述してしまう点だ。したがって、注入するクラスは、このインターフェースの構造に従う＝束縛される。
一方、アスペクト指向は、インタータイプ宣言などにより、利用するメソッドや属性を追加させ、構造を変えてしまうことも出来る＝束縛されない。
このような「アスペクト指向の何でも出来てしまう自由」は、（自己責任という名において）危険性と紙一重の関係にあり、あまりにひどい変更を行ってしまうと、コンパイルエラーになることすらありえる。
したがって、フレームワークの「ハリウッドの法則」のような、拘束をかけたい場合は、自由なアスペクト指向ではない、DIのほうが向いている。
ここで、昨日の状態遷移との問題がある。
アスペクト指向では、遷移すら変えてしまう。優先順位を間違えれば、遷移の順序も変えてしまうし、ポイントカットをミスれば、不必要なときに呼び出しをしてしまったりする。
このことは、派生開発などにアスペクト指向を使うことに対して、障害となる。
アスペクト指向を利用すれば、構造も振る舞いも変えられる。
そこで、これを利用して、既存のシステムに機能追加をすることが考えられる。
しかしこの場合、設計上で想定しなかった遷移が起こる可能性がある。
この点をどうするかを考えないといけない。
アクセス
トータル
ランキング
