AOPの危険性

(from J2EE without / Chapter8 Dangers of AOP)

フィールドへのインターセプト

• 通常のアプリケーション開発では不要。
• カプセル化を壊すので危険だから。
• ほとんどはメソッドのインターセプトで代替できる。
• ただし一部特定の場面では使われているのは妥当。JDOのバイトコード拡張やTopLinkのリフレクションでのフィールドアクセスとか。

アスペクトを多量に使いすぎ

• どこに何のアスペクトがかかっているのかわけわからん、という状況はイカン。
• 乱用せずに制約を課して使いましょう
• Rodはそれで問題になったことはないなぁ。用心深いしよく知ってるからね(さすがの自信だ)。
• アスペクトの設定は一箇所にしといた方がよい(SpringではXML設定ファイルでDIコンテナから取ったもの以外はアスペクトはない)

直行性

• 他のアスペクトに依存するアスペクトを書くのはイカン。基本的に、汎用的なアスペクトは独立したものとして書く。
• ただしポイントカットでアスペクトの順序も必要。例えば、トランザクションコンテキストで他のアスペクトを適用するときは、トランザクションアスペクトを一番外に置いたりする場面はある。
• デザインパターン(OberserやChain Of Responsibility)の場合も同じでしょ
• AspectJの「直行ジョインポイントモデル」ってどんなもの？

テスタビリティ

• AOPを使うとテストしにくくなるというのは嘘
• 根本的に重複ロジックを取り除くのがアスペクト。あちこち同じコードがあるよりテストや修正は容易
• ビジネスロジックはアスペクトを気にしなくていいので単体テストはしやすいハズ
• 結合テストではアスペクトや設定を含めてドカーンと全部テスト(EJBを使った場合も同様のハズ)

デバッグ

• AOPを使うとデバッグしにくくなるというのも嘘
• これは、ある程度フレームワーク、ミドルウェアに依存
• アスペクトが多数かかりまくってるとまあ大変かもしれんが
• スタックトレースはきまくりはEJBや何かのツール使った場合も同じ
• 心配性の人は、「垂直のスライス」がお勧め(プロトタイプみたいなので、一本ちゃんと検証してから利用する方法。そいで、必須のアスペクトだけ利用すれば問題ないっしょ)
• 問題はコードが細かく分離されているからソースのあっち、こっちと処理がとんで、見通しがしずらくなることか？手続きからOOに以降していったときと同じ批判？

パフォーマンス

• ジョインポイントの判断にたいていリフレクションが利用されるので、そのコストはかかるかも
• 問題は粒度
• ビジネスオブジェクトへのアスペクトはノープロブレム(粒度は荒く、呼び出し少ない)
• Springは基本ビジネスオブジェクトへのアスペクトなのでノープロブレム
• ちなみにビジネスオブジェクトというのは、EJBでいうところのSLSBみたいなやつ(という修飾を3回以上みた。たしかにクドイ文章多いなとおもった僕)
• 細かい粒度にアスペクトかけるのはパフォーマンスの点でいただけない。例えば永続オブジェクトにかけちゃうと、あれあれ大変(細かくやる場合はAspectJの利用を検討しよう)
• EJBコンテナよりSpringの方が速いって