積読のような。（アスペクト指向に本格的に取り組んでこなかった理由について）
最近、AOP（Aspect Oriented Programming）やアスペクト指向について、盛んに論議する機会が多い。mixi のソフトウェア工学のコミュや知人の BLOG 上など、何度か意見を交わした。最近、Web 上に日本語のドキュメントや書籍なども出回ってきたようなので、これから流行り始めるのであろうか。ただ私自身、まだ AOP に本格的に取り組んだ事が無い。*1最初にこの関連の論文を読んだのは多分、1997年のECOOP論文で発行年度の翌年ぐらいだったと思う。Java での実装の一つ、AspectJ も 2000年前後に初期のバージョンをダウンロードをしてから、何度かダウンロードを繰り返したが結局、実際のプログラムに使う事は無かった。通勤途中、電車の中でも、チュートリアルやマニュアルを何度か読み返した記憶がある。面白い技術だと思いつつ、２年ほど AspectJ の ML にも入ったが、アドレスが変ったのきっかけに自然と退会に成ってしまった。個人的には珍しい事だと思う。何故なんだろう。
ただ、オブジェクト指向と OOP(Object Oriented Programming) が違うように、概念としてアスペクトとプログラム技術としての AOP は別物だと思う。この辺は mixi のコミュでの論議でも話題になった話である。そういう意味で概念として理解してから実装技術として取り組むにはこのアスペクト指向、実は難物だと思う。事実、アスペクト指向の場合、AOP だけがプログラム上でのモジュール化テクニックとして先行した部分があるので、分析や設計の手法が今ひとつ明確でない。私自身 OOP には OOA/D（オブジェクト指向分析・設計）から入った口なので、その辺で違和感を感じたのが、一つの理由かもしれない。しかし、元々アスペクト指向の動機づけの一つとして、システムの非機能要件*2が対象となるアプリケーション内モジュール（ OOP の場合はクラスの事ですが）に分散してコーディングされてしまい、保守性が悪いと言った問題がある。元々 OOA にしろ OOD 対象となるアプリケーション領域（ドメイン）の観点からモデル化を行い、オブジェクトを抽出して分類し、クラスというモジュールを設計して行くものなので、アプリの固有のドメインにあまり関係ない部分は最初は殆ど考慮されない。オブジェクト指向のシステム分析では、実装を意識しては駄目だとも読んだ教科書には書いてあったような気がする。これはオブジェクト指向の先祖の一つが Simula67*3 だからであろうか。実世界を忠実に模擬する。これを是とした考え方にかなり影響されていたように思える。非機能要件は大抵はクラス全体に共通する性質を持たせると言った事を行うので、分析・設計をしていても、やはり至る所で注釈を打つか、モデルに工夫をする必要がある。やはり煩雑で面倒である。しかしその部分だけをまとめては見たものの、では本来のドメインモデルの部分にどう関わるのかと記述は、どのようにすれば良いかまうで検討がつかなかったと思う。
後は、AspectJ のチュートリアルには例として描画用のクラスの例を使い、AOP の何たるかを説明していた。が、私自身は GUI や Window ベースのアプリケーションプログラムは殆ど書かない。もっぱらサーバー側だけなので、今ひとつ馴染めなかった。そんな事も関係あるのかもしれない。無いかもしれないが。
Java などでプログラムをする場合、非機能要件部分（ログ、セキュリティなど）もクラスとしてモジュール化されるが、上記のようにアプリケーションの固有ロジックを担うクラスには、絡みつくような関わり方をする。実際にベタに展開すれば、きれいでないしややこしいと思う。それで、どうしたか。私の場合は Web アプリケーションのプログラムを書くことがもっぱらだったが、フレームワークを利用するのである。ちょうど４〜５年前ぐらいからか、Web Application Server がにわか注目されて来たが、それを使って運用時の機能等もツールとして、ブラックボックス的に扱おうとしたのである。実際には
- プレゼンテーション
- ビジネスロジック
- データ
の３つの層を、アプリケーショフレームワークンという枠組みで囲った形でシステムを構築するのである。非機能要件はトランザクション等（これはデータ層で担う）を除き、アプリケーションフレームワークで片付けるという方針だった。その頃はパターン（設計の様式化）、フレームワーク（枠組み）、コンポーネント（部品）、この３つの活用で解決すると信じていたような気がする。そこには Aspect という概念が無かった。
最初に AspectJ を応用したツールを使ったのは Web アプリのテスト用フレームワークである。Jakarta Cactus だった。LogAspect と言う名前のアスペクトがあり、各種の Log 機能がアスペクトとしてモジュール化されていたように思う。確かにテスト用フレームワークでは、至る所でログを取りたくなる可能性があるだろう。またログの出力なども一元的に管理しただろうし、AspectJ の応用対象としては教科書的な適性を持っていると思う。元々フレームワーク・枠組みなので、汎用的な部分（cold spot）と可変部分（hot spot）の色分けは明確に出来ているし、可変部分もその境界でのインターフェイスはきちんと定義されている。汎用的に作られているからこそ、全体を見て、最適なアスペクトとは何かということをフレームワークのリファクタリングを通じて行えるような気がする。
要はアスペクト指向でシステムを組む場合は、アスペクトとして纏め上げる処理の抽出（この場合ならログ処理）よりも、アスペクトを適用する対象のクラス・属性（どのクラスのどの部分をログに取るか）を如何にきれいにして、アスペクトの相互作用部分に当たるアドバイスの特徴（シグネチャ）を決めるかが難しいと思う。その辺は全体を見て考えるよりも、ついついログ用のコードを埋め込んで、何がしか boolean debug = false のようにフラグ用変数を用意して、if(debug) {..} みたいな感じで入れ込んでしまう。またアスペクトとして分離してしまうと、局所的ではあるが可読性は下がる。この辺はデバッグをする際にはけっこう気になる部分である。ある程度まとまったら、リファクタリングを行い、アスペクトとしてまとめ行けばよいのだろうが、やはり何がしか敷居の高いものを感じてしまっていたと思う。単純なクラスパッケージではなく、ある種言語使用の拡張だからであろうか。
いずれにせよ、こうして今に至るのであるが、やはり AOP に取り組むのは、自分で何かフレームワークを作るか、既存のフレームワークを拡張するような事があればという話になりそうだ。本当はフレームワークの構築とかは好きな方なので、取り組みたいのであるが、現実はそう甘くない。困った物だ。
あと、アスペクトという概念と AOP の違いや、従来のプログラミングにおける AOP を使わないアスペクト指向の話とか、mixi のソフトウェア工学のコミュに書いた物があるが、もう少し考察を進めたいところもあるので、そのうち暇があれば BLOG にあげようと思う。*4
