変なAspectを書かなければいいんじゃないの

今日は大学で先週の続きをディスカッション。
結構、盛り上がりました。

† 品質を作りこむとすれば

そもそも、デバッグしにくいAspectができてしまう原因はweavingすると他のオブジェクトの挙動をかえてしまうことが原因だと思っています。議論の中で単純に思ったことは、そうなってしまったプログラムをデバッグツールでデバッグをするというのは本質的ではないんじゃないかということです。

この状況をトヨタ生産方式のライクに考えるれば話は早いと思います。つまり、ツールによって不良を検査するのではなく、品質を作りこむプロセスによって問題を解決すべきということです。具体的には設計とかプログラミングの段階で、単純に「そういうAspectを書いたらいけない」ということにすればいいのではないでしょうか。

† 「できるのにやらせないという発想」 ＝　「開発方法論？」

構造化プログラミングにしてもオブジェクト指向プログラミングにしてもそうですが、どんなプログラミングパラダイムにも「これはやってはいけない」という制約とか「アンチパターン」のようなものが必ず存在しています。AOPをやっていて気になるのは、そういうものがないのでいつの間にかとんでもないプログラムになってしまうということです^*1。

別にこれは悪いことではなくて、見方を変えればAspectは強力なプログラミングパラダイムということを示している例であると考えることができます。問題はこれをいかに上手に使いこなして、いかにAOPに強力な味方になってもらうかということでしょう。

少なくとも、今の僕にとってAOPは使いこなせない代物なので、諸刃の剣以外の何者でもありません。

Aspectはパラダイムとしてまだまだ若いので、使い方の可能性を模索している段階にあります。全体がそういう論調なので、使い方の秩序を模索しようという動きはあまり見られません。しかしながら、過去のプログラミングパラダイムの歴史を考えてみれば、最終的にはそういうノウハウの蓄積が重要になってくる時がきっと来るはずです。

一般的にそれらの知識はソフトウェア開発方法論という形でまとめられます。ソフトウェア開発方法論(Software Design Methodlogy)とは「作業手順（Process）」、「対象の捉え方(View)」、「作業の判断基準(Criteria)」、「成果物(Output)」が規定されているものです。

AOPはOOPを補完するパラダイムなので、OOPの方法論とかぶるところも多いと思いますから、ポイントはCriteriaになるでしょう。それが明らかになったとき、アスペクト指向開発方法論というものがきっと登場するのでしょうね。

• ^*1: 単純に僕の腕の問題ですけど。