PR
図9●DIやアスペクト指向の課題</b><BR>依存性をオブジェクトの外に切り出したことによる保守性や理解容易性への影響は,両者に共通する課題だ。さらにアスペクト指向には,適切なアスペクトの抽出や,複数のアスペクト同士の矛盾性の検証が困難といった課題がある。
図9●DIやアスペクト指向の課題</b><BR>依存性をオブジェクトの外に切り出したことによる保守性や理解容易性への影響は,両者に共通する課題だ。さらにアスペクト指向には,適切なアスペクトの抽出や,複数のアスペクト同士の矛盾性の検証が困難といった課題がある。
[画像のクリックで拡大表示]

課題
依存性の管理

 以上見てきたように,クラス間の依存性を低減するためのものとして,DIとアスペクト指向は有望な技術である。しかし現時点では,いずれにも課題が存在する(図9[拡大表示])。どちらにも共通するのは,クラスから切り離した依存性をいかに管理し,把握するかである。

 クラスから依存性を切り離したとしても,複数のクラスのオブジェクトが協調動作する以上,どこかで依存性は生じる。DIはこれをXMLファイルやコンテナの自動的な結びつけ機能によって解決する。アスペクト指向では,アスペクトを記述するソースコードか,XMLファイルでこの情報を記述している。

 つまりどちらも,依存性の情報は本来のソースコードからは切り離されたところに存在する。アプリケーションに何か不具合が発生し,動作を確認したい場合,どこに問題があるかを判断しにくい。ソースコードやXMLファイルなど,アプリケーションの動作にかかわる情報が分散して存在しているからだ。またコンテナの自動的な結びつけのように,開発者自身が記述していない処理が見えないところで実行されると,ますます原因を究明しにくくなる。

 「オブジェクトをシンプルにすることで得られるメリットもあるが,同時に失うものもある。今までハード・コーディングしていた部分を外に切り出すことで,アプリケーションとしての保守性は下がる面もある。EJBは複雑すぎたので次版ではシンプルになるようだが,そのうち複雑化する揺り戻しがあるのではないか」(浅海智晴事務所の浅海智晴代表)。

 また,部品の量が増えたときに,依存性の定義ファイルの管理が難しくなる。例えばDIコンテナで依存性の記述が大量になった場合,それを間違いなく記述し,正しく管理するのは大変な作業だ。

アスペクトの矛盾が起こる

 さらにアスペクト指向には,別の問題も存在する。アスペクトの定義が複数になったとき,それらの整合性をとるのが難しい。例えば「注文に関するアスペクトと,配送に関するアスペクトがあったとする。どちらも,商品というオブジェクトを貫通する。このように複数のアスペクトが適用され得るオブジェクトがあった場合,どのように両者を制御するのか」(豆蔵の羽生田栄一取締役会長)。

 また,アスペクトそのものの抽出が難しいという課題もある。複数のオブジェクトから,それらに共通する機能をきれいに分割するのは容易ではない。そもそも何をアスペクトにするべきかという,根本的な問題も存在する。「アスペクトは,オブジェクトのようにきっちりと区分けができるものなのかどうかが疑問。結局汎用の技術でなく,ログ出力のように明らかに切り分けられるものに限定されるのではないか」(早稲田大学理工学部情報学科の深澤良彰教授)。

 もちろん,以上のような課題に対応する取り組みも少しずつ出てきた。例えばDIコンテナは,依存性の管理を容易にするために,XMLファイルの管理ツールを整備し始めた。またアスペクトの抽出についても「プログラムの構造に注目して,複数のクラスに共通する部分を抽出する研究が始まっている」(国立情報学研究所実証研究センターの鷲L弘宜助手)。

 ただプログラムの構造だけでは,その機能がオブジェクトに対してどのような意味を持つ機能なのかは分析できない。クラスの本質として残しておくべきものなのか,外に切り出すべきものなのかは人が判断するしかない。つまり「現在アスペクト指向はプログラミングのレベルでもてはやされているが,本来は設計技術。分析や設計の段階からアスペクトの考え方を導入することが,これから重要になっていく」(南山大学数理情報学部情報通信学科の青山幹雄教授)。