Aspect-Oriented Design Patterns
AspectJ を使ってデザインパターンを再実装しようという試み*1を続けて、もうすぐ2年が経つ。しかし、まだ、完成しそうにない。ので、少し、現状を書きとめておきたいと思う。
そう、この試みから、僕は何を学んだのか？ なぜいまだに完成しないのか？ そして、今後の展開は？
何を学んだのか？
一つの学んだことは、デザインパターンに関する理解が深まったこと。少なくとも Java の言語能力範囲 だけで デザインパターンを理解しようとするよりは、デザインパターンとは何か、という本質への理解を深められたと思う。
単に 使うだけ の範囲でデザインパターンを考えるよりも、明らかにデザインパターンへの見方が深くなった。たとえば、Java の範囲で考えるならば、各デザインパターンの実装（あるいは、効果）に関する疑問点は、AspectJ でのときよりも、少ない。なぜなら、Javaの場合は、他に手段がないため、最適な（あるいは最適に近い）実装上の選択が、デザインパターンの形で終わることが多いため。あるいは、だからこそ、デザインパターン、とも言える。
しかし、一方、AspectJ では、選択肢の幅が広がる。したがって、根本的なところから各デザインパターンを見直す必要性を感じる。つまり「なぜこのデザインパターンは、このデザインパターンとして、存在するのか？」といった、単にパターンを使うだけの時には疑問をもっても仕方ないような、疑問に回答する必要を感じる。
なぜ、Observer パターンは、パターンなのか？ なぜ、FactoryMethod がパターンとして存在しているのか？ どんな 言語的機能が提供されて いなかった ので、パターンとして存在しているのか？ どんな 言語的機能が提供されて いたとしたら 、パターンでは なくなる のか？
もう一つ学んだことは、自分で実際に考えてみることによる効果を認識できたこと。すでに、AspectJ を使ってデザインパターンを再実装しようとする試みは存在する*2。それなのに、どうして僕は 再 研究となるようなことを行っているのか？
もともとは、すでにそのような試みがあることを知らなかったというのが挙げられる。しかし、その試みを調べてみて（ソースを読んだり論文を読んだり）分かったことは、僕とは違う結果が出ている、ということだった。
ソースを読んだり、論文を読むだけでどれだけの経験を得られるのか？ 実際に自分で考えてみるだけでどれだけ論文から得られる知見との差が生まれるのか？ この差は、大きい。
なぜ完成しないのか？
なぜ、いまだにこの試みが完成していないのかについては、いくつかの理由がある。一つは、まず、常にこれに関わっているわけじゃないので、進行具合が遅いということ。
もう一つは、AspectJ がもたらす、デザインパターンの実装上のバリエーションの多さにあると思う。いまだに、こういう視点から AspectJ で特定のパターンを実装するようなこともできるんじゃないか、という発見がある。もちろん、すべてのバリエーションが実践的に重要な考慮の必要な設計上の選択肢となるとは思わないけど、いくつかはなると思う。
あとは、実際的な例の少なさ。もっと、現実的にありえるような例（Component とか、Context とか Product とかじゃなく）で実装例を挙げたほうがいいと思う。
もう一つは、カタログとしての使い勝手の悪さ。昔日記に書いたと思うけど、カタログとしては、今の段階ではかなり使いにくい。ソースコードだけを載せるのは、やはり、僕（著者）から見たときでさえ、不十分に思える。
今後の展望:
そう、関連することとして、今後どのような試みがあるのか？
その他のアスペクト指向言語によるデザインパターンの実装: もちろん、AspectJ だけがアスペクト指向言語ではない。したがって、その他の言語で実装すれば、どのような結果となるのかは興味深い。これは、また、デザインパターンを実装する、という観点からの、既存のアスペクト指向言語の特徴の違いを評価するのにも使えると思う。
リファクタリングからアスペクト指向デザインパターンへ: 通常のデザインパターンと同じように、はじめからデザインパターンを適用できると感じていても、そうすることが正しいとは限らない。
リファクタリングとパターンとの関係は、もうすぐ発売予定の「Refactoring to Patterns」という本でも触れられていると思う。
http://www.industriallogic.com/xp/refactoring/
ただし、ここでいうパターンは、恐らくオブジェクト指向デザインパターンなのであって、アスペクト指向デザインパターンなのではないと思う。したがって、アスペクト指向デザインパターンの視点から、リファクタリングとの関係を考えてみるとは、価値があると思う。
Aspect-Oriented Patterns as Signs: Patterns as Signs という研究に対しての、アスペクト指向デザインパターンからみた取り組み。
DL: http://www.mcs.vuw.ac.nz/~kjx/papers/e03.pdf
まとめ
AspectJ を使ってデザインパターンの実装という試みに関わってもうすぐ2年。基本的な方針は、各デザインパターンを AspectJ を使って実装するという視点から考えたときに、どのような設計上のバリエーションがあるのかをできるだけ多く考えてみようとすることであった。
実装しようとするときに、最も考慮が必要な点は、各デザインパターンの本質は何か、という点であった。実装方法、あるいは、どのように実装するのか、は本質ではないと思う。各パターンが、パターンとして認知されるに至った意図と、過程が重要に思える。
どのような過程（発展、進化）を通して、各パターンは、パターンとして残ったのだろう。いくつかは、リファクタリングの結果としてである、と考えられる。
「AspectJ を使ったデザインパターンの改善と支援」が、タイトルである。なぜ、「AspectJ を使ったデザインパターンの実装」ではないのだろうか。改善とつけたのは、デザインパターンの欠点が解決できる、という実装が存在したためである。支援というのは、AspectJ を使えば、各パターンの適用範囲を広げられる、といニュアンスを感じたためである。
いくつかの実装上のバリエーションは、本来のデザインパターンの実装とは、大きく異なるかもしれない。しかし、各パターンの意図は、残っているはずである。
一つの本質的な疑問は、AspectJ を使ってオブジェクト指向デザインパターンを実装しようとした場合に、その実装結果は、パターンなのか、という点である。どこまで がパターンなのであろうか。
そう、
デザインパターンとは何か？
まだ答えは出ていないと思う。
