僕が考えるAOPの適用ポリシー

Javaナイトセミナー(Vol.3)」で宿題(?)だった「AOPの適用」について,僕なりの意見を以下に述べようと思う。 AOPはトランザクションやロギング,ベースとなる機構で必要な前処理などを適用することが代表例なのは揺るぎのない事実だろう。そして,AOPのこれらの処理に対する適用は,プログラマからテクニカルで毎度毎度のお決まりコーディングを削減することができ,さらに継承やTemplateパターンなどを駆使することなく前処理を実行できるため,対象のクラスを汚す必要がない(何らかのクラスを継承しなくて済むなど)という利点をもたらしてくれる。 しかし,業務的に必要な前処理や共通的な処理の実行にAOPを使用すると,本来業務処理をコーディングするプログラマはAOPに関する知識を必要としなくて済むはずなのに,業務処理の記述に比較的難解な技術となるAOPを覚えてもらうことになる。敷居が高くなるだけでなく,複雑さの向上は品質の低下を招く。これを本末転倒という。さらに,AOPの業務処理まで及ぶ多用は「RDBMSによるトリガーの多用」と同じレベルの動作に関する追跡可能性の低下,つまりスパゲッティなソフトウェアとなる。もはやコード上で動作を追うことは不可能,動かしてみても再現しない不具合が発生し,見えない敵との戦いが待ち受けることになる。 まとめてみると,AOPの適用ポイントとして,

  • 業務に関する処理には極力適用しない。

  • 業務に適用する場合は,業務に変更が生じてもAOPの組み替えが発生しないことが保証される箇所にのみ適用する。

  • 業務に適用する場合は,AOPのインターセプタ内で条件分岐を行わず,AOP対象のメソッドは必ず呼ぶようにする。

  • ベースの機構に適用する場合は,できるだけレイヤ間の結合部分のみの適用に留める。 というような観点で設計を行うと,余計な苦労を少なくすることができるのではないだろうか。 観点が足りないぞ!,間違った観点じゃないのか!といった遠慮のない突っ込みは控えめに,そうだ!その通りだ!という突っ込みは盛り沢山頂けると嬉しい。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて