ポイントカット、アドバイスの詳細。パタンマッチでコード挿入できるのはデバッグに便利かも。って思いつく用途がやっぱりデバッグってのはなんだかなあ。だんだん分かってきたけど、複雑怪奇すぎて使う気が...。ちょいとしたパズルだねこりゃ。
ところで私は例外処理のtry-catch構文がコードの可読性を低下させるので大嫌いなのだが、これこそアスペクトにできないもんでしょうかねえ。あまり横断的じゃないからアスペクトっぽくないかもしれないけど。
こんなんありましたぜ。用途の例も載っていますが…<br>http://www.oucc.org/~tail/aspectj/index.php?%A5%A2%A5%B9%A5%DA%A5%AF%A5%C8%A4%CE%CD%F8%CD%D1%CA%FD%CB%A1
なるほどー。やはり使い方の一つとしてあるんですね。
私が知りたいのはアスペクト指向を使う場合に得られるものと支払う代償の釣り合いですよね。これをはっきりさせないとどんな場合にアスペクト指向を使うべきか分からないわけです。<br><br>これとはちょっと違う話ですが、「表明」に関するところで<br><br>> クラス本体の記述には影響を与えないため，クラスの再利用が，制約に左右されないという利点があります．汎用的なクラスに対して，厳しい制約を外部から付加することで安全に使う，といった用途が考えられます．<br><br>大抵の場合、表明が必要となるのは有る程度以上の規模のソフトウェアで、表明が必要になるクラスは多分あまり汎用的でない、つまりソフトウェアの問題領域に特化したようなクラスではないかと思われます。（こうなる理由は直感的には説明できるけど、論文にまとめるのは多分凄く大変だと思います）<br><br>で、こういう「真に表明が必要とされる」クラスの場合、表明とクラスは別々にしてはいけないのです。分けて書きたいプログラマーはいるかもしれませんが、テストをする人の多くは反対すると思います。<br><br>まあそういう訳で、言語の機能の話をする場合は有効なプログラム例が必要で、そのプログラム例が有効かどうかはそれが登場する状況とかそれによって得られる（或いは失われる）ソフトウェア工学上の利益によって担保されると思う次第です。
それからアスペクト指向と同じような動機だけど、プログラミング言語の機能じゃなくてソフトウェア開発の「手法」でなんとかしちゃおう、という話もあると思います。ユースケースの利用やひょっとしたらこれから流行るかもしれないSoftware Factoryなんていうのがこれに相当するんじゃないかと思います。手法になると現場の方が強いですよね。で、結局「アスペクト指向は手法に比べてずっと良いです」という事を主張しないと研究者の世界での流行に終わってしまうのではないのか、というのが私の考えです。長文スマソ。
「得られるものと代償」なのですが、最近のソフトウェア工学では仕様変更にかかるコストなどを測るメトリックスはなにかあるんでしょうか。
> 手法になると現場の方が強いですよね。<br>> 研究者の世界での流行<br><br>研究者の世界というのがどこまでなのかはよくわかりませんが、AspectJなどは開発者向け Java雑誌などでもよく取り上げられており、ログ／トレース等の最終製品に害を与えないような使い方なら、「手法」よりもずっと受け入れられる余地は大きいように思います。関係ないですが、最近のJava雑誌はCafeOBJとかをなにげに紹介したりするので、油断できません。どうでもいいけどカーソルが見えない（黒いから？）です、このスタイルは。確かに目には優しそうですが。
個人的にはUI系ソフトのデバッグに重宝しそうな気がしてきています。ただあの文法では書く気がしませんので、エディタでログ出力コードを埋め込んでいくとアスペクトをPBE的に自動生成してくれるようなツールが欲しいです。しかしCafeOBJを一般向け雑誌でやるとはなかなかですね。カーソルはFirefox 1.5 on WinXPでは白くくっきり見えてるんですが...。
とよだ氏：<br> > 「得られるものと代償」なのですが、最近のソフトウェア工学では仕様変更にかかるコストなどを測るメトリックスはなにかあるんでしょうか。<br><br>メトリクスは全然分からないので、そっち方面のプロジェクトをやっている人に今度会ったら聞いてみます。<br><br>それからおいらのネスケ7.1ではカーソルは白くくっきり見えます。<br>なぜか知らないけどこの配色だと一瞬Xかと思ってしまった。<br><br>とさん：<br>> 研究者の世界というのがどこまでなのかはよくわかりませんが、AspectJなどは開発者向け Java雑誌などでもよく取り上げられており、ログ／トレース等の最終製品に害を与えないような使い方なら、「手法」よりもずっと受け入れられる余地は大きいように思います。<br><br>まあ、OO手法の偉い人達は大学人だったりコンサルタントしたりしているようなので「研究者の世界」の境界は曖昧かもしれませんね。自分の日記でも何度か書いていますが手法は宗教臭がする分受け入れられ難いところもあるかもしれません。<br><br>そういえば最近頭がすっかり古典的になっていてJava雑誌とか全然読んでいないような気がします。
はじめまして。<br><br>> 個人的にはUI系ソフトのデバッグに重宝しそうな気がしてきています。ただあの文法では書く気がしませんので、エディタでログ出力コードを埋め込んでいくとアスペクトをPBE的に自動生成してくれるようなツールが欲しいです。<br><br>そういう目的だと、Bugdel<br>http://www.csg.is.titech.ac.jp/~usui/bugdel/<br>はどうでしょう？既に知っておられるかもしれませんが。
みずしまさんありがとうございます。やっぱりあるんですねこういうの。面白そうですが、まずEclipseを使えるようにならないと...。<br>これ、千葉先生の学生さんが作っておられるんですね。デモムービーが作ってあったり気合が入っていていいですね。
こんなんありましたぜ。用途の例も載っていますが…<br>http://www.oucc.org/~tail/aspectj/index.php?%A5%A2%A5%B9%A5%DA%A5%AF%A5%C8%A4%CE%CD%F8%CD%D1%CA%FD%CB%A1
なるほどー。やはり使い方の一つとしてあるんですね。
私が知りたいのはアスペクト指向を使う場合に得られるものと支払う代償の釣り合いですよね。これをはっきりさせないとどんな場合にアスペクト指向を使うべきか分からないわけです。<br><br>これとはちょっと違う話ですが、「表明」に関するところで<br><br>> クラス本体の記述には影響を与えないため，クラスの再利用が，制約に左右されないという利点があります．汎用的なクラスに対して，厳しい制約を外部から付加することで安全に使う，といった用途が考えられます．<br><br>大抵の場合、表明が必要となるのは有る程度以上の規模のソフトウェアで、表明が必要になるクラスは多分あまり汎用的でない、つまりソフトウェアの問題領域に特化したようなクラスではないかと思われます。（こうなる理由は直感的には説明できるけど、論文にまとめるのは多分凄く大変だと思います）<br><br>で、こういう「真に表明が必要とされる」クラスの場合、表明とクラスは別々にしてはいけないのです。分けて書きたいプログラマーはいるかもしれませんが、テストをする人の多くは反対すると思います。<br><br>まあそういう訳で、言語の機能の話をする場合は有効なプログラム例が必要で、そのプログラム例が有効かどうかはそれが登場する状況とかそれによって得られる（或いは失われる）ソフトウェア工学上の利益によって担保されると思う次第です。
それからアスペクト指向と同じような動機だけど、プログラミング言語の機能じゃなくてソフトウェア開発の「手法」でなんとかしちゃおう、という話もあると思います。ユースケースの利用やひょっとしたらこれから流行るかもしれないSoftware Factoryなんていうのがこれに相当するんじゃないかと思います。手法になると現場の方が強いですよね。で、結局「アスペクト指向は手法に比べてずっと良いです」という事を主張しないと研究者の世界での流行に終わってしまうのではないのか、というのが私の考えです。長文スマソ。
「得られるものと代償」なのですが、最近のソフトウェア工学では仕様変更にかかるコストなどを測るメトリックスはなにかあるんでしょうか。
> 手法になると現場の方が強いですよね。<br>> 研究者の世界での流行<br><br>研究者の世界というのがどこまでなのかはよくわかりませんが、AspectJなどは開発者向け Java雑誌などでもよく取り上げられており、ログ／トレース等の最終製品に害を与えないような使い方なら、「手法」よりもずっと受け入れられる余地は大きいように思います。関係ないですが、最近のJava雑誌はCafeOBJとかをなにげに紹介したりするので、油断できません。どうでもいいけどカーソルが見えない（黒いから？）です、このスタイルは。確かに目には優しそうですが。
個人的にはUI系ソフトのデバッグに重宝しそうな気がしてきています。ただあの文法では書く気がしませんので、エディタでログ出力コードを埋め込んでいくとアスペクトをPBE的に自動生成してくれるようなツールが欲しいです。しかしCafeOBJを一般向け雑誌でやるとはなかなかですね。カーソルはFirefox 1.5 on WinXPでは白くくっきり見えてるんですが...。
とよだ氏：<br> > 「得られるものと代償」なのですが、最近のソフトウェア工学では仕様変更にかかるコストなどを測るメトリックスはなにかあるんでしょうか。<br><br>メトリクスは全然分からないので、そっち方面のプロジェクトをやっている人に今度会ったら聞いてみます。<br><br>それからおいらのネスケ7.1ではカーソルは白くくっきり見えます。<br>なぜか知らないけどこの配色だと一瞬Xかと思ってしまった。<br><br>とさん：<br>> 研究者の世界というのがどこまでなのかはよくわかりませんが、AspectJなどは開発者向け Java雑誌などでもよく取り上げられており、ログ／トレース等の最終製品に害を与えないような使い方なら、「手法」よりもずっと受け入れられる余地は大きいように思います。<br><br>まあ、OO手法の偉い人達は大学人だったりコンサルタントしたりしているようなので「研究者の世界」の境界は曖昧かもしれませんね。自分の日記でも何度か書いていますが手法は宗教臭がする分受け入れられ難いところもあるかもしれません。<br><br>そういえば最近頭がすっかり古典的になっていてJava雑誌とか全然読んでいないような気がします。
はじめまして。<br><br>> 個人的にはUI系ソフトのデバッグに重宝しそうな気がしてきています。ただあの文法では書く気がしませんので、エディタでログ出力コードを埋め込んでいくとアスペクトをPBE的に自動生成してくれるようなツールが欲しいです。<br><br>そういう目的だと、Bugdel<br>http://www.csg.is.titech.ac.jp/~usui/bugdel/<br>はどうでしょう？既に知っておられるかもしれませんが。
みずしまさんありがとうございます。やっぱりあるんですねこういうの。面白そうですが、まずEclipseを使えるようにならないと...。<br>これ、千葉先生の学生さんが作っておられるんですね。デモムービーが作ってあったり気合が入っていていいですね。