BLOGTIMES
2004/07/03

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

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

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

品質を作りこむとすれば

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

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

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

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

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

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

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

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

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

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

トラックバックについて
Trackback URL:
お気軽にどうぞ。トラックバック前にポリシーをお読みください。[policy]
このエントリへのTrackbackにはこのURLが必要です→https://blog.cles.jp/item/251
Trackbacks
このエントリにトラックバックはありません
Comments
愛のあるツッコミをお気軽にどうぞ。[policy]
古いエントリについてはコメント制御しているため、即時に反映されないことがあります。
はま (2004/07/08 13:45) <%HatenaAuth()%>

 はじめまして。
 僕も、ツールによるデバッグにいちゃもんつけるよりは、デバッグの必要ないコードを書けばいいじゃんと思ってる人です。
 ほんとにわかりやすく、バグが無いと判断できるコーディングができるようにならなければ、口先だけになってしまいますよね。
 コードを書く人の心次第。アスペクトの方法論、興味がありますね。

hsur (2004/07/09 00:30) <%HatenaAuth()%>

こちらこそ、はじめまして。

バグのないプログラムを作り出すプロセスは、確かにコードを書く人の心次第ですよね。その心をサポートできるのは、デバッグツールでなくて、方法論だと思っています。できたら自分もそういうところに貢献したいと思っていて、一応ネタとしてはいくつか考えてあるのですが・・・・・別件の忙しさもあって、半年くらい手付かずになっています。

Comments Form

コメントは承認後の表示となります。
OpenIDでログインすると、即時に公開されます。

OpenID を使ってログインすることができます。

Identity URL: Yahoo! JAPAN IDでログイン