↑↑↑アスペクト指向とは何か↓↓↓

1 ：→：02/09/03 21:42

アスペクト指向とは何か？

2 ：デフォルトの名無しさん：02/09/03 21:42

何か？

3 ：デフォルトの名無しさん：02/09/03 21:44

何すか

4 ：デフォルトの名無しさん：02/09/03 21:44

デジャブかな・・

5 ：デフォルトの名無しさん：02/09/03 21:45

>>1
も～発てるまえに検索しろよ

6 ：デフォルトの名無しさん：02/09/03 21:48

>>5
返信のテスト

7 ：デフォルトの名無しさん：02/09/03 21:51

>>5
同意。だがageることもなかろうて。

8 ：デフォルトの名無しさん：02/09/03 21:54

>>7
どちらにしろ、立てて数分じゃ、上のほうにあるだろうけどな。

9 ：→：02/09/03 21:58

AOPスレは、
深海の奥底でこっそりやるのがお好きなようなので、
別スレ立ててみました。

アスペクト＝非機能的特性、とすると、
機能実現＝実装と直結した「オブジェクト」よりも、
分析設計上の概念と結びついた「インターフェース」と
共通点や関連を見出せるのではないか？とか、
実装の再モジュール化に使う手法と考えると、新種のリファクタリング手法ではないか？とか、
考えてしまいます。

また、実装言語とは別のレイヤーで、コードの再構成を行う、という目的は、
マクロやpatchとの共通性も浮かんで来ます。

どないな感じでしょうねぇ

10 ：デフォルトの名無しさん：02/09/03 22:00

>1
とりあえず、ゲーム帝国などを読んで自習してくれ。

11 ：デフォルトの名無しさん：02/09/03 22:00

DelphiはAOP

12 ：→：02/09/03 22:00

gomiか

13 ：デフォルトの名無しさん：02/09/03 22:05

お前もこっそり参加してりゃ良かったのに。

14 ：デフォルトの名無しさん：02/09/03 22:07

OOPの次はAOPだそうですね？
http://pc3.2ch.net/test/read.cgi/tech/1004962559/

15 ：→：02/09/03 22:08

AOPスレ、伸びるの遅いから、興味の速度についてかないんだ‐

16 ：デフォルトの名無しさん：02/09/03 22:14

新手の荒らしですか？

17 ：→：02/09/03 22:15

またgomiですか？

18 ：デフォルトの名無しさん：02/09/03 22:19

ﾃﾞﾑﾊﾟですか？

19 ：→：02/09/03 22:21

ｶﾜｲｿｳな煽り屋さん？

20 ：デフォルトの名無しさん：02/09/03 22:50

例えば、メソッド呼び出し全てに一発でロギング処理文を放り
込むようなことができたら便利でしょ？それをやるのがAspectJ。

JavaServlet2.3のFilterなんてのも、それを別の形で実現する
方法だな。

21 ：デフォルトの名無しさん：02/09/03 22:53

頼むからクソスレ立てまくらないでくれ>>1
http://pc.2ch.net/test/read.cgi/prog/1031059323/

22 ：デフォルトの名無しさん：02/09/03 22:53

ロギングは良いから、もっと面白い話をしてくれ。

23 ：デフォルトの名無しさん：02/09/03 22:56

剥板もレベル下がったなー。
しつこい煽り厨房(>>21)みたいな奴がのさばってる様じゃ、
この板に訳ﾜｶﾗﾝｸｿｽﾚ立ちまくっても自業自得だね

24 ：デフォルトの名無しさん：02/09/03 22:58

>この板に訳ﾜｶﾗﾝｸｿｽﾚ立ちまくっても自業自得だね
自作自演です(藁

25 ：デフォルトの名無しさん：02/09/03 22:59

なるほど、>>21は>>24の自作自演ですか。
消えて下さい>>21＆>>24

26 ：デフォルトの名無しさん：02/09/03 23:10

別スレでは、Aspectが干渉しあう場合について問題だとおっしゃる方もいるようだが、
AspectJの親方のセールストークによれば「そのような問題に遭遇する人は少ない」そーだ(母数が少ないんじゃないかと(略))

じゃぁもう一歩踏み込んで、AspectJで切り出したAspectから、更にAspectを切り出したい場合(高次のAspect?)に、アスペクト指向は有効なんだろうかねぇ？

27 ：デフォルトの名無しさん：02/09/03 23:17

>>26
既存のライブラリに広く薄く機能追加するのに便利であって、
こればっかりでなんかしようとするのは本末転倒だと思われ。

28 ：デフォルトの名無しさん：02/09/03 23:19

AspectのAspectって、上位抽象クラスの導出と似てるかもね

29 ：デフォルトの名無しさん：02/09/03 23:22

>>27
それは、「君が納得できた範囲ではそうだ」って話でしょ。
このスレは、耳知識や過去の経験だけに頼らず、
その場で自分で考えてレスしてね。

30 ：デフォルトの名無しさん：02/09/03 23:23

知ってる用語を並べてみるスレはここですか？

31 ：デフォルトの名無しさん：02/09/03 23:25

厨房はおねむの時間ですよ。おやすみ

32 ：デフォルトの名無しさん：02/09/03 23:26

なんかLISPで全部できそうだな

33 ：デフォルトの名無しさん：02/09/03 23:29

>>26
どーだろね？

34 ：デフォルトの名無しさん：02/09/03 23:30

>>32
たとえば？

35 ：デフォルトの名無しさん：02/09/03 23:32

>>26

diffファイルのdiffってのが、実行可能だけど役に立ちそうもないのと同様に、
aspectのaspectってのが有効に役立つようにするのは、まだ難しいんじゃないのかな？

36 ：デフォルトの名無しさん：02/09/04 00:14

>>31
は、OLAPのスレで、技術的内容と経営コンサルの区別が付かなかったﾔｼだね

37 ：デフォルトの名無しさん：02/10/22 23:52

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

38 ：デフォルトの名無しさん：02/10/23 00:00

ﾏﾀｰﾘ
http://ime.nu/homepage2.nifty.com/rohizuka/ka/pa_003_a.htm

39 ：デフォルトの名無しさん：02/10/23 00:00

OOPの次はAOPだそうですね？
http://pc3.2ch.net/test/read.cgi/tech/1004962559/l50

40 ：デフォルトの名無しさん：02/10/23 00:06

↓←　↓←　
→↑　→↑　

41 ：デフォルトの名無しさん：02/10/23 00:07

で、ログ以外にどんなまともな使い道があんのよ？
重複スレ立てるくらいなんだから答があんだろうな？

42 ：デフォルトの名無しさん：02/10/23 00:07

ｺﾞﾒｿ
http://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm

43 ：デフォルトの名無しさん：02/10/23 00:13

一つ思い付いたのは、DBアクセス系のメソッド実行前に
システム利用者の認証が切れてないかを確認するって
いうアスペクトはどうだろう？

システム利用時に入力したIDとパスワードでログイン後、
データアクセス系のサービスを利用するたびに認証情報
が時間切れ等で失効してないか毎回確認後サービス実行。

厳密にユーザ権限の執行をしたいような業務があるか
どうか分からないけど、とりあえず妄想を吐き出しておく。

44 ：デフォルトの名無しさん：02/10/23 00:19

つーか変な名前つけて意味ぼかしただけで、中身hook-functionだろ。
新しい事なんて何も無い。

45 ：デフォルトの名無しさん：02/10/23 00:25

また知ったかぶりの馬鹿がひとり・・・＞44

46 ：デフォルトの名無しさん：02/10/23 00:25

>>44 ぷっ。これだから新しい概念についていけないヤシは。
…と突っ込むヤシ、その新しい概念をキチンと説明してください。

47 ：デフォルトの名無しさん：02/10/23 00:40

>>43
AspectJの親玉も、aspectの例としてアクセス・コントロールを上げてたよん

48 ：デフォルトの名無しさん：02/10/23 00:45

普通にクラス作ってその観点でメソッド作った後に、
そう都合良く、メソッドフックだけで何かの
別観点の一貫した付加機能が作れるものか？
ただのメソッドフックじゃないと言うヤシは、
ここんとこどうなのよ？

49 ：デフォルトの名無しさん：02/10/23 00:45

>>47　サンクス！
既出だったのね・・・・スマソ
勉強が足りなかった。

50 ：　：02/10/23 00:54

>>48
属性とかも追加できるでしょ。

51 ：デフォルトの名無しさん：02/10/24 15:51

インターフェースの実装や親クラスの変更もできるぞ！

52 ：デフォルトの名無しさん：02/11/12 17:00

芹何濶ョさん?

53 ：デフォルトの名無しさん：02/11/24 15:27

MixJuice http://staff.aist.go.jp/y-ichisugi/ja/mj/
もアスペクト指向の一種でしょうか?

クラスの外側を覆っているモジュールを継承できることで
オブジェクト指向的でないとされる
if-else-if文の追加の問題を解消できるらしい。

この言語に対応したデザインパターンについても説明されている。

オブジェクト指向の次に来るのはエージェント指向と言う人も居たけれど
また別物ですね?

54 ：デフォルトの名無しさん：02/11/24 15:34

グダグダ言う前にコードを書いてみろと、設計してみろと。

55 ：デフォルトの名無しさん：02/12/07 19:56

http://www.google.co.jp/search?q=cache:LNvilRoec4QC:iip-lab.ics.es.osaka-u.ac.jp/research/aspect/+%E3%82%A2%E3%82%B9%E3%83%9A%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91&hl=ja&ie=UTF-8
ここ分かりやすかったけど、説明あってます？

56 ：デフォルトの名無しさん：02/12/07 20:21

所詮プリプロセッサだから、既存のライブラリとかには適用できない
わけだね。トレース以外に使い道あるんかな。

57 ：デフォルトの名無しさん：02/12/10 02:52

AspectJ は最新版から class や jar に対しても使える。

58 ：デフォルトの名無しさん：02/12/19 03:59

おれは基本的に>>44に同意なんだが、OOのターム(とくに設計段階のそれ)
でいうとどういう解釈になるの？
http://dolphin.c.u-tokyo.ac.jp/~kazu0/aspectj-primer/primer-fornewcomers/node7.html
なども読んだけど、どうもいまいち。

59 ：デフォルトの名無しさん：02/12/28 02:44

>>58
フックは実現の手段であって、アスペクト指向の全てではない。
OOP がただの構造体と関数ポインタに見えたのと同じ。
新しさは実装方法ではなく、コードのとらえ方にある。

class Hoge{
public:
　void func1();
　void func2();
private:
　int a, b;
}

func1 からは a しか見なくて、 func2 からは b しか見ない。
この場合、a, func1 と b, func2 は、異なるアスペクトに分類できる
可能性が高い。

60 ：デフォルトの名無しさん：03/01/09 02:58

　　　　　　　　　 l≡l 　.　l≡l
　　　　　　　　　 |:::└┬┘:::|
　　　　　　　　　 |:::┌┴┐:::|
／￣￣＼　　　ﾉ::::::丶 /:::::::＼.　　／￣￣＼
|　記念　.＞　（::(,,ﾟДﾟ)(ﾟーﾟ*)::)　＜　ﾊﾟﾋﾟｺ　.|
＼＿＿／　　　|:∪::::| |::::∪::|.　　　＼＿＿／
　　　　　　　～（(((:::::))(((:::::))）～
　　　　　　　　　∪￣U U￣∪

61 ：デフォルトの名無しさん：03/01/09 04:23

IPは取ればいいと思うけど、だれでも見れるようにはしてほしくないなあ。
串つかうやつもいて、そいつだけ無傷でやりたいほうだいとかでてくるからな。

62 ：デフォルトの名無しさん：03/01/09 13:59

これも宮崎の圧力な訳だが

63 ：デフォルトの名無しさん：03/01/09 14:39

>>240の後半
それはそうだとは思う。けど告発して話題にされるのが目的なら、結局危険だな。
小さな掲示板に書き込んで、他人に広めてもらえばいいのか。

64 ：あぼーん：あぼーん

あぼーん

65 ：デフォルトの名無しさん：03/01/09 23:35

1chみたいにログ流出だけは避けてくれればとりあえずはいいかなと。
しょうがないでしょう、このご時世。

66 ：デフォルトの名無しさん：03/01/10 08:34

なんか賛成票の妙な伸び方が組織票っぽいんだよな・・・
もしかして企業とかが・・・なんてね（＾＾）

みんなアクセスログなんて言葉聞いたこともないよな？

67 ：デフォルトの名無しさん：03/01/10 09:54

スレに即した質問したのに返ってこない

68 ：デフォルトの名無しさん：03/01/10 10:35

>>216
途中までは真面目な話だったはずなんだけどな、、

69 ：デフォルトの名無しさん：03/01/10 11:06

>>566
書き込みのログだけでも(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙなんですが

70 ：デフォルトの名無しさん：03/01/10 11:50

>>237
匿名で書き込み、何処の誰ともしない奴に煽られ、
それでいて、いわゆる荒らし行為に臨む者が存在する現状で誰も文句を言わないと言うのはおかしくないか。

住所などを表示した場合のセキュリティはどうする？
仮に本名で語り合ったとしてもその「本人であるという認証」はどうする？
ＩＰアドレスやリモートホスト、メールアドレスの表示があったとしても偽名で書き込むのはなんなくできてしまう。
「身元」と言う表現を使うなら、それはハンドルネームを用いるネット上の全てのコミュニティ、
サイトに対する挑戦となってしまうな。

71 ：デフォルトの名無しさん：03/01/10 12:21

qb : 2ch批判要望削除議論削除要請削除整理
live2 : ニュース速報
tmp : ニュース極東ちくり裏事情政治思想 Download
　　　　厨房！人権問題バカニュース薬・違法
　　　　ゴーマニズムロビー最悪少年犯罪
　　　　違反の潰し方ペット苦手なんでもあり学歴

72 ：あぼーん：あぼーん

あぼーん

73 ：デフォルトの名無しさん：03/01/10 15:33

いい所突いているように思えますが。

74 ：デフォルトの名無しさん：03/01/10 17:01

も
こ
そ
も
お
人
世
ど
こ
お
断

75 ：デフォルトの名無しさん：03/01/10 23:22

>>312
この野郎！

と言おうと思ったけどIP晒されるのでやめた

76 ：デフォルトの名無しさん：03/01/10 23:29

　　　　　言　い　た　い　こ　と　も　言　え　な　い
　　　　　　　　　　　こ　ん　な　イ　ン　タ　ー　ネ　ッ　ト　じ　ゃ

　

77 ：デフォルトの名無しさん：03/01/11 00:47

次スレ立てるときは
のソース貼り付けおながい。

78 ：デフォルトの名無しさん：03/01/11 00:52

あ、そうだIP記録してんなら削除三板のリモホ表示やめれ

79 ：デフォルトの名無しさん：03/01/11 10:15

ぬんちゃく、か、、、

80 ：あぼーん：あぼーん

あぼーん

81 ：デフォルトの名無しさん：03/01/11 11:40

水疱瘡のあとか。女の子でも残っている人いるよね。シリコンいれて治るらしいが。

82 ：デフォルトの名無しさん：03/01/11 13:44

全板を強制IDにするだけでもかなり状況はよくなると思うんだが、、、
はっきり言って、任意IDやIDのない板は酷いし面白くない。

83 ：デフォルトの名無しさん：03/01/11 16:30

そんなことはない。
2ちゃんねるだからなのです。

84 ：デフォルトの名無しさん：03/01/11 16:37

↑
キン肉マンに出てくるｳｰﾙﾏﾝ？

85 ：デフォルトの名無しさん：03/01/12 00:42

2chが2chでは無くなるときが来ましたね。
遊び方の解らない馬鹿が増えたから、しかたないのかもしれません。
もう転載しませんので、以後は該当のスレ追っかけてください

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

こんなところでしょうか。

86 ：デフォルトの名無しさん：03/01/12 00:52

ここで３人くらいが「大丈夫だよ」と言ったら、それを信用して
そういう書き込みを続けるんですか？
まあご自由にとしか言いようがありませんね。
どうせなら「授業料」を支払うことになる限界がどこにあるか見つけてください。

87 ：デフォルトの名無しさん：03/01/12 03:30

いととよう

88 ：デフォルトの名無しさん：03/01/12 03:30

あきらめる(・∀・)

89 ：デフォルトの名無しさん：03/01/12 10:58

　つまんね

90 ：デフォルトの名無しさん：03/01/12 11:02

■「ある発言が名誉毀損かどうかを管理人では判断できない。
　　法廷で判断されてからでもいいではないか」
今回、次のような発言は動物病院にとっては「社会通念上、名誉毀損と容易に推測できるはず」
とされています。
ブラックリスト、過剰診療，誤診，詐欺，知ったかぶり、えげつない病院、ヤブ医者、
精神異常、精神病院に通っている、動物実験はやめて下さい、テンパー、責任感のかけらも無い、
不潔、氏ね、被害者友の会、腐敗臭、ホント酷い所だ、ずる賢い、臭い

91 ：デフォルトの名無しさん：03/01/12 21:32

http://www.liquidgeneration.com/sabotage/vision_sabotage.swf

92 ：デフォルトの名無しさん：03/01/12 21:35

＞59K+TtJ+
ややこしいからそのトリップ使うな。

今回の裁判の話と今後起こりうる訴訟は全然別の話になるだろうから、
（プロバイダ責任制限法と削除システムの変更がある）
ごっちゃにして話をするのは無意味。

93 ：デフォルトの名無しさん：03/01/12 21:46

今後sports3鯖は定期的にhtml化されるの？

94 ：デフォルトの名無しさん：03/01/13 01:33

筑冓H

95 ：山崎渉：03/01/13 18:25

（＾＾）

96 ：デフォルトの名無しさん：03/01/13 22:13

ループコピペ厨は年越しは一人ぼっちの筆記

97 ：山崎渉：03/01/15 17:51

（＾＾）

98 ：井川遥：03/01/16 23:11

（＾＾）

99 ：山崎渉：03/01/23 22:05

（＾＾）

100 ：デフォルトの名無しさん：03/02/08 10:11

ほっしゅ

101 ：デフォルトの名無しさん：03/02/16 22:24

保

102 ：デフォルトの名無しさん：03/02/25 21:18

そろそろか...

103 ：デフォルトの名無しさん：03/03/16 14:25

sage

104 ：デフォルトの名無しさん：03/03/16 17:30

mage

105 ：デフォルトの名無しさん：03/03/16 19:03

アスペクト指向って死滅しちゃうの？？？？

106 ：デフォルトの名無しさん：03/03/16 21:11

まだはやる前だろ。

107 ：デフォルトの名無しさん：03/03/17 22:50

解説見ても分からん
loggerとか言われても意味不明

108 ：デフォルトの名無しさん：03/03/18 02:00

>>105って死滅しちゃうの？？？？

109 ：デフォルトの名無しさん：03/03/18 02:43

lispのadvanceみたいなもの

110 ：デフォルトの名無しさん：03/03/18 02:48

advaiceだった。
http://www.george24.com/~akihisa/texi/elisp-manual-20-2.5-jp/elisp_17.html

111 ：デフォルトの名無しさん：03/03/18 04:55

ふーん、Elispにも、CLOSのMixInみたいな機能が付いたんだー。
アスペクトと MixInて、確かに近いよね

112 ：山崎渉：03/04/17 15:53

（＾＾）

113 ：デフォルトの名無しさん：03/04/18 13:40

http://www.research.ibm.com/cme/
CMEってどうよ

114 ：山崎渉：03/04/20 04:13

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

115 ：あぼーん：あぼーん

あぼーん

116 ：あぼーん：あぼーん

あぼーん

117 ：デフォルトの名無しさん：03/06/23 00:11

知ってる用語を並べてみるスレはここですか?

118 ：デフォルトの名無しさん：03/06/23 00:40

負け惜しみだけはいっちょまえの>>117が居るスレはここですか？

119 ：デフォルトの名無しさん：03/06/23 06:45

煽りだけはいっちょまえの>>118が居るスレはここですか？

120 ：デフォルトの名無しさん：03/06/23 11:02

>>118
>>119
違います。

121 ：デフォルトの名無しさん：03/07/19 00:25

アスペクト指向とは何か?

122 ：デフォルトの名無しさん：03/07/19 01:04

何か？用でつか？

123 ：デフォルトの名無しさん：03/07/19 01:12

AOSD (Aspect Oriented Software Development)
すっかり有名になったねぇー。
JavaWorldでも2chでも取り上げられてるし、
JBOSSやらEclipseでもサポートされ始めたし。

３年前に携帯Javaいじってて、
実行時クラス・サポートを期待できない環境で、
OO的プログラミングをする手法として SoC, AOPを流用できる事を知り、
それやってる所へ話しを聞きに行ったのが、遠い昔のようだ。

ってか、元居た企業でAOP導入進めようとしたらアフォ扱いされた日々が、
遠い幻のようだ（ｗ　あの会社はきっと滅びる（ｗｗｗ

124 ：デフォルトの名無しさん：03/07/19 01:29

>>123
そんなのあるね、片っ端から新しい技術否定するSE。
オマエも折れを同じ嫌われ者かい？

125 ：デフォルトの名無しさん：03/07/19 01:34

どのオマエが折れたんですか？
漏れはあきらめましぇんが。

126 ：デフォルトの名無しさん：03/07/19 01:46

「僕は死にましぇん」のAA希望

127 ：デフォルトの名無しさん：03/07/19 05:35

まぁあれだ、仕事上広範囲なニーズがあって、
それに対する筋の良いソリューションのシーズがあって、
そのシーズを地道に育てる事ができる組織と、
そのシーズをみすみす見逃してしまい、
3年,5年たって世の中に充分普及してからようやく重い腰を上げるださださ組織
の二種類が世の中にはあるってこった。

もう10年以上そんな事の繰り返しなんで、俺は疲れたよ

128 ：p：03/07/19 06:11

まあ、オブジェクト指向も理解が浅いヤツが”たいしたことねーじゃん”って言うのと同じくアスペクト指向も理解が足りないヤツが”たいしたことねーじゃん”って言ってんだろな。
モデル計算とか様相論理とかの研究者って普段活躍の場がない連中だから、こういうのが出てきたとき一気に飛びつく可能性があるよ。
エージェント指向のときもまさにそうだった…。

129 ：デフォルトの名無しさん：03/07/19 07:50

アスペクト指向の指向ってのがオブジェクト指向のパクリみたいで
いまいち画期性に欠けるな。

130 ：デフォルトの名無しさん：03/07/19 08:36

>>129
んじゃ、アスペクト理論にする？
それとも、アスペクト外伝
あるいは、アスペクト比←あ、これは既出だな

131 ：デフォルトの名無しさん：03/07/19 09:38

でもログと認証しか例がないんじゃ説得力ないよな
それぞれ専用のメカニズムを組み込めばいいんだし。
かといってあまり話を広げてもOOPのような体系は
築けない
正直はやらないと思うよ

132 ：デフォルトの名無しさん：03/07/19 11:04

そもそもOOPと相対するもんじゃなくてOOPの弱点を補完する
為の機構だと思うが・・・？

133 ：デフォルトの名無しさん：03/07/19 14:36

>>131
他にも応用可能な分野があるでそ。
・アプリケーションのリファクタリングやカスタマイズ
・ORBや分散トランザクション機能のアドホックな追加

ビュー周り(画面)や、ストレージ周り(DBMS)は、応用例思いつかなかった・・・。

134 ：デフォルトの名無しさん：03/07/19 17:45

>>133
機能と機能の接続部分に着目すべし。

135 ：山崎渉：03/08/02 02:32

（＾＾）

136 ：あぼーん：あぼーん

あぼーん

137 ：デフォルトの名無しさん：03/08/22 19:28

oo2003逝ってきた

138 ：デフォルトの名無しさん：03/08/23 00:45

↑レポートして

139 ：デフォルトの名無しさん：03/08/23 22:39

MixJuice聞いてたからプログラムスライスを用いたアスペクト指向
プログラムのデバッグ支援を聞けなかった。

140 ：デフォルトの名無しさん：03/08/26 21:16

メーリングリストは盛り上がってるね。

141 ：ほっしゅ：03/10/10 00:45

ｽﾚのこの落ちようは無残だな…。

142 ：デフォルトの名無しさん：03/10/18 18:50

さがったなあ。

143 ：デフォルトの名無しさん：03/10/22 15:10

最下層ほっしゅ

144 ：デフォルトの名無しさん：03/10/27 01:34

そろそろ圧縮きそうだな。

145 ：デフォルトの名無しさん：03/10/27 20:43

圧縮来ても、保守しているから大丈夫では？

146 ：デフォルトの名無しさん：03/11/10 16:46

AspectJ

147 ：デフォルトの名無しさん：03/11/13 01:49

保守

148 ：デフォルトの名無しさん：03/11/15 13:27

>>20
も少し具体的にどうやる概念なのか解説ｷﾎﾞﾝﾇ

149 ：デフォルトの名無しさん：03/11/15 13:43

>>148
たとえばいろんなクラスにprintっていうメソッドがあったとして、その後で
　System.out.printlnt("printed!!!");
ってやりたいとする。
そんなとき、普通のJavaだとそのいろんなクラスを変更しないといけないけど、AspectJだとアスペクトをひとつ追加すればいい。

150 ：デフォルトの名無しさん：03/11/15 13:50

アスペクト指向ってオブジェクト指向が全く分からなくても
習得できますか？

151 ：デフォルトの名無しさん：03/11/15 15:48

>>150
一応異なる概念だけど、オブジェクト指向がわかってなければ有効に
使えない。

152 ：デフォルトの名無しさん：03/11/15 22:39

アスペルガかと思った。

153 ：デフォルトの名無しさん：03/11/16 17:23

アスペクト指向ってのは、アスペクトとコアロジックを分離するための
考え方。ロギングが最も一般的なアスペクト指向の使い方だと思う。
例えば、各クラスでロギングAPIを呼ぶってのが、普通のロギング方法だけど、
アスペクト指向では、ロギングアスペクトを定義する事により、実行時または
コンパイル時に各クラスに、ロギングを埋め込む。
つまり、通常は、各モジュールがログモジュールに依存する事になるけど、
アスペクト指向では、各モジュールがロギングAPIを呼ぶ必要が無くなるから、
モジュール間の結合は無(または疎)になり、再利用性が増すと同時に、つまら
んコードを書く手間が省ける。
ロギング以外だと、認証なんかもそうなるね。

Javaだと、aspectj,jboss-aop,aspectwerkz,mixjuiceなんかがAOPの
代表的な実装。バイトコードの書き換えには、bcelや、jassistなんかが使わ
れてる。

実行時変換タイプのAOPフレームワーク(jboss-aop,aspectwerkzなど)
では、クラスローダを変更する事により、クラスコードの変換を可能とし、
コンパイル時変換タイプ(aspectjなど)は、ソースコード又はclassファ
イルを直接変換する。(それぞれonlineコンパイル、offlineコンパイル
とも言う)

いずれも、XMLや、通常のJavaに似た言語などによってアスペクトを定義する。
アスペクトを構成する要素はAdvice、Point-cut、Introduction、meta-data
の4つ。これらの意味が分かれば、何となく使えるようにはなる。

154 ：デフォルトの名無しさん：03/11/16 17:44

meta-dataってのは、プロジェクト毎の決まり事の定義のこと。
詳しくは、JSR 175を見た方がいいかも。例えば、
public void async***(...)
ってメソッドがあったら、これは非同期で実行される、と言ったことを
事前に決めておき、AOPコンパイル時に、実際に、別スレッドで実行される
ようにmeta-dataを定義しておくって感じ。

Introductionは、クラスのsuper classや実装インターフェイス、フィールド
メソッドを変換するための定義。javaのdynamic proxyみたいだけど、もっと
簡単。

Point-cutは、コード中に、切り込みを入れる定義。メソッドの先頭、末尾、
メソッドの呼び出し前、呼び出し後、メソッド全体、メソッド呼び出し全体、
例外発生前、フィールドアクセスなどを定義する。通常は、各AOP独自の
expression languageで指定する。

Adviceは、point-cutで定義したpoint(join pointと言う)で呼ばれる
コードのこと。AOPのメインとなるもの。要するにAdviceでロギング呼び出しや、
認証を行う。
jboss-aopの場合は、interceptとも呼ばれている(Adviceとは違う物を指して
いるかも知れないけど、たぶんAdviceだと思う)。

実際いじってみるのが一番。
aspectjあたりが、参考文献が充実していておすすめ。いずれにせよ、日本語では、
これと言った文献が少ないので、英語の文献をあたるのが良い。

155 ：デフォルトの名無しさん：03/11/18 09:41

↑２ちゃんで散々外出のネタを披露している人が居る・・・今更なんで？
　認証ネタなんて、AspectJの親分が自分で言ってたって上の方に書いてあるやん
　ｱﾌｫ？

156 ：デフォルトの名無しさん：03/11/18 11:34

>>153-154
まとめサンクス。

個人的には、adviceに書くのはglue codeのみにしたいね。
既存のコードに、adviceを使って外部の部品をねじ込んでいく
イメージがいい。
adviceにだらだらコード書いても、そこの再利用性は低いし。

157 ：デフォルトの名無しさん：03/11/18 23:59

>>155
こんな閑散としたスレの上までちゃんと見てるあんたに乾杯

158 ：名無しさん＠Linuxザウルス：03/11/19 01:48

>>1=>>47=>>155ですが、何か？

AspectJの親方に、座席まで出張ってもらって、
「ﾅﾆｶ質問､ｱｰﾘﾏｾﾝｶ? ﾅﾆｶ質問? ｼｰﾂﾓﾝ?」
(Do you have any questions ? Any Questions ? Any Questions ?)
って親切に聞かれましたが、何か？
＃本当に、とても親切で素晴らしい方ですた

159 ：デフォルトの名無しさん：03/11/19 08:07

>>158
要するに、俺 = >>1 = 偉くて凄い、俺以外は皆アフォ
って言いたいのか。

160 ：デフォルトの名無しさん：03/11/19 12:47

>>159
ほっといてやれ。
自分以外にもAspectJを理解している人間がいることを
受け入れられない可哀想なやつなんだから。

161 ：デフォルトの名無しさん：03/11/19 13:03

↑テクニカルなコアの話と、軽薄な煽りを、アスペクトで分離しる

162 ：デフォルトの名無しさん：03/11/19 17:48

↑↑↑このｸｿｽﾚっぽいスレタイ何とかしろ↓↓↓

163 ：デフォルトの名無しさん：03/11/22 02:21

つか、ログと認証以外に良い例ってないの？
導入や導入後のコスト増も馬鹿にならないわけで。
なんだかオマケ機能程度に～指向とは大げさだな、と思ってしまう。

何かわくわくするような良い例おしえてえらいひと

164 ：デフォルトの名無しさん：03/11/22 02:28

>>163
コアな処理と、付随する処理を分離する、という考え方が大切、ということもあるので。
ログと認証で結構十分なきがする。あとはDB接続？

165 ：デフォルトの名無しさん：03/11/22 02:29

あ、あと、メッセージ正規化。エンコーディング変換とか。

166 ：デフォルトの名無しさん：03/11/22 02:31

基本的には、コアな処理と、付随する処理を分離する、ということになるから、アスペクトの例として挙げられるのは、どうしても付随する処理の方になる。
だから、それだけみると、「オマケ機能程度」と思ってしまうのだろう。
コアな処理とオマケ機能を分離するのがアスペクト指向なのだから。

167 ：デフォルトの名無しさん：03/11/22 02:42

おっしゃられる、コアな処理と、付随する処理との定義って何だろう？
付随する処理（雑多であったり、本質ではないもの）を切り出すことによって、
興味がある部分のみを（簡潔に）記述できるから、うれしいってこと？

おもしろそうに聞こえるが、やはり例がほしいところ。
わがままでごめんよ。

168 ：デフォルトの名無しさん：03/11/22 02:45

>>167
> おっしゃられる、コアな処理と、付随する処理との定義って何だろう？

定義はない。

とりあえずオレの考え付いたのは先にあげた
・認証
・ログ
・データベースなどリソース準備
・メッセージなど入出力正規化

169 ：デフォルトの名無しさん：03/11/22 02:53

いや、どういう意味を込めて、コアとか、付随とか呼んでいるのかを聞きたいだけ。

たとえば、メッセージの入出力変換がコアなものになるか、
付随的なものになるかは状況によって異なると思うんですが。

関心を切り分けるという大義名分にはそこはかとない説得力を感じるのですが、
その実はフックに基づくいくばくかの例しか出てきてないような気がして、
どうも消化不良で。

170 ：デフォルトの名無しさん：03/11/22 03:06

>>169

> たとえば、メッセージの入出力変換がコアなものになるか、
> 付随的なものになるかは状況によって異なると思うんですが。

うん、だから、定義はないと。
オレが思ってるのは、169がいってるのと同じ意味だと思うよ。

171 ：デフォルトの名無しさん：03/11/22 03:28

よくわからなくなってきた？
コアな処理とか付随する処理とか言ったが、特に意味はない（処理A、処理B）ということ？

ならば、なぜ、

> 基本的には、コアな処理と、付随する処理を分離する、ということになるから、アスペクトの例として挙げられるのは、どうしても付随する処理の方になる。

のだろう？
あほでごめんよ。

172 ：デフォルトの名無しさん：03/11/22 03:36

>>171
たとえばメッセージを取得してHTMLとして表示するというときに、メッセージ取得したあとで\n-><br>の変換が必要だったとする。
メッセージの取得としてはさまざまな処理があるとして。

としたら、メッセージの取得がコアな処理で、\n-><br>変換は付随する処理。
表示先がHTMLでなければ必要なくなるし、たとえば\n->\n\rという変換が必要かもしれない。
でも、メッセージの取得に関しては変わらない。

やりたいことをやる処理がコアな処理で、それを環境にあわせるのが付随する処理という感じか。

173 ：172：03/11/22 03:39

ちなみにオレはJava質スレの401なのだが、同じ相手とやりとりしている気がする。
気のせいか？

174 ：デフォルトの名無しさん：03/11/22 03:51

うんうん、そういう意味で言っているのはわかるんだよ。
つか、定義あるじゃん。曖昧でなんともいえないが。

でもそれって、高々フックで実現できることの一つであって、
アスペクト指向の応用としてはさんざん既出のものの一つだよね。
だいたい、そういった変換をわざわざアスペクト指向の流儀でやる必要もないと思うし。

フックだけじゃないもっと一般的な概念だという割にそういう実例はないなと。
話がループしてるなぁ。

> 173
・・・どれどれ、って、ちがうｗ
おれはどっちかというと考察の足りなさと不明確な物言いに対して
柔らかな物腰で文句をつけている

175 ：デフォルトの名無しさん：03/11/22 04:20

>>174
フックで実現するためには、いちいちそのフックのコード書く必要があるよね？

176 ：デフォルトの名無しさん：03/11/22 04:49

必ずしもフックのコードを「いちいち」書く必要はないと思う。

仮に書くような状況を想定したとしても、それが本質ではないのでは？
アスペクト指向は、フックのコードを書く手間をなくす仕組み、ではないのだから。
ここはデザインパターン＋リファクタリングの陣営とケンカになるところだそうだけど。

177 ：デフォルトの名無しさん：03/11/22 18:55

C言語であすぺくとしたいんですが、
できますか

178 ：デフォルトの名無しさん：03/11/22 19:14

>>177
コンパイル前のプリプロセッサの形で実現可能じゃない？

179 ：デフォルトの名無しさん：03/11/22 19:22

>>177
http://www.cs.ubc.ca/labs/spl/projects/aspectc.html
とかどうよ？

180 ：177：03/11/22 20:11

>>179
とりあえず関数呼び出しのトレース取ってみたいだけなんですが、

int d(int c) {return c+3;}
int b(int c) {return d(c);}
int a(int c) {return b(c+1);}

とかいうコードがあったら、a(1)の呼び出しで

a(1)
　b(2)
　　d(2) => 5
　b(2) => 5
a(1) => 5

みたいな出力を元コードを変えずにできるんでしょうか

181 ：デフォルトの名無しさん：03/11/24 02:15

>>169
コアな処理
入力(引数)に対し、出力(レスポンス)を返す/状態を変化させる
ための必要最小限の処理
って考えればいいんじゃない。それ以外は付随する処理。

182 ：177：03/11/24 04:32

誰か>>180わかりませんか？

183 ：名無しさん＠Linuxザウルス：03/11/24 04:42

ドキュメントも読めない教えて厨は、質問スレに逝け

184 ：177：03/11/24 04:56

>>180
逆ギレされても困るんですが・・・
ここアスペクト指向のスレだし。
この程度の質問も許容されませんか？

とりあえず>>179のリンク先に行っても、肝心のAspectCの
ダウンロード先とかが見当たらないんですが。

185 ：177：03/11/24 04:57

↑>>183でした

186 ：デフォルトの名無しさん：03/11/24 05:09

逆切れって、何よ？
さっさと質問スレ逝け

187 ：177：03/11/24 05:21

質問スレって、何処の？

188 ：177：03/11/24 05:24

ちなみに>>178が言っている様なマクロで出来るってのはわかってます。
それをAspectCでやりたいんですが。
わざわざここで質問している意図を汲み取ってくださいよ。

189 ：デフォルトの名無しさん：03/11/24 05:26

>177
リナザウ厨＝荒らし
なのでほっとけ。
AspectCについては知らん。

190 ：デフォルトの名無しさん：03/11/24 07:24

結局、解説できる人は一人もいないのですな。

191 ：１ ◆Pv2t5vbKCk ：03/11/24 09:29

さっさと質問スレへ逝け。
わからなかったら、Yahooに関連グループがあるから、
実名晒してそこで聞け。
嵐は首吊れ。

回答は以上だ。

192 ：デフォルトの名無しさん：03/11/28 02:29

C言語でりすぺくとしたいんですが、
できますか

193 ：デフォルトの名無しさん：03/11/28 03:02

>>192
してくれ。
多いに尊敬してくれ。

194 ：デフォルトの名無しさん：03/11/29 00:28

こりゃ誰も実践してないな。１まで
クソスレでした。

195 ：デフォルトの名無しさん：03/12/03 19:54

>177
and we hope to make it publically available soon.
とあるのでAspectCはまだ公開されてない様です｡

http://www.aspectc.org/
というのもありますがcompiler manualのunimplemented featureにmanipulating
C(not C++) codeとあるのでcはまだ使えない模様。

196 ：デフォルトの名無しさん：03/12/03 22:57

aspect cobolはないですか

197 ：デフォルトの名無しさん：03/12/04 18:48

素直にaspectJ使おうよ｡まだ成熟した分野じゃ無いんだし｡

198 ：デフォルトの名無しさん：03/12/04 20:38

//////ここまでよんだ//////
1って痛い奴だな

199 ：デフォルトの名無しさん：03/12/05 20:42

続きは、Yahoo!掲示板で、どうぞ(ﾆｺﾆｺ

200 ：あぼーん：あぼーん

あぼーん

201 ：デフォルトの名無しさん：03/12/07 01:43

aspect cobol
aspecr asmbler
aspect PL1
aspect smalltalk
aspect c#
aspect ruby
aspect php

202 ：デフォルトの名無しさん：03/12/07 13:08

やっぱり、コア+雑事なのか？
観点Aのコア+観点Bのコアできれいに書けて、かつ
「+」もきれいにできるものを期待したのだが。
OOなら、OOなりのアプリのきれいな書き方というのはある。
AOはコアをピュアにしていくのはいいが、はじかれた雑事は、
きれいに書かけるのか？きれいにコアとコラボレートするのか？
そうでなければ、「指向」を名乗るのはいかがなものか。

203 ：デフォルトの名無しさん：03/12/07 18:51

>>202
＞やっぱり、コア+雑事なのか？
＞観点Aのコア+観点Bのコアできれいに書けて、かつ

コア＋雑事と言った場合の雑事は、観点Aのコアにも観点Bのコアにも
ならないって事も、暗に言ってるわけね。
その雑事とは例えば何？（まさか、またログ？）
それと観点Aと観点Bって、それぞれどんなの？
そもそも「コア」と「雑事」を対立概念として共起させてる、冒頭の「やっぱり」
ってなに？

＞はじかれた雑事は、きれいに書かけるのか？きれいにコアとコラボレートするのか？
＞そうでなければ、「指向」を名乗るのはいかがなものか。

「指向」自体を検証する事にどんな意味があるのか分からないけど、
結果としてきれいかどうかは場合によりけりでしょう。
たとえば「雑事アスペクト」とかいったものを作って、コア（？）じゃない
コードをまとめて一緒くたに放り込んだら、十分汚くなるだろうし。

204 ：デフォルトの名無しさん：03/12/07 20:53

Jboss　AOLに期待しましょう
JBが簡単にEJBになるそうです

205 ：デフォルトの名無しさん：03/12/08 00:47

>>202
"コア+雑事"で語られることが多いけど、それはわかりやすさの
ためであって、基本的には"観点Aのコア+観点Bのコア"が正しいと思う。
ただ"+"の部分がきれいになるには、もう一工夫欲しい。
リフレクションやメタデータを活用すればきれいになりそう。

206 ：202：03/12/08 01:52

>>203
「雑事」が観点B,C…になるというつもりで書いた。
> 結果としてきれいかどうかは場合によりけりでしょう。
アフォが書いたら汚くなるのは仕方ないが、OOでOO的解決があるように
AOはそういう風に一般にきれいに書ける能力があるものなのかってこと。
さらに、AOはそれをweaveするのが前提だから、そこもきれいに書け？ないとね。
ちゅうわけで、>>205で納得。AOは（少なくとも今は）指向とまでいえる能力を持たない。

207 ：205：03/12/08 12:30

>>AOは（少なくとも今は）指向とまでいえる能力を持たない。
微妙な表現になるけど、俺の印象としては、
AOは十分指向と言えるレベルにあるが、指向を実践できるだけの有効な
実装が存在しない状態だと思う。
ただ現状ではOOをベースにしないとなかなか使える実装はできないので、
まずはできることをってことでAspectJやJBoss AOPが存在する。
実際純粋AO派からは、「AspectJなんてAOPじゃねぇよ」って言われてるし。

現状OO前提で行かないと使える実装にはなんないので、必要なのは
純粋なAOをOOに乗せる工夫だな。

208 ：デフォルトの名無しさん：03/12/08 21:02

>>実際純粋AO派からは、「AspectJなんてAOPじゃねぇよ」って言われてるし。
なぜじゃ！理由は？

209 ：デフォルトの名無しさん：03/12/08 22:26

だがJBをEJBに自動的に変換してくれるのはすごい
どう思う？みなの衆

210 ：デフォルトの名無しさん：03/12/08 22:32

MixJuice使ってるけど、イイよ

211 ：デフォルトの名無しさん：03/12/08 23:17

>>208
詳細忘れた。
調べるのめんどい・・・

212 ：202：03/12/09 00:22

>>207
≫AOは十分指向と言えるレベルにあるが、指向を実践できるだけの有効な
≫実装が存在しない状態だと思う。
≫実際純粋AO派からは、「AspectJなんてAOPじゃねぇよ」って言われてるし。

実装の問題なのか？　そもそも実装に関係なく、いろんなAspectを、
一般にきれいにweavingできるような理論なり、プラクティスがあるのか？
元々出来っこない事を出来ると仮定した妄想語っても、それは純粋××派ではなく、
ただの電波と思われるが、いかがなものか？
偽を前提とすれば、なんだっていえるからな。F⇒T，F⇒Fどっちも真。

213 ：202：03/12/09 00:40

>>210
みたけど、friendを洗練させたってこと？
しかし、モジュールごとにひとつのオブジェクト（クラス）の意味っつーか、
定義が変わっていくのはいかがなものか。
すなおに子クラスとかで必要なinterfaceを多重実装したほうが判りやすいのでは？
そんなことない？

214 ：デフォルトの名無しさん：03/12/09 04:27

ｃ＋＋がオブジェクト指向でないという屁理屈と同じだよ

215 ：デフォルトの名無しさん：03/12/09 11:23

>>212
いやいや。実装と独立して語られるのは当然でしょ。
問題は、AspectJなどの実装を見て、「アスペクト指向は～」と語ること。
特定の実装を元に語るのなら、「AspectJは～」って感じに限定すべきだ。

まあ、あれだよ。オブジェクト指向とC++の関係と同じ。
オブジェクト指向を語るんなら、C++に縛られてはいけない。
アスペクト指向を語るんなら、AspectJに縛られてはいけない。

216 ：202=212：03/12/09 12:48

>>215
>>212 は貴殿のその主張を前提としたレスのつもりだが？
「そもそも実装に関係なく、いろんなAspectを、一般に」と実装非依存の
AOについて問うているつもりだが？

217 ：デフォルトの名無しさん：03/12/09 21:40

>>216
そうなのか。
だとすると言いたいことがよくわからん。
207の俺の意見に反対してるのか、純粋AO派を非難してるのか。
あとAspectを名詞で使ってるけど、何を意図してるんだ？

ちなみに、俺の言う「実装」は、処理系って意味で使った。
アスペクト指向により分離される実装コードとは意味合いが違う。

218 ：デフォルトの名無しさん：03/12/09 22:06

>>213
子クラスの名前を考えるの大変でしょ。

SoCとか再利用性とか考えなくても、インクリメンタルな開発をしている時に
クラスにメンバーをあとから追加することってあるでしょ。
そういう時に便利。

219 ：デフォルトの名無しさん：03/12/09 22:57

単なる横断だけがメリットのaspect指向は糞

220 ：202=212=216：03/12/09 23:04

>>217
純粋AO派、ないしはAOそのものを非難している。
俺の言う実装は貴殿の言う実装と一致する。
Aspectは、AOのAを言っている。
AOはweaveが前提と考えるが、十分なweaveは現実に可能なものなのか。
AspectJがへぼいのではなく、そもそも出来ないのではないか。
またはそれを支援する理論もプラクティスもないのではないか。

221 ：202=213：03/12/09 23:29

局所的にモジュール化して影響範囲を押さえるということ？
後から後からそんな事してたら、
ぐちゃぐちゃで手に負えないものが出来あがると思われ。
ふつうにめんばを追加してクタればいいのでは？

222 ：デフォルトの名無しさん：03/12/09 23:44

>>220
＞AOはweaveが前提と考えるが、十分なweaveは現実に可能なものなのか。
＞AspectJがへぼいのではなく、そもそも出来ないのではないか。

今のところAspectJで十分だなあ。Javaだけじゃtanglingだのscattering
だのは、どうしも避けられないしさ。別に不満なくきれいにweaveできるし。
ところである特定の実装を有用なものにしている方針が、あるアイデアに
基づいているとして、それを「指向」と呼んだところで誰も困らないと思う
んだね。

223 ：デフォルトの名無しさん：03/12/10 00:20

>>221
クタるってなに？

やろうと思えばぐちゃぐちゃにもなる。
が、普通の人はそうはしない。

224 ：202=220：03/12/10 00:30

>>222
AspectJを使いこなしてそう。どんなのをAspectにしている？
そうそういろいろAspectにできるもの？

225 ：205=207=211=215=217：03/12/10 00:32

>>220
まあ、そこまできてるんなら、いっぺん自分でいろいろ調べてみるのがいいのでは。
そもそも出来ないのかどうなのかは難しくても、それを支援する理論や
プラクティスがあるかどうかは調べればわかるっしょ。
「十分なweave」の意味するところがどうもかなり高尚っぽいので、何とも言えない。

俺にはAspectJは十分使えて、研究開発のベースの一つにしてるし、
今後もそうし続けるつもり。

226 ：デフォルトの名無しさん：03/12/10 07:26

＞俺は～で十分
はいはい。
一人でやってなさい。

227 ：デフォルトの名無しさん：03/12/10 22:53

>>俺にはAspectJは十分使えて、研究開発のベースの一つにしてるし、
>>今後もそうし続けるつもり。
何を研究しているのですか？
エロですか

228 ：デフォルトの名無しさん：03/12/10 23:13

研究開発のベースってぇと実務で使ってねぇのかよって思われちまうな。
いや実務もやってるのだけど実際そっちでは使ってない。

使える感触はあるのだけど、開発ツールのサポートが無いと俺しか使わな
そうなので、導入してない。
誰か実務で使ってる人いる？

229 ：202：03/12/11 00:56

>>225
≫「十分なweave」の意味するところがどうもかなり高尚っぽいので
高尚とか言うわけでなく、AOのポテンシャルを知りたい。
ログとかしょぼいのだけじゃなく、*一般に* AOはホントに使えるのか、
つまり、
　オブジェクト脳ならぬアスペクト脳で、
　AO的にクールなコードで
プログラムを書く、
ということができるものなのか、ということを問いたい。

>>222 AspectJを使いこなしているようだが、どうか？

230 ：デフォルトの名無しさん：03/12/12 02:54

横断（トリガー）以外なんかメリットあるんか

231 ：デフォルトの名無しさん：03/12/12 02:55

見ての通りですが何か

232 ：デフォルトの名無しさん：03/12/12 07:34

ないということですね？
トリガー以外特徴はないですね

233 ：デフォルトの名無しさん：03/12/12 07:37

まあ>>44が全てです

234 ：デフォルトの名無しさん：03/12/12 10:54

無理に既存の知識に当てはめようとすると、本質を見失うよ。

235 ：デフォルトの名無しさん：03/12/12 17:25

じゃあ、あなたの言う本質を語って下さいよ。

236 ：デフォルトの名無しさん：03/12/13 20:21

ネーミングが気に食わん。
オブジェクト指向っていうのはよく出来たネーミングだと思うが、このアスペクト指向ってのはいわばオブジェクト指向のパッチみたいな存在なくせに新たに指向とつく言葉を作る事で別のパラダイムがある、オブジェクト指向の「次」という印象を与える。
オブジェクト指向はデータと挙動の関係がひっくり返った、指向、Orientedって言葉にはそれだけの重みがある。しかしこのアスペクトは同じ指向ってだけの重みは無い、付け足しだからだ。
ただでさえ用語が氾濫する世界なのに、新たな概念入れるときはこの辺十分わきまえて伝道してほしい。この言葉作った奴の自己満足にしか思えんな。
アスペクト拡張オブジェクト指向でいいだろ。これでくだらん前置きの説明が省く事ができると思う。

237 ：デフォルトの名無しさん：03/12/13 20:23

＞＞オブジェクト指向のパッチ
ｗ

238 ：デフォルトの名無しさん：03/12/13 20:25

国内では使用禁止だよ。
なんでも、肺がんを誘発するとか。

239 ：デフォルトの名無しさん：03/12/13 20:27

>>237
そういうレスは余裕で予想できるが、ｗの根拠をぜひ教えてもらいたいね。
確かに自分はこれをさっきざっと見たが、それ以上のものは見つからなかったが。
実装で、こうすれば複数のオブジェクトのまたがるメソッドを「織り込めます」って「メリット」を説いていたが、
/eclipseでも対応したとか、簡単にプリプロセスで付け足されてるんじゃないのかね？
オブジェクト指向のパッチじゃないの？

240 ：デフォルトの名無しさん：03/12/13 20:41

要するにさ別スレで既出したが、DOSコマンドで
COMMAND FILE1, FILE2...　
がOOで
FILE1.COMMAND1 COMMAND2...
とひっくり返った、要素が逆転したわけで相互関係における矢印、つまり指向がひっくりかえった。

しかしこの「アスペクト指向」ってのはその後に
ただしCOMMAND3はFILE４とFILE6に共通。っていう方法を付け加えただけ。関係をひっくり返すというだけの激しいパラダイムの変化など無い。
それを同レベルの「指向」ってネーミングを与えた事は間違いで誤解を与えるだけだと思う。
別にこの方法の便利さを否定しているわけではないよ。ただ単なる拡張だろうよ、って事。

241 ：デフォルトの名無しさん：03/12/13 20:59

×　 AO (Aspect Oriented )
○　AEOO　(Aspect Extended Object Oriented)

242 ：デフォルトの名無しさん：03/12/13 21:39

>>240
一見ただのポリモーフィズムに見えてしまう

243 ：202：03/12/13 22:39

「指向」なんて言っちゃったのは、PARCの誇大自己宣伝だろう。
特許もとってるから、PARCに本社から儲けるよう圧力が掛かってるのだろう。
幸か不幸か、外からは、「PARCから次が出た！」と
同分野とのバランス的には過剰に受け入れられてしまった。

244 ：デフォルトの名無しさん：03/12/13 22:49

PARCはイーさネット・オブジェクト指向現在の基礎技術を
形成した研究所だｋがアスペクトも商品化には失敗しそう
技術はいいのにね。

245 ：デフォルトの名無しさん：03/12/13 23:02

もっと言ったら、VisualStudioNetとかIDEのマクロでも実現できそうだな。プリプロセッサとか。
正直それくらいの価値しか見えん。まあ言語レベルでやれば見通しはよくなるがな。

246 ：デフォルトの名無しさん：03/12/13 23:27

Eclipseでもチャレンジしようと言う動きもあるっぽいね
IBMががんばって研究しているらしい

247 ：デフォルトの名無しさん：03/12/14 00:19

せっかく有益な議論になるかと思ったら、なんだか電波じみてきたな。

今のAspectJは、その場しのぎの実装だと思えばいい。
AspectJ=アスペクト指向では無い。
でも、アスペクト指向の実践を楽にしてくれるツールではある。

248 ：222：03/12/14 01:41

>>229
＞>>222 AspectJを使いこなしているようだが、どうか？

遅レス、すまん。
いやあ、まだまだ使いこなしてるとは言えないレベルだけど、リソース
管理とかデザパタとかありがちな使い方は一通りやってるよ。ログが
しょぼいとも思わないしさ。
ビジネスロジックも上手く導出できればアスペクトにするけど、この辺りは
まだ勉強不足だな。しょせん誰かがやってるのを真似してるに過ぎない
んで、情報源が足りないと難しいね。
それと俺は呼び名にはこだわらないな。
使えればそれでいいし、無駄な理屈は嫌なんだよ。

249 ：デフォルトの名無しさん：03/12/16 11:49

ダイクストラの構造化手法が生まれたとき、
構造化手法からオブジェクト指向分析にシフトしたときは
それぞれ画期的な変化に見えたが
アスペクト指向はまだまだまだ自分の内では謎が多く画期的なのかよくわからない。

今回のアスペクト指向はどうなりうるのか？
C++やってからJavaやったときは非常に新鮮味を帯びたが
その後にC#やっても、すでにやったことがあるものを再びやっているようで新鮮味が感じない、
アスペクト指向もそのように新鮮味が感じないということは・・・・？

どうなんですか？

250 ：デフォルトの名無しさん：03/12/16 15:52

>>249
> C++やってからJavaやったときは非常に新鮮味を帯びたが
え？具体的にどこが新鮮なんでしょうか…
C++ → Java よりは
Java → AspectJ の方がまだ新鮮味があると思いますが．

251 ：デフォルトの名無しさん：03/12/16 16:23

C++とJavaは同じオブジェクト指向でも世代が違うからね。
JavaとC#は同じ世代だから新鮮味はないだろ。

アスペクト指向はパラダイムが違うわけだから

252 ：デフォルトの名無しさん：03/12/16 21:06

パラダイムが違うって奴は具体的にどの辺ががらっと変わったのかぜひ説明してもらいたいね。
オブジェクト指向はデータと挙動の主従関係の逆転という言葉で説明できる。
パラダイム指向は何がどう変わったのか説明できるんだろうな？

このスレにはそんなパラダイムの変化を感じさせるレスはひとつとしてないし、俺が読んだソースにもない。
パラダイムの変化なんてものはわかりやすいもんだ。本当にそんなものがアスペクト「指向」にあるのなら簡単に説明できるはず。

253 ：デフォルトの名無しさん：03/12/16 23:49

>>252
アスペクト指向がオブジェクト指向に取って代わるような話は聞かないし、
大げさなものを期待してるのは、逆に>>252氏だけのように見えるよ。

>>251氏も違うと言ってるだけだしさ。違うものを同じとは言えないからね。
そもそも違うという事自体が分からないとしたら、まずは一人で落ち着いて
分かるまで調べたり考えたりすると良いかも。

あと現に指向してるんだから指向なんだろうけど、何か心配かな？
「指向」の意味が難しいのかもしれないから、一応貼っとくね。
あとorientedとかで引いてみても良いしさ。悩みが解決する事をお祈りするよ。

しこう　―かう 0 【指向】

（名）スル
(1)ある目的を目指して向かうこと。志向。
「医を―する」
(2)ある特定の方向を指定すること。ある方向に向けること。
「探知機が発信源を―する」

254 ：251：03/12/17 03:26

252はオブジェクト指向とアスペクト指向が直交することに気付いてないようだ。
べつにアスペクト指向になったからといってオブジェクト指向じゃなくなるわけではないし、アスペクト指向のためにオブジェクト指向が必要なわけでもない。
パラダイムの「変化」ではなくて、「相違」ね。

255 ：デフォルトの名無しさん：03/12/17 03:30

「～指向」で括るとろくなことが無い

256 ：236,252：03/12/17 10:12

>>253
>>254
パラダイムってのは枠組みが大きく変化するときに使われる言葉であって、オブジェクト指向はそれだけのものがあった。パラダイムの相違なんて適当な言葉だな。
アスペクト指向は「指向」っていうことによって同レベルに感じさせる。しかしそれだけの変化はない。繰り返しになるが、オブジェクト指向の「不便なところを拡張した」ものだ。

最初っからさ、アスペクト拡張オブジェクト指向っていう風にすればいいのに。

257 ：デフォルトの名無しさん：03/12/17 10:43

これから発明されるプログラム技術はすべてＸＸ指向って名前がつくだろう。
なぜならパラダイムの相違があるからだが、それらは常にオブジェクト指向と直交するだろう。。。

258 ：デフォルトの名無しさん：03/12/17 12:29

>>256
やっぱ、「指向」や「パラダイム」に崇高なものを求めてることが、
そう思わせる原因じゃないのかねぇ。

それと、アスペクト指向を実際に適用するには、対象言語において
ジョインポイントを定義する必要がある。それは当然既存の言語
要素(における構造を識別するもの)なわけで、JavaだろうがCだろうが、
その言語の特徴に依存する。
もしそこだけを見てこれはオブジェクト指向の拡張だって言ってるんだと
したら、完全に本質を見誤ってるな。

259 ：デフォルトの名無しさん：03/12/17 14:44

>>258
崇高だとか、期待とかそういうものは無いよ。
事実としてオブジェクト指向というものがあってそれが大きな節目になっている。
それ以前には何か指向って名のつく技術はあったかい？
当然、新たに指向ってついた技術が出ればＯＯを連想するし、同じ座標軸にある次のものっていう印象を受ける。
構造化＞オブジェクト指向＞アスペクト指向みたいに普通思うよね。それはこのスレの一連のレスを見ても明らか。
こういう無駄な誤解、議論を生むのは開発者のネーミングの仕方、エゴじゃないのかね？

260 ：デフォルトの名無しさん：03/12/17 15:20

構造化とオブジェクト指向も同じ座標軸にはないな。

261 ：デフォルトの名無しさん：03/12/17 15:23

GUIプログラムのためにオブジェクト指向が発展したように、Webプログラムのためにアスペクト指向が発展するのさ。
っていうのは間違ってる？

262 ：デフォルトの名無しさん：03/12/17 16:11

>>260
構造化、オブジェクト指向、メタプログラミング、アスペクト指向はそれぞれ直交した概念、と。
「パラダイム」っていうからには完備性が要求されるから、直交する他の概念の方が補助的な
ものであるというくらいにアスペクト指向で徹底された構築物がないとパラダイムとはいえない
ような。。。

って書いてて思いついたけど、プロトコルスタックとか Windows の wdm ドライバの仕組みは
非常にアスペクト指向なような気がする。。

263 ：デフォルトの名無しさん：03/12/17 17:36

パラダイム
--- ある一時代の人々のものの見方・考え方を根本的に規定している概念的枠組み

確かにアスペクト指向はそこまでのものではないな。

264 ：デフォルトの名無しさん：03/12/17 20:17

>>259
> 構造化＞オブジェクト指向＞アスペクト指向みたいに普通思うよね。

トレンドとしては俺もそうとらえてるけど、それと技術的な部分とはまた違うよね。

っつーか。要は、「誤解したじゃねーか！紛らわしい！」って言いたいだけだよな？
もしかして本気で「アスペクト指向はその呼び方を変えるべきだ。」って主張してる？
だとしたらコミュニティとかそこの偉い人とかに直接言っとくれ。

265 ：デフォルトの名無しさん：03/12/17 20:30

大々的に呼び方が変わったら間違いなくそれに従うけど、
現時点、会話の中で「アスペクト拡張オブジェクト指向(w」とか
言いたくないな。馬鹿だと思われちゃいそうで・・・

266 ：デフォルトの名無しさん：03/12/17 20:37

言葉の問題は、観点が違うという程度のことを
「『パラダイム』が違うわけだから」って言い出した人がいけないんじゃない？
パラダイムって言いたかっただけと違うんか、と。

それはそれとして filter っていう概念はデバイスドライバや web server では
一般的なものだけど、これってアスペクト指向的なんですか？＞識者の人

267 ：デフォルトの名無しさん：03/12/17 23:25

filter 自体はアスペクト指向じゃないんじゃ。。。

268 ：デフォルトの名無しさん：03/12/17 23:36

ええと、ドライバや web server の仕様自体は「オブジェクト指向」で分析されて
いて、pipe & filter っていう「アーキテクチャ」を用いようとするときに、
「アスペクト指向」でモジュール化をおこなうと、すっきりとプログラムとして
書けるっていう。。。

269 ：デフォルトの名無しさん：03/12/17 23:41

ここにははじめて書いたけど、、ちょうど、やっているところなんで論文に
でも書けるときが来たら。。。ともかく、それぞれ違うものであることは
確かなはず。もともといる識者のみなさんはどう思うか。。。

270 ：デフォルトの名無しさん：03/12/18 00:14

>>268
おっ。なんかちょっとまとまってるっぽいぞ。

ただ、本筋は横断的な関心にあるので、一カ所のフィルタに
処理をはめ込めるってだけでは、アスペクト指向というのはちと苦しい。
アプリケーション内のいろんなところにフィルタがあって、
任意箇所(一つでも複数でも)にざくっと処理を追加できれば、アスペクト指向と言える。

どうもフックやフィルタなどの、個々のジョインポイントを実装する
部分に目が行きがちなんだけど、それらを束ねたポイントカットに対して
処理を編み込めるところが、アスペクト指向の特徴なんだな。

とかわかった風に書いてるけど、間違ってたら突っ込んで > 詳しい人

271 ：268：03/12/18 00:18

> >>268
> おっ。なんかちょっとまとまってるっぽいぞ。

ありがとう。

> 任意箇所(一つでも複数でも)にざくっと処理を追加できれば、アスペクト指
> 向と言える。

なるほど。

アスペクト指向関係なひとが近くにいないんで、ぜひ議論に参加させて
くだされ。

272 ：202：03/12/18 01:38

構造化は、関数（プロシジャ）を作ることでプログラムを作る。
オブジェクト指向は、オブジェクトを作ることでプログラムを作る。
アスペクト指向は、アスペクトを作ることでプログラムを作る、のか？

まあ、「おまいが「指向」の言葉に乗せせられすぎ」という指摘は、
そうかもしれない。であれば、このスレ住人は、
　アスペクト指向は、構造化やオブジェクト指向ほどはすごいものではない、
で同意？

273 ：デフォルトの名無しさん：03/12/18 02:11

>>272
申し訳ないが、ある技術がある技術より凄いと結論付けること、
もしくは直交する技術間に優劣を付けることについて、あまり関心が無い。

274 ：デフォルトの名無しさん：03/12/18 03:05

直行する技術間にも、優劣ではなく、インパクト規模の違いというのはあると思うが。
一般にもう片方のスレタイみたいな理解のされ方がされてる節があるので、
きちんと捉えるのはよいのではないか。
AOは、構造化やOOのレベルのものではなく、DbCみたいな位置づけが妥当か？
アスペクトを作る事でプログラムを作るのでなければ。

275 ：デフォルトの名無しさん：03/12/18 08:07

>>272
>構造化は、関数（プロシジャ）を作ることでプログラムを作る。
>オブジェクト指向は、オブジェクトを作ることでプログラムを作る。

ここまでは、まあまあ、あたってるのでは？

一般論として Java とか C++ とかは「オブジェクト」の中に「プロシージャ」
を内蔵できるので、オブジェクト指向だけで書く。構造化だけで書くと
いうのはないよな。

>アスペクト指向は、アスペクトを作ることでプログラムを作る、のか？

で、これはびみょーなんだが、いろいろな「オブジェクト」の中に「アスペクト」
をねじ込むって感じでは？だから、これもオブジェクト指向だけで書く
アスペクト指向だけで書くっていうのはないと思う。

優劣っていうよりは、A+B よりは A+B+C のほうがいろいろと書き方が
あるよねって言う程度だよね。オブジェクトだって理解できないひとだと
かえってスパゲッティになるように、アスペクトが理解できない人には
余計なお世話。実際に書いてみればわかるよ。

276 ：デフォルトの名無しさん：03/12/18 09:26

>>274
＞AOは、構造化やOOのレベルのものではなく、DbCみたいな位置づけが妥当か？

分析、設計、実装それぞれに関わる事だし、少なくともそれよりは普遍的だと思うんだがね。
一般論としてのAOで言えば、別にオブジェクト指向の拡張ってわけでもないしさ。

そういえば、>>268のPOSAもpattern-ORIENTED software architectureだけど、
こういうのも気になっちゃうのかな。

277 ：デフォルトの名無しさん：03/12/18 10:15

理論としては、AO は OO と別なのは同意だな。実践では、OO と組み合わ
せて使うことがほとんどなのも確かだね。漏れは、AO の分析はあまり意識
したことがなくて、設計、実装のときに意識するんだけど。AO分析に関しては
割と自明に思えてしまうところがあるんだけど、AO の分析の理論を書くと
するとかなり難しいかもね。

278 ：デフォルトの名無しさん：03/12/18 10:26

というより、分析が自明に思えたときは、設計、実装がうまく行くときなんだ
よね。分析に「なぜこうなる」がないので、いつもうまく行くとは限らないと
言われてもしょうがないんだけど。

279 ：デフォルトの名無しさん：03/12/18 18:06

　　ねぇ、Yahoo!掲示板でやろうよ、こーゆーendlessな謎議論はさぁー。

　　スレ汚し(・Ａ・)ﾖｸﾅｲ！

280 ：デフォルトの名無しさん：03/12/18 18:08

　　２ちゃんの問題は、

　　究極の暇暇人間が、全板全スレ巡回して、訳のわからん戯言を100でも200でもレスし続ける所だ罠。

　　モデレーテッドで実名onlyのYahoo!でやろうぜ、こーゆー訳わかんない議論はさぁー。

281 ：デフォルトの名無しさん：03/12/18 20:00

>>270
>任意箇所(一つでも複数でも)にざくっと処理を追加できれば、アスペクト指向と言える。

Windows の wdm ドライバモデルでいる filter driver の概念とか、
プロトコルスタックへのプロトコルやドライバの追加なんかはまさにこういう感じですよね。

282 ：１：03/12/18 20:21

おまぃら、知ってる言葉全部並べて、スレ潰す気ですか？

283 ：デフォルトの名無しさん：03/12/18 20:23

>>253
あぁ、辞書厨の文系のあの人ね。
まったく、全板くまなく糞を撒き散らして、
ご苦労なこった

284 ：デフォルトの名無しさん：03/12/18 22:03

>>279,280,282
汚しているっつか保守してくれてんじゃん？w
他に話題ないじゃん．
あるならどんどん振ってくれや．

285 ：→：03/12/18 23:51

>>282
そういうの止めれ。本当の1が迷惑するだろ。

286 ：デフォルトの名無しさん：03/12/19 01:21

低脳MS厨が迷い込んで暴れてるな。
つまらん荒らししてないで、C#の属性についてでも語れよ。

287 ：281：03/12/19 03:08

足りない頭絞って実例あげてネタ振っても反応なし……
てかみんなドライバとか書かないの?

288 ：デフォルトの名無しさん：03/12/19 05:32

>>287

組み込み系の人じゃないとドライバ書く事はまず無いんじゃない？wdm作成した事
ある奴なんて殆どいねーと思うが…｡つーか281はどんなの書いた事あんの？

289 ：デフォルトの名無しさん：03/12/19 12:25

yahoo 掲示板のアスペクト指向板のアドレスを教えて。
あと、egroups に ML あるけどなんで流行っていないの？

290 ：デフォルトの名無しさん：03/12/19 13:21

>>288
あんまり書くと特定されそうなのでアレだけど、
Windows用に IP in IP トンネルデバイスとか、
linux 側でその逆とか。。

291 ：デフォルトの名無しさん：03/12/19 21:26

>>264
まあそのとおり。ややこしいネーミングするんじゃねえよ、と。それに乗せられているような人が多いように感じられたので釘もさしておきたいってのもあるかな。
文字通りパラダイムの変化があったオブジェクト指向の「指向」という冠をとってるのは明らかにOO意識しているだろうね。それで、後からいやいや直交する概念にすぎず、OOほどのパラダイムの変化があるって思うのは君たちの勝手な妄想だよみたいな姿勢じゃないの？
OOの専門用語もそうだが、プログラミングの専門用語はもっと注意深く命名されるべきだと思う。ただでさえ複雑になってきているんだからね。

292 ：デフォルトの名無しさん：03/12/20 00:18

>>291
＞釘もさしておきたいってのもあるかな。

何様だ？馬鹿。いいから逝け。

293 ：デフォルトの名無しさん：03/12/20 00:36

>>292
だまれ。

294 ：デフォルトの名無しさん：03/12/20 01:02

おまえら「オブジェクト指向」に騙されてるぞ。
「オブジェクト指向」と一括りにされて、うやむやにされた技術は、
実はほとんどが「オブジェクト指向」とは全く関係ないものばかりだ。
俺達は「オブジェクト指向」という言葉に踊らされているのさ。

295 ：デフォルトの名無しさん：03/12/20 03:44

いやまあ、一般消費者なら誇大広告だってのも通じるかもしれんが、
技術者なんだから自己責任でいいだろ。

ほんとに有効な釘を刺したいんなら、それなりの成果を出して有名になって
影響力を持って、それからにしろ。
別に有効じゃなくてもいいなら2chでいいけどさ。

296 ：デフォルトの名無しさん：03/12/20 07:27

ここで出てくる「構造化」も「オブジェクト指向」も俺様勝手定義ばかりでうんざり

297 ：デフォルトの名無しさん：03/12/20 11:20

話のすり替えばっかりだな。要するにアスペクト指向ってのは名前から印象づけられるほどインパクトはないってことだ。

298 ：デフォルトの名無しさん：03/12/20 11:32

やれやれまたか・・・
＞名前から印象づけられるほどインパクトはないってことだ
何度も言うけど、それはお前の勝手な妄（ry

299 ：デフォルトの名無しさん：03/12/20 11:43

>>298自体も勝手な妄想じゃないのか？

300 ：デフォルトの名無しさん：03/12/20 11:48

主張を通そうとするなら、それなりに説得力が無きゃね。

んでは次の人、
「アスペクト指向」としてインパクトが得られそうな事柄とは？
↓

301 ：デフォルトの名無しさん：03/12/20 12:50

現実世界でも、なんで自分が馬鹿にされてるのか分かってなさそう。

302 ：デフォルトの名無しさん：03/12/20 14:44

またおかしくなってきたな。
まあ、この程度はよくあることだが。

騙されたって感じたんなら、自分を誉めて、より勉強するなり、
実践するなり、もっと生産的な方向にシフトしろよ。
技術者としては喜ぶべきことじゃねーか。
また一つ賢くなったってことなんだから。

303 ：デフォルトの名無しさん：03/12/20 15:30

まあ、いいじゃねぇか。
「悪徳詐欺に騙された！」と表明があるのは、
他の奴が同じ詐欺で騙されなくなる効果はあるだろ。
AOは、知らない奴が名前を聞いたらかなりの奴が騙されるだろ。

304 ：デフォルトの名無しさん：03/12/20 17:48

↑↑↑アスペクト指向とは何か↓↓↓

A.　悪徳詐欺。

305 ：real >>1 ：03/12/20 18:08

■■■■終了■■■■

306 ：デフォルトの名無しさん：03/12/20 19:34

ひとりだけが批判していると思い込んでいる人がいるな。
そもそも自分は技術者でもないし。

307 ：デフォルトの名無しさん：03/12/20 19:36

>>303
そうそうそれが普通の感想。こういう表明があるのは当然のこと。

308 ：real >>1 ：03/12/20 20:18

１です。
永きに渡り、皆様のご愛顧を頂いた本スレですが、
糞粘着が発生し、正常な議論が期待できなくなったため、
一旦スレッドを終了します。

　　　　♪♪♪♪続きは、Yahoo!egroupでどうぞ♪♪♪♪

■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■完■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■

309 ：デフォルトの名無しさん：03/12/20 21:24

egroupsのaosd-jpは何であんな惨憺たる状況なんだろ。

310 ：デフォルトの名無しさん：03/12/21 01:11

１ってガキみたい

311 ：202：03/12/21 02:58

糞粘着って俺のことか？
とりあえず、↓の意図と背景認識を問いたい。

282 ：１：03/12/18 20:21
おまぃら、知ってる言葉全部並べて、スレ潰す気ですか？

312 ：デフォルトの名無しさん：03/12/21 13:35

>>299は>>298が「インパクトがある」って主張してるとでも思ったのかね

313 ：202：03/12/21 14:18

ちなみに、2つをのぞいてレスはいずれも202を名乗っている。もちろん299は俺ではない。
1が被害妄想に苛むのは、なにゆえか。単純に1が病人であるだけか？
そうでないなら意図と事情を問いたい。

314 ：デフォルトの名無しさん：03/12/21 18:56

>>290
ネットワークカードのデバイスドライバですかね。最近の連中だとアセンブラ書ける
奴自体が少数派だろうし、デバイスドライバ書ける奴はもっと少ないと思いますよ｡

315 ：デフォルトの名無しさん：03/12/21 21:18

>>310
また、きみか。
いい加減、実名晒して議論したらどうよ(苦笑

316 ：デフォルトの名無しさん：03/12/21 22:29

その辺の本をちょっと斜め読みしただけなんだけどさ、
アスペクト指向って、一言で言えば「逆 #include」みたいな感じ？
#include を使って、「どこそこのコードをここに挿入せよ」と指定する記述の逆で、
hoge.h に、「このコードをどこそこに挿入せよ」という指定が並んでる、みたいな。

317 ：デフォルトの名無しさん：03/12/21 22:48

>>316
俺もそう思うんだけどね。だから指向ってほどのことはないと。概念の変化というよりテクニックだという印象を強く受ける。
しかし本質うんぬん云う人達によるとそれ以上の概念があるような話方をする。巷のWEB上も何か難しく解説しているのが多い。
俺は簡単なことを簡単に自分の頭で消化して簡単に説明できる人（>>316もそうだと思うが）が頭がいい人であって、本質を捉えている人だと思う。
同じレベルで簡単にその捕らえ方が十分でないと指摘されれば納得もいくが、今のところそういうレスはひとつもない。

318 ：デフォルトの名無しさん：03/12/21 22:52

で、こういう事を書くと典型的に実装レベルでしか捕らえていないって一言レスが返ってくるのがパターンだが、それ以上のものがあるんならそれを簡潔に説明してもらいたい。

319 ：デフォルトの名無しさん：03/12/21 22:58

>>317
誤解を生むかも知れんが。

>>316みたいな捉え方は、間違いではない。
でもそれは、

オブジェクト指向のクラスとは、構造体に関数が宣言できるように
なったものだ。

って言ってるのと同じだと思う。
間違いでもないし、その部分に限定してればいいんだけど、
それが全てだって言っちゃうと、それは間違い。

320 ：デフォルトの名無しさん：03/12/21 22:58

アスペクトとは、それだけで自立している副プログラム (self-contained subprogram)であり、そこにはプログラム全体の特性 (global property)が記述されます。
各々のアプリケーションドメインには、大抵アスペクトのセットがあります。例えばそれらは、クライアント・サーバアプリケーション用の同期・分散アスペクトであったり、解析アプリケーション用の行列アスペクトであったりします。
複数のアスペクトは、アスペクトウィーバ (Aspect Weaver)と呼ばれる新たな種類のコンパイラによって自動的に結合され実行可能なプログラムの形(executable program image)になります。
「実行可能なプログラムの形」とは各々のアスペクトが一本の糸であるようなタペストリ(tapestry：つづれおり)のようなものです。
現在のプログラミングパラダイムがタペストリ全てを一つ一つ手で編むのに対し、アスペクト指向プログラミングはこのタペストリを自動的に編み込むものです。

321 ：デフォルトの名無しさん：03/12/21 22:59

>>318
簡潔な説明。

「へっ、しゃらくせぇ。
パソコンなんて、所詮電卓の親分みたいなもんじゃねえか。」

反論は無いか？

322 ：デフォルトの名無しさん：03/12/21 23:01

>>318
漏れもそれ以上のものがあるかどうか知りたいところなんだけど。。。
318 さんや 317 さん的には、アスペクト指向使ってみたいと思う？
オブジェクト指向だと使って当然みたいなところがあるけど。
概念を簡単に取られられる人だと、ただ単にモノを単位に分割して
行くと言うだけのことじゃない。実装的には構造体にメソッドを
つけたり(C で書いてもオブジェクト指向って話もあるし。。。）。
（オブジェクトの説明が下手ならスマソ）でも、オブジェクト指向は
みんな使いたがる。なんか理由があるのだけど、一言で言えること
なのかな？アスペクト指向についてもそれが言えるかどうかだけど、
とりあえず、そこまで概念を簡潔に捉えているなら、使いたいかどうか
を知りたい。

323 ：デフォルトの名無しさん：03/12/21 23:02

>>321 コピペつられんな。

324 ：322：03/12/21 23:04

317 さんや 316 さん的にはだった。欝だ詩嚢。

325 ：デフォルトの名無しさん：03/12/21 23:04

>>317
＞俺もそう思うんだけどね。だから指向ってほどのことはないと。概念の変化というよりテクニックだという印象を強く受ける。

結局、言葉の印象の話しかしていないね。

>>318
＞それ以上のものがあるんならそれを簡潔に説明してもらいたい。

「以上」って言葉は不適切だけど、技術に先立つ動機はあるだろう。
アスペクト指向って言うくらいだからアスペクトに着目している事くらい
分かりそうなもんだけど、分からなかった？

326 ：デフォルトの名無しさん：03/12/21 23:04

と言うのは云わば売り手側、研究者側のセールストークだとも捉えられる。
これを額面どおり「勉強して」感嘆する人間もいれば、実際どういうことなのか自分の頭で考える人間もいる。
上の例は非常にうまい例えだと思うが、実際は実装で語った逆インクルードでもうまい例えなのであって、価値は同等というのが自分の考え。
その上で、アスペクト指向ってのがどういうものか判断している。織物の例えがより本質的な捉え方ってのは何も優位な根拠などないよ。

327 ：デフォルトの名無しさん：03/12/21 23:14

>>325
だからさ、その「アスペクト指向」って言う位だからっていう部分がしばらく疑問視されているんだろうが。
言葉の印象の話をしているんだよ。

もちろんこういう議論がナンセンスだってのはそのとおりだよ。大方のここの人間がやってるように自分も暇つぶしに書き込んでるわけだからね。その点に関してとやかく言われる筋合いは無い。
あるテクニックを分析してそれをアスペクトだと分類し体系化するのはまあコンピュータサイエンスなんだろうね。
しかし、学者がそうするのも勝手だが、ユーザーから見れば逆インクルードくらいのもんだね、って事。
それ以上のものがあるのなら念のために知りたいが、無いでしょうということ。

328 ：デフォルトの名無しさん：03/12/21 23:17

>>321
簡潔な説明になってないよ。
質問を質問で返すような詭弁。

329 ：デフォルトの名無しさん：03/12/21 23:26

敢えて対立させてみると、オブジェクト指向が客体に着目したモジュール化の
考え方なのに対して、アスペクト指向は主体に着目したやり方ってことでしょ。

立ち位置が違えば対象（それが一枚岩だろうと小さなオブジェクトの集まり
だろうと）の見え方や記述の仕方が変わってくるっていう事を、素直に表現
したいという方向性なんじゃないの？

フックだとかプリコンパイラとかそういう話じゃないでしょ。

330 ：デフォルトの名無しさん：03/12/21 23:28

>>327
＞だからさ、その「アスペクト指向」って言う位だからっていう部分がしばらく疑問視されているんだろうが。
＞言葉の印象の話をしているんだよ。

いや、それなら何もいう事はないよ。あなたの個人的な心的事情にまでは誰も立ち入れないならね。

331 ：デフォルトの名無しさん：03/12/21 23:31

>>319
オブジェクト指向はそのパラダイム自体にちからがあると思える。
構造体に関数が定義できるとか、実装レベルで語るとそれこそ本質が見えにくい、その手法のメリットを感じにくくなると思う。
しかし自分が考えるにアスペクトてのはむしろ実装レベルの不便さってのが本質じゃないのかなと考える。アスペクトってのはむしろ後付で、そんな指向ってのはなくても十分成り立つのではないかとね。逆インクルードテクニックでもいいだろうと。

332 ：デフォルトの名無しさん：03/12/21 23:37

ML 関連スレで猛威を振るったアレ級のナニが居るというのはココですか？

333 ：デフォルトの名無しさん：03/12/21 23:50

オブジェクト指向は subtyping が本質なんじゃないの？
構造体に関数を定義できる、というだけで十分なら、
単に関数が first class であれば済んでしまう話なんだから、
関数型言語の方が素直、かつ一般性のある解だと思うんだけど。

>>322
デバッグコードなんかの例だと、確かに #ifdef で挿入するよりはいいかな、と思う。
で、そういう例がある以上、他にも便利なシーンがきっとあるんだと思うけど、
自分で具体的には、アスペクトを使ってこそ！という例は、なかなか思いつかないんだよね。

あと、多重継承と同じような難しい問題があると思うんだけど、それはやっぱり未解決なんでしょ？
「編み上げる」なんていうイメージで布教するからには、
やっぱり、その部分にキレイな解が欲しいなぁという気はする。

334 ：デフォルトの名無しさん：03/12/21 23:51

まあ別にいいよ。アスペクト指向はネーミング自体極論だし、解説もオーバーなのが多いから、まともに論じようとすればネガティブフィードバックがこれくらいあったほうがちょうどバランスがいいんだよ。
例出した>>320の説明なんかを見ても最後の一行でパラダイムの変化を説いている。
しかしちょっと注意深く見ると、タペストリとか編みこむとかいう「べつの言葉の使い方」をしているものの、実際言っている事は逆インクルードと同等である。
>>329のようにもう一歩踏み込んだ捉え方をしていればそれなりに説得力もあるが、パラダイムの変化があるってのは甚だ疑わしい。

335 ：デフォルトの名無しさん：03/12/22 00:18

例えばシステム開発での何かの文書で、「(1)当システム全体の×××の方針として
○○○のような実装方式を用いる。」とあったとする。
（×××の部分は例えばログ出力とかリクエストハンドリングとかイディオムとか）

(1)の文句が着目しているのがオブジェクトじゃないにも関わらず、なんとなく
凝集性らしきものが見えるので、独立した開発単位として切り出したい。
なおかつ、切り出した部分と切り出された部分の結合度はできるだけ低くしておき
たい。
そういう要求を満たそうとする方向性の事じゃないのかな。

でやはり、個々の×××について、OOのパターンやフレームワークでも十分とか、
逆にAspectJのような現状のアスペクト実装では不十分とか言うのは話が別だと思う。
まして逆インクルード？とかプリプロセッサの話とは違うんじゃない？

336 ：デフォルトの名無しさん：03/12/22 00:30

そろそろアスペクト指向が役に立ったって実際の例を説明してくれ。

337 ：デフォルトの名無しさん：03/12/22 00:32

漏れ的には今まで出てきた中では、335 さんの意見に近いかな。

338 ：デフォルトの名無しさん：03/12/22 00:36

漏れは335の説明は抽象的すぎてわからん。頭悪いのかな。

339 ：デフォルトの名無しさん：03/12/22 00:39

>>335
すばらしい。

340 ：デフォルトの名無しさん：03/12/22 00:44

クラス階層に対して横断的な「モジュール」を、
(interface で宣言して各クラスで implement するという形ではコードが散らばるので）
結合度を低く保てる形で実装したい、という話だと思う。
そこまでは、納得できる。

で、単純なものなら、逆インクルードみたいな仕組みで、プリプロセスで対応できるよね。
というのが、誰でもすぐに思いつくだろう解決方法。

それじゃ駄目だから、アスペクト思考という話になるんだろうけど、
肝心の「それじゃ駄目な例」ってのが、提示されてない気がする。

341 ：デフォルトの名無しさん：03/12/22 00:48

>>340

調べ方が甘い。AspectJ でもいじってみろ。

342 ：デフォルトの名無しさん：03/12/22 01:04

メリットを簡単に伝えられない概念というのは、たいした概念ではない。

343 ：デフォルトの名無しさん：03/12/22 01:11

>>340
＞クラス階層に対して横断的な「モジュール」を、

オブジェクト指向と関係なく、機能分割で関数に括りだした場合でも同じと思う。

＞で、単純なものなら、逆インクルードみたいな仕組みで、プリプロセスで対応できるよね。

ここまで実装の話なのに、

＞それじゃ駄目だから、アスペクト思考という話になるんだろうけど、

ここで、上位レベルの方針の話になってる。

344 ：デフォルトの名無しさん：03/12/22 01:25

オブジェクト指向で visitor パターンってあるでしょ。
visitor オブジェクトがオブジェクト群をたどっていって
引数の型でディスパッチして云々って奴。
ああいうのは visitor 部分をアスペクトにしてやると
アスペクト指向ですっきりかけるよね。

345 ：デフォルトの名無しさん：03/12/22 01:30

どうすっきり書けるの？それを見せてほしいわけで・・・

346 ：デフォルトの名無しさん：03/12/22 02:15

>>345
下のサイトにGofのパターンをjavaとaspectJで実装して比較したサンプルがあるよ。
まあVisitorパターンは難しいかも知れないけど。
一応、最低限のソース読解力とデザパタの知識がある前提で、どうぞ。

http://www.cs.ubc.ca/~jan/AODPs/

347 ：デフォルトの名無しさん：03/12/22 04:12

削除整理板にこのスレの削除依頼が出てるのを見て読んでみたのですが熱いスレですね。
削除依頼した人はいったい何を考えているんでしょうか。

良レスがたくさんありましたが、特に下記のレスが良かったです。
>>153-154 アスペクト指向のまとめ
>>316 実装からみたアスペクト指向
>>335 概念から見たアスペクト指向

私からもアスペクト指向に関する論点をいくつか追加させてください。

「AspectJは差分プログラミングにも使えます」
MixJuiceはメソッド単位の置き換えにより差分プログラミングを行い、
AspectJはjoin pointへのコード追加により横断的な関心を実現するとされています。
この思い込みがあるのでAspectJの用途としてロギングや認証など
複数のメソッドに追加され元の処理にさらに処理を追加する例しかでてこないのでしょう。
しかしAspectJは特定のメソッドの先頭に追加するコードの最後でreturnすることで
メソッドの元の処理を新しいコードによる処理に置き換える差分プログラミングに使えます。
AspectJはEclipse Technology Projectに採用されている勝ち組だし勉強するならAspectJですね。

「差分プログラミングはソフトウェア開発を複数のチームやツールが独立して行える画期的な手法です」
元のコードと差分コードを同じ人が書いているなら元のソースをリファクタリングすることで対応できます。
しかし別チームが作っているクラスライブラリの中の親クラスを固有の事情に合わせて修正したい場合、
元のソースをいじると元のクラスライブラリがバージョンアップするたびに修正作業を繰り返す羽目になります。
差分プログラミングなら新しいクラスライブラリと差分コードを再コンパイルするだけですみます。
差分プログラミングはアスペクト指向の活用方法の中で最も汎用的で将来性があると思います。

348 ：デフォルトの名無しさん：03/12/22 05:58

AspectJの宣伝はもういいよ
他の無いの？

349 ：デフォルトの名無しさん：03/12/22 13:18

Aspectってダイナミックリンクの拡張版だろ？

350 ：デフォルトの名無しさん：03/12/22 13:34

{AspectJ|JBoss|他のプロダクト名}って{フック|逆インクルード|他実装技術名}を使って実装してるんだろ？

351 ：デフォルトの名無しさん：03/12/22 14:21

WindowsってMS-DOSの拡張版だろ？

352 ：デフォルトの名無しさん：03/12/22 15:32

>>321 = >>351

353 ：デフォルトの名無しさん：03/12/22 15:46

>>314
そんなようなものです。

wdm ドライバは、バスドライバ (PCI とかの面倒見るﾔﾂ）、
特定のデバイスの面倒を見るいわゆる普通のデバイスドライバ、
上位層に対して機能を提供するファンクションドライバなんかから構成されるわけなんだけど、
これ、最終的にプラグアンドプレイで下から順に適当に構成されてAPに機能が提供されます。
（かなり大雑把で嘘もある説明）

いわばジョイントポイント（っていうの？）を両面に持った小モジュールの塊で、
PCI ドライバの上に乗った IEEE1394 ドライバの上に乗った IEEE1394 ファンクションドライバの上に
1394 バスドライバが乗って、その上にさらに　1394 接続されたデバイのドライバ階層が構築されたり。

大本のアスペクト指向の方では、こういう自動的に構築されるようなものの話はどうなってるんだろ。

354 ：デフォルトの名無しさん：03/12/23 02:37

>>353
その話のどの辺りがアスペクトなのかよく分からない。

355 ：デフォルトの名無しさん：03/12/23 03:45

アスペクト指向で全てが変わると思ってる。
オブジェクト指向でも全てが変わったわけではないのに。

356 ：1：03/12/23 09:10

>>347
そーかな。
同じ話をぐるんぐるん繰り返してるだけで、
全然本丸に攻め込まない、なんちゃってスレになっちまってるけど。

357 ：山崎渉：03/12/23 09:48

俺的には、アスペクト指向の歴史的位置付けは、下記にあると考える。
まだまだ発展途上だが、磨けば光る原石だと思う。

1. 「プリプロセス」「ポストプロセス」への、オブジェクト指向意味論の付与

　「プリプロセス」「ポストプロセス」は、
　Lisp, C, UNIX等で存分に活用されてきた。
　　例：・CommonLispのマクロ機能
　　　　・Cのプリプロセッサ
　　　　・UNIXのsed, diff, patch類
　しかし、オブジェクト指向言語では意味論や扱いが定まらず、
　使用を避けるべきだと考えられてきた。
　アスペクト指向は、上記に一定の解を与え、積極的な使用方法を提案した。

358 ：山崎渉：03/12/23 09:49

2. 型継承と実装継承の分離

　これまでのオブジェクト指向は、実装継承を型継承の下位機能と見なし、
　「実装継承と型継承を一体化」する事で、概念の単純化を図ってきた。
　例えば、
　　　　・型継承と同時に、実装継承　　　　・・・クラス
　　　　・型継承と同時に、部分的実装継承・・・抽象クラス
　　　　・型継承のみ　　　　　　　　　　　　　　・・・インターフェース
　というのはあっても、
　　　　・実装継承のみ
　という選択肢がなかった。

　アスペクト指向は、実装継承のみという選択肢を与える事で、
　本来別々のものである、実装継承と型継承を明確に分離して扱う事を、
　可能にした。

3. 「実装の単継承vs多重継承」　問題の解決

　多重継承を、「実装継承と型継承を一体」という視点で実現する場合、
　「選択的な実装多重継承」が必要になる。
　しかし、型のセマンティクスと、実装のセマンティクスは異なるため、
　両者を同じ視点で扱うと、混乱が生じ易かった。

　上記の混乱の回避策は、「実装多重継承の排除」だった。
　実装単継承の元で、実装多重継承の提供機能を実現するには、
　　　　・型の多重継承　　　　　　　　　　　　　　・・・インターフェース
　　　　・メソッド実装の委譲
　を使用する。
　但し、メソッド実装の委譲は、実装レベルのコードで実現する必要があった。

　アスペクト指向は、上記「メソッド実装の委譲」を、
　静的に(宣言的に)取り扱う事を、可能にした。

359 ：山崎渉：03/12/23 09:55

補足：アスペクト指向出現の背景には、
　　　　近年、統合開発環境/ツール類の技術が飛躍的に進歩し、
　　　　上記項目2.、項目3. を事実上提供するツールが現れつつある、
　　　　事も関係していると思う。

360 ：デフォルトの名無しさん：03/12/23 11:03

>山崎渉

言ってる事はまともな気がするが、
そのコテハンにした意図が気になる。

361 ：デフォルトの名無しさん：03/12/23 13:24

AOPは便利そうな気はしている。
AspectJを使おうと調べてみたら、
eclipseではまだ確実に動いていないみたいだから、
今のところ様子見。

いまいちわからないのはAOPの位置付け。
つまり、
1. どんな問題を解決するために
2. どのような方法を提案しているのか？
3. そして、その提案にはどんな欠点があるのか？
この３つを誰かピンポイントで指摘できる人はいる？
ようするに従来法のとの比較なんだけどね。

362 ：デフォルトの名無しさん：03/12/23 13:29

>>358
>しかし、オブジェクト指向言語では意味論や扱いが定まらず、
>使用を避けるべきだと考えられてきた。
C言語のプリプロセッサがJavaにくっついてたとしても
俺はデバッグ、ロギング以外では使わないと思う。
逆にあれば使うのだから、それがAOPという事かな？
C言語のプリプロセッサには、多くの負の面がある反面
いいところもある。
ただ、ソースコードを事前に書き換えるという方法は
どうもいただけない。
言語機能として組み込めないものだろうか？
という事をAOPで考えてるのかな・・・

363 ：デフォルトの名無しさん：03/12/23 13:33

1. ロギングの実装を一箇所で管理したくても、現実には出来ないという問題。
　メソッド全部にロギング処理書くのー。うわー。だりー。超だりー。
2. いわゆるメソッドフックを宣言的に行う方法を提案している。
　え？一箇所に書けばいいの？うわー。すげー。横断的ー。
3. マイナー
　AOP？なにそれ？ AOLって社名変えたの？

364 ：デフォルトの名無しさん：03/12/23 13:39

>・実装継承のみ
これは要するにコピペの事かな？

書き込みの内容が理解できてないので
的を外してたら無視して。

ソフトウェアの生産性を上げるというのは、
再利用性を高める事であって
タイピングの量を減らす事ではないと思うんだよね。

実装多重継承がJavaにないのは
根本的に違うオブジェクトを
ポリモーフィズム（動的バインド）して使うならばインターフェース。
差分プログラミング見たいな事をするなら、
継承、みたいな事になってると思う。

多重継承が必要な時はいつなんだろう？
という事を考えてみると、いまいち思いつかないんだよね。
つまり、多重継承をする事で再利用性の高いクラスを定義できるのか？
ということ。
冗長なコーディングのよりも、再利用性を重視しているのは
Javaとperlの比較をすれば明らかな事だとは思うし。

365 ：デフォルトの名無しさん：03/12/23 13:41

>>363
つまり、AOPっていうのは
ロギング（のような処理）のためのソリューションの一つで
メソッドフックを宣言的に行う事で、
一箇所にすべての処理を記述できる。
それによる弊害はないという事？

366 ：デフォルトの名無しさん：03/12/23 13:43

素人発言スマソ
AOPでロギングする事は
log4jより優れているという理解でいいの？

367 ：デフォルトの名無しさん：03/12/23 13:45

コピペせずにコピペできるのがプリプロセッサ。
再利用性で考えるならオブジェクト指向といい勝負だよね。
一度書けば、全体に波及させるための作業コストが「無い」んだから。

だからたとえJavaであっても、ロギングとかプロファイリングとか、
実装横断って概念は有用だし、効果的に使えると思うよ。

それ以外のことは、もちろんオブジェクト指向で解決するべきだが。

368 ：デフォルトの名無しさん：03/12/23 13:47

アスペクト指向：
SXGAのモニタでXGAの画面を表示すること。また、そのさま。

369 ：デフォルトの名無しさん：03/12/23 13:48

AspectJインストールのページ
http://www.02.246.ne.jp/~torutk/aspectj/

370 ：デフォルトの名無しさん：03/12/23 13:49

>>366
// 先のロギングの例をアスペクト(AspectJ)で書くと…
aspect Logging {
　/* execution() 内部に書かれているメソッドの実行に対して動作
　　従来は，各メソッドの先頭にこのコードを書かないといけなかったが
　　アスペクトを使うと，オブジェクト側のコードには何も書かなくてよい．*/
　around: execution(void Foo.foo()) ||
　　　execution(void Bar.doSomething()) ||
　　　execution(static void Baz.doSomething())) {
　　// この実行時点(join point)で，呼び出されているメソッドを記録
　　// thisJoinPoint はどのメソッド呼び出しに相当するかの情報を持っている
　　logger.log("start - " + thisJoinPoint.getSignature());
　　// 呼び出されているメソッドの実行
　　proceed();
　　logger.log("end - " + thisJoinPoint.getSignature());
　}
}
引用先 ttp://sel.ics.es.osaka-u.ac.jp/research/aspect/index.html.ja

371 ：デフォルトの名無しさん：03/12/23 13:54

>>365
アスペクト指向の横断的なコードは別のファイルに書かれるから、
オブジェクト指向のコードと完全に分離できる。
TestUnitによるテストケースを継承したクラスを想像してみて。

アスペクト指向を使えば、元のクラスからロギング処理のコードを
削除したり、そのために staic final なフラグを使ってコンパイル時の
最適化を期待したり……

そうやっていちいち対象のクラスに手を加える必要は、全くなくなる。

372 ：デフォルトの名無しさん：03/12/23 13:58

>>370
around: execution(void Foo.foo()) ||
　　　execution(void Bar.doSomething()) ||
　　　execution(static void Baz.doSomething())) {
この３つのメソッドに関しては
ログをとるという事になるんですか？
つまり、ログをとりたいメソッドをここに列挙すればいいと。

確かに、それは便利ですね。
プリプロセッサ以上のものですね。

373 ：デフォルトの名無しさん：03/12/23 14:04

この機能だけでも使う価値はあると思うなぁ。
導入しようかな。
いいテキストがあればなぁ

374 ：デフォルトの名無しさん：03/12/23 14:05

AspectJは現状ではアスペクトのコードを元コードに埋め込むようになってるけど
アスペクトを動的に扱えるようにならないとまだまだいまいちという感じがぬぐえない。

375 ：デフォルトの名無しさん：03/12/23 15:13

>>361
1) crosscutting concerns
2) weaving
3) フックと思われてる

376 ：デフォルトの名無しさん：03/12/23 17:15

>>364
OOP ではメソッド（そのインタフェイス・シグネチャ)が再利用の最小単位だけど、
それ以外の再利用の仕組み（generics なり macro なり aspect なり)を導入することで、
解決できることもあるよねってことかと。

377 ：デフォルトの名無しさん：03/12/23 17:34

>>364
＞>・実装継承のみ
＞これは要するにコピペの事かな？

単なるコピペじゃなく少なくともコピペ元に何らかのモジュール性が無いと、
継承と言わないんじゃないかな。

378 ：デフォルトの名無しさん：03/12/23 21:07

>>360
某有名専門家の方の文字りでつ。オリジナルの人ゴメソ

379 ：デフォルトの名無しさん：03/12/24 03:06

議論についていけないDQNが逆ギレしたぞ
http://qb2.2ch.net/test/read.cgi/saku/1027372992/318

380 ：デフォルトの名無しさん：03/12/24 03:09

>>356 =1
>本丸に攻め込まない
じゃ、おめーが本丸に攻め込んだネタを語れやｗ
重複で刷れ立てたうえ、盛り上げてもらっといてエラそーにしてんな池沼病人が。
リアルでのイカれっぷりが目に浮かぶぜ。

381 ：202：03/12/24 03:43

>>375
> 2) weaving
つまり、AOとはweabingって事だよな？
（1) だけならただの問題意識であって技術ではない）
しかし、そんなもの、一般に可能なのか？
偉そうに「指向」なんて名乗っておいて、
やっぱりログとか認証くらいじゃないのか？

>3) フックと思われてる
「オブジェクトを構造体+関数として見るような見方で
　AOを捉える馬鹿が多い」という認識なんだろうが、違うな。
オブジェクト指向は、どう実装されるかなど埋もれてしまうほど、
その概念によってまったく新しい沃野をわれわれに見せ付けた。
AOは、
1）概念自体が、実装が埋もれてしまうほど新しくも強力でもない。
2）OOみたいな沃野を見せてくれていない

とは言え、恥ずかしい名前はおいといて、一応は広まっていくんだろうね。
>>335 のようなニッチを埋めるものとして。

382 ：202：03/12/24 03:48

訂正（typoは放置）
×　>>335 のようなニッチを埋めるものとして。
○　>>335 のようなニッチの一部を埋めるものとして。代替技術が出てこなければ。

383 ：１：03/12/24 03:58

>>379-380
スレ汚し良くないぞ。
自分でレス削除しとけよ。

オリジナルスレは、サーバ移転でdat落ち、
なんでこっちのスレ残したのか、意図は不明。

>>1 としては、有効な議論を100番台までやったつもりだが。
最近雑談ぽい無内容なレスで、スレが空転してるみたいなんで、
>>361-365に、要約を書いておいた。

ぐだぐだ抜かしてる暇があったら、
ちゃんと簡潔かつ有効な議論な議論をしろ。
さもなくば、削除だ。反論は受け付けない。さっさと議論しろ。

以上。

384 ：１ (レス番訂正)：03/12/24 04:01

>>379-380
スレ汚し良くないぞ。
自分でレス削除しとけよ。

オリジナルスレは、サーバ移転でdat落ち、
なんでこっちのスレ残したのか、意図は不明。

>>1 としては、有効な議論を100番台までやったつもりだが。
最近雑談ぽい無内容なレスで、スレが空転してるみたいなんで、
>>356-359に、要約を書いておいた。

ぐだぐだ抜かしてる暇があったら、
ちゃんと簡潔かつ有効な議論な議論をしろ。
さもなくば、削除だ。反論は受け付けない。
さっさと議論しろ。

以上。

385 ：１：03/12/24 04:11

319: 318 03/12/24 04:09
>>319
上記スレを立てた者です。
まだまだ未発達で、成育途上の上記分野について、
いい加減な議論をしつこく展開する粘着が発生しており、
２ちゃんのみならず、世の中の学術発展のために極めて有害なスレ
と化したので、削除を是非お願いします。

現在粘着している人物は、過去にもオブジェクト指向スレ他で
デタラメな議論を延々と書き続け、２ちゃんにおける該当分野の
議論を停滞させ、ひいてはプログラム技術板の知的レベルを低下させた人物のようです。
２ちゃんを、素人がデタラメをする便所の落書きではなく、
匿名で有効な議論ができる場にするためにも、削除をお願いいたします。

386 ：１：03/12/24 04:12

■■■■終了■■■■

以降の議論は、きちんとした専門家のいる Yahoo!egroupで、
どうぞ

387 ：１：03/12/24 04:15

■■■■終了■■■■

以降の議論は、きちんとした専門家のいる Yahoo!egroupで、
どうぞ

388 ：デフォルトの名無しさん：03/12/24 04:31

結局１の自慰スレだったな
とりあえずスレストしてもらえば？

389 ：デフォルトの名無しさん：03/12/24 04:44

さっさと市ね。
おまえは、一生引きこもっておなーにでもしてろ

390 ：デフォルトの名無しさん：03/12/24 04:46

おまえさぁ、複雑系だ脳科学だって言って、
痛い過疎板立てまくってる厨房だろ。
おまえみたいな椰子がいるから、世の２ちゃん離れが進むんだよ。

いい加減、消えたらどうよ

391 ：デフォルトの名無しさん：03/12/24 04:48

>>1
じゃ、今居る粘着が消滅したら、どっかの板のどっかのスレで議論再開って事で。

392 ：デフォルトの名無しさん：03/12/24 04:58

> 最近雑談ぽい無内容なレスで、スレが空転してるみたいなんで、
それは全部おまえのレスだろうが。エライオモシロイ>>1ダナ、HaHaHa

> >>356-359に、要約を書いておいた。
SoCと別文脈で語るのもおもしろいが、
> >>1 としては、有効な議論を100番台までやったつもりだが。
>>1-200 うーん、有効な議論だねぇ、HaHaHa。

> ちゃんと簡潔かつ有効な議論な議論をしろ。
↓こういうのですか？ちょっと俺らには難しいよ。
消防の頃なら出来たかもしれんけど。

15 ：→ ：02/09/03 22:08
AOPスレ、伸びるの遅いから、興味の速度についてかないんだ‐
19 ：→ ：02/09/03 22:21
ｶﾜｲｿｳな煽り屋さん？
158 ：名無しさん＠Linuxザウルス：03/11/19 01:48
>>1=>>47=>>155ですが、何か？

AspectJの親方に、座席まで出張ってもらって、
「ﾅﾆｶ質問､ｱｰﾘﾏｾﾝｶ? ﾅﾆｶ質問? ｼｰﾂﾓﾝ?」
(Do you have any questions ? Any Questions ? Any Questions ?)
って親切に聞かれましたが、何か？
＃本当に、とても親切で素晴らしい方ですた

393 ：デフォルトの名無しさん：03/12/24 05:03

粘着厨房の基地外議論にお付き合いするつもりはないんで、
■■■■終了■■■■

以降の議論は、きちんとした専門家のいる Yahoo!egroupで、
どうぞ

394 ：347：03/12/24 05:12

>>356
　　このスレはアスペクト指向を知らない人への布教に大いに役立っていると思いますよ。
　　プログラム板は情報科学研究のための板ではなくプログラムを作る人のための板です。

>>381
AOPの位置付けはこのスレだけでも３種類出ています。
weaving(織り込み)だけがアスペクト指向と考えるのは正しくありません。

１．横断的な関心を実現するための織り込み。ログや認証が典型例。
　　joinpointへのコード追加を１個所で記述することにより織り込みを効率的に実現します。
　　AspectJの売り文句ですが、これがニッチであるというのには同意します。

２．複数チームやツールが独立してコーディングを行う差分プログラミング。
　　元のソースファイルを一切いじらずに異なる機能を持つソフトウェアを作り出せます。
　　MixJuiceの売り文句ですし>>347でAspectJでも可能だと説明しています。
　　指向というのとは違うと思うのですが、広い範囲で有用な手法であると考えます。

３．オブジェクト指向を補完する実装のみ継承。>>346が具体例。>>357-359がまとめ。
　　深い継承や多重継承の乱用による困難を集約と委譲が救ったように、
　　実装のみ継承はオブジェクト指向を大きく改善する可能性があります。
　　この位置付けなら「指向」の名に恥じないと思います。
　　この視点でのAOPは未発達で学問としては面白くても実践は難しいですが
　　>>346のサンプルを理解すればGOFパターンについて実践できます。

上記以外の位置付けをご存知の方はこのスレを読む人のために簡単なまとめをお願いします。
スレの価値は良レスの質と量で決まるのであって駄レスは関係ありません。

395 ：デフォルトの名無しさん：03/12/24 09:15

>>381
＞偉そうに「指向」なんて名乗っておいて、

>>253

＞やっぱりログとか認証くらいじゃないのか？
＞
＞>3) フックと思われてる
＞「オブジェクトを構造体+関数として見るような見方で

この辺りの誤解は、自分でいろいろ検索でもしてみてよ。
ま大変だろうけど、がんばって。

396 ：デフォルトの名無しさん：03/12/24 09:29

これからはナラヤマブ指向。

397 ：381：03/12/24 12:28

いろいろ関連研究がある中で、PARCがとなえたもの（>>394 の1.）を
他と区別してAOと呼ぶという認識だった。それはニッチのさらに一部を埋めるだけと。
>>395
単なる引用ミスならいいけど、でなければレスを読み違ってるよ。
いずれにせよ2．3．はほとんど意識を払ってなかったのでこんど見てみよ。

398 ：デフォルトの名無しさん：03/12/24 13:15

>>374
AspectJはコンパイル前にひと手間増えるコンパイラベースの実装だけど、
最近はDynamic AOP(Proxy)とか言ってバイトコードに対してアスペクトを
動的に適用するのがトレンドだよ。AspectWerkzとか。

ただ、Dynamic AOPだと静的な型チェックができず、利用時にキャストが
必要になるという欠点もある。

399 ：デフォルトの名無しさん：03/12/24 13:47

AspectJってまだバグがあるわけ？

400 ：デフォルトの名無しさん：03/12/24 20:23

>>397
引用ミスじゃないよ。違ってるところを指摘してるだけ。

＞やっぱりログとか認証くらいじゃないのか？

これはもう説明いらないでしょうな。

＞>3) フックと思われてる
＞「オブジェクトを構造体+関数として見るような見方で
＞　AOを捉える馬鹿が多い」という認識なんだろうが、違うな。

やっぱフックって思ってるんだね。それを違うって言ってるんだけど。
例えば、>>346のVisitorパターンなんかよくあるアスペクトの活用例だけど、
全然フックなんか使って無いよ。

401 ：デフォルトの名無しさん：03/12/24 20:30

>>399
むしろAspectJで作ったらバグだらけ

402 ：デフォルトの名無しさん：03/12/24 22:05

なんかjavadeveloper誌でアスペクト指向についての連載が始まったみたいね。

ttp://www.javadeveloper.jp/

内容見た人の感想希望。

>>391
具体的にどんなバグがあるの？

403 ：デフォルトの名無しさん：03/12/25 20:15

　　　　　　　　ｒ､_ .⊆ヽ｀二ミヽ､
　　　　　　(｀_ー-=r‐ｧﾞ=,三ﾐ､｀､ } ＿
　　　　　,⊆三彡' ／ ,r＝==ﾞﾞ'---‐¨＝丶
　　　　　,ゞ＝,.= ‐'　／　　　　　　　.:i
　　　　し￢_r＝彳、　　　　　　　　　.:::i
　　　　　　　　　　　}c｀'ｰ--- ───---:::'{
　　　　　　　　　,. ￢､＿Ｏ　＿__Ｏ__...::::::_2!、
　　　　　　　　／　　　　　..￣..　　....:::::￣:: .:::::ヽ
　　　　　／　　　　 ,.-t_ｒ‐ﾃ=:.‐ｬｒﾃ‐x｀.::::::::ヽ
　　　　　／　　　　　,. イ　｀こﾆ ´ﾞ　Ｆﾆ´｢[｀ヽ､:::::ヽ、
　　 ,　'" 　　,.r‐'i"｢:..._ﾞゝ‐-ｰ- ､r 　ﾚ;z亠ｯ｀'ｰﾞ=ﾐ- '
　　,ｆ=‐:-,,-＜. i::. l:. l:_,≦-｀　　　｀ -'" ´_=ミｰ"_,.:ヽ
　/.:. 　　｀:. 　ﾞヾ. l:..ヽ､彡,´ 　　　　　　　､ミﾐﾞｰ"⌒:ヽ
_/.:._ 　　　　:. 　　｀'ｰ-､〃;" 　　,,　　,、　､ヾﾂ　　　...;;ﾍ
⌒ﾞー:...._　　　｀;,,_　　　''≠彡ｯ彡;,ｿ,,ﾘ､,ﾐ?_ﾞ丶-‐....::::;;〉

逝こう………、ここもじき腐海に沈む………………

404 ：397：03/12/26 01:42

>>400
> やっぱフックって思ってるんだね。
日本語読める？そんなに難解なレスだったか？まあいいけど。

>>346 みたけど、これが何を解決してるのかよくわからん。
RubyやJavaScriptとちがうの？純然たるOO言語だけど？
型チェックできるのがいいわけ？

405 ：404 /= 2：03/12/26 03:53

と書いたけど、宣言的に書けるのはちょっとｲｲかもね。
ただ、「指向」っていうほど新しい世界観を提供してるかっつうと、アレだね。
>>346 だって、外から言える後から言えるってだけで、
モデリングとしての正しさとか安定性とか見えないし。

406 ：デフォルトの名無しさん：03/12/28 08:51

>>403
荒しウザイ。さっさと消えろ。お前の頭が腐ってるだけだろ

407 ：デフォルトの名無しさん：03/12/31 14:21

>>353
ドライバ階層というのは上位の層が低レベルで凡用な機能を提供し、下位の階層は
上位の階層の機能を利用する事でアプリが必要としている特殊な機能を実現する
というモデルを指してるんでしょうか？アスペクト指向が注目してるのはそのよう
な一般的な機能とそれを利用したアプリ依存の機能との関係ではなく、全く別個の
機能（よく例にあげられるログ、認証、永続性等）間の関係に注目してると思いま
すけどね。

408 ：デフォルトの名無しさん：04/01/02 12:26

　┌───────────────────┐
　│┌─────────────────┐│
　｜│　　　　　　　　　　　　　　　　　　　　　　｜｜
　｜｜　　　　　　　　　　　　　　　　　　　　　　｜｜
　｜｜　　　 ,.．-──- ､　　　　　　　　　　　　｜｜
　｜｜　　／. : : : : : : : : : ＼.　　　　　　　　　　｜｜
　｜｜　/.: : : : : : : : : : : : : : ヽ　　　　　　　　　　　｜｜
　｜｜,!::: : : :,-…-…-ミ: : : : :',　　∩＿＿＿∩.　｜｜
　｜｜{:: : : : :i '⌒'　 '⌒' i: : : : :}　/ 　　　　　ヽ.　｜｜
　｜｜{.:: : : : |　ｪｪ　ｪｪ　|: : : : :}/　 ● 　　 ● ヽ. ｜｜
　｜｜ { : : : :|　　　,.、　 |:: : : :;!;　　　(_●_)　　ミ｜｜
　｜｜　ヾ: : :i　r‐-ﾆ-┐ | : : :ﾉ:彡　　 |∪| 　､　｜｜
　｜｜　　ゞイ! ヽ二ﾞノｲゞ‐′/　＿＿ヽノ　　/´>｜｜
　｜│　　／＼` ｰ一'´丿＼ (＿＿＿）　　　 |　(.｜｜
　｜｜　／＼　＼___／　　　/｀　|　　　　　　　| 　｜｜
　｜└─────────────────┘│
　｜　　　　　　　　　　　　　　　　　　　　　　　　｜
　｜　　Jan 01, 2004　　　　　　　　　　　　　　　｜
　｜　　　　　　　　　　　　　　　　　　　　　　　　｜
　｜　　　　　　　　　　　親　友　と　　　　　　　｜
　｜　　　　　　　　　　　　　　　　　　　　　　　　｜
　｜　　　　　　　　　　　　　　　　冬の表にて　｜
　｜　　　　　　　　　　　　　　　　　　　　　　　　｜
　｜　　　　　　　　　　　　　　　　　　　　　　　　｜
　└───────────────────┘

409 ：デフォルトの名無しさん：04/01/05 14:14

>>407
なるほど。でもドライバモデルやプロトコルスタックのように well defined な
joint point を沢山持ったアーキテクツじゃないと、面白い応用が無いような。。。

410 ：デフォルトの名無しさん：04/01/07 20:56

>>402
今日読んだ。
なかなかいい記事だと思う。おすすめ。

411 ：デフォルトの名無しさん：04/01/08 00:12

>>409
それがつまり、>>394 の
> ニッチである
ってことじゃないの？

412 ：デフォルトの名無しさん：04/01/08 00:16

というか、
>>381 の
> しかし、そんなもの、一般に可能なのか？
とか、
>>397 の
> ニッチのさらに一部を埋めるだけ
ということかと。

413 ：デフォルトの名無しさん：04/01/12 21:52

>>402
つーか、またログ佳代！！！

414 ：デフォルトの名無しさん：04/01/12 22:04

>>402
前半はﾄﾞｷｭｿPGには読ませたい記事だが、
ﾄﾞｷｭｿPGはそもそもこんな記事よまねー。

415 ：デフォルトの名無しさん：04/01/12 22:05

413もっと具体的な例は？
ＥＪＢとか連載しろよ
アスペクトの

416 ：デフォルトの名無しさん：04/01/14 20:45

>>409
新しい理論とはそういう物じゃないですか？コードが大規模になってゆくにつれ、
それを楽にできる新しい技法が出現するという事だと思いますよ。

417 ：デフォルトの名無しさん：04/01/15 01:31

>>416
なにか根本的に読み間違ってると思われ。

418 ：デフォルトの名無しさん：04/01/15 09:02

意味不明なレスを返すのはいつも１なのでスルーしる・・

419 ：デフォルトの名無しさん：04/01/15 10:46

>>413
まぁ、オブジェクト指向の「犬」「猫」「哺乳類」と同じようなもんじゃない？

420 ：デフォルトの名無しさん：04/01/15 10:51

> 問題は「Logger.log(・・・)をだれが、いつ、どこで使うのか」に関する情報がプログラム中に散らばることです。

という一文に深い意味が隠されていると見た。

421 ：デフォルトの名無しさん：04/01/15 19:44

>>417
そうなのかな…。

漏れ的には
409：アスペクト指向って応用例がかなり限定されるんじゃ？
411：>>394が既にニッチだと言ってんじゃん。
412：つーか>>381が言うようにWeavingによってコードを適宜埋め込むというやり方
自体、本当にうまくいくの？いったとしても>>397のいうようにごく一部でのみしか
役に立たないんじゃ？

と読んで、

実際の所、既存の理論や言語で大抵のコードはうまく記述できるでしょ。でも
一部でそれではコードの記述がやりにくい場面（ログとか）がある。で、それ
をうまく記述するための新しい理論（アスペクト指向）が現れるという事じゃ？
新しい理論はそのごく一部をうまくやるためのものだからニッチな物でしょ？

という事を言いたかったんだけど…。

422 ：デフォルトの名無しさん：04/01/15 20:13

>>421
総合すると、
　新しい理論というものは、ニッチの一部を埋めてくれるだけでしかない。
となりますが？

423 ：デフォルトの名無しさん：04/01/15 20:46

物理学の例を考えると、
新しい理論から新しい応用が現れるケースもありそうだけど。
・相対性理論 ⇒ 核エネルギーの利用、etc
・量子論 ⇒ 半導体レーザーその他物性関係、etc
でもニュートン力学で十分だった分野は、依然としてニュートン力学で十分。
核爆弾のようなキラーアプリケーションが出てくれば、「ニッチ」とは言われなくなるんだろうね。

424 ：デフォルトの名無しさん：04/01/15 20:51

しかしAOの場合、　ログ　がキラーアプリらしいので…。
しかも、>>381 の通り、相対論のような一般性はないのでやはりニッチのままでないかと。

425 ：デフォルトの名無しさん：04/01/15 20:53

しかも実コード全く示せない状況だしね（苦笑

426 ：デフォルトの名無しさん：04/01/15 20:54

Ｃでアスペクトできなきゃイヤン

427 ：デフォルトの名無しさん：04/01/16 10:21

>>425
いみふめー

428 ：デフォルトの名無しさん：04/01/16 11:23

>>424
データベースアクセスを伴うメソッドの前後にトランザクション制御を
挟んだりできる、ってのは嬉しい人多いと思うけどな。

429 ：デフォルトの名無しさん：04/01/16 16:48

>>428
メソッドわかってるなら継承でトランザクションを追加すればいいんじゃない？
なんでそこでわざわざアスペクト使いたがるのか理由がわからんのですが。

430 ：デフォルトの名無しさん：04/01/16 21:44

>>429
データベースやトランザクションマネージャの実装に依存するコードを
ビジネスロジックに埋めるわけにはいかないから。
それに、データベースアクセスを行うすべてのクラスを、単一のクラスを
継承して作るわけにもいかないでしょ。

継承とかインターフェースに制限されることなく共通の振る舞いを
付加できるのがアスペクト指向のメリットなんだし。

431 ：デフォルトの名無しさん：04/01/16 22:27

MIX-INで。。。。

432 ：デフォルトの名無しさん：04/01/17 17:32

>>418
誤爆で喧嘩売ってるのか？さいてー

433 ：1：04/01/17 17:37

>>428-430
某研究者の人は、
Aspect Oriented Software Development の目的は
２ちゃねらーが例に上げがちな ORBやトランザクション基盤の分離などにあるのではなく、
例えばﾃﾞｻﾞﾊﾟﾀの要素間に働く力の分離、ﾃﾞｻﾞﾊﾟﾀ体系の再構築 (間違ってたらスマソ)
てな事言ってたね。

ちゃねらーの漏れ的には、「J2EEﾌﾟﾗｯﾄﾌｫｰﾑをAspect で再構築！」ってなｶｯｸｲｲ目標上げるのも
悪くないと思うんだけど。やっぱ現世への影響大き過ぎる上に、実現しえない彼岸の目標上げるのは、
マズイのかな、研究者的には。

434 ：428：04/01/17 19:38

>>433
俺の場合、AOPによるトランザクション制御の分離は普通に仕事で使ってるよ。
アスペクト指向だけで何でもやろうとするのは当然無謀だけど、
AOPってオブジェクト指向なんかと組み合わせるのが前提だから
スコープを絞れば夢物語でもなんでもない。

435 ：デフォルトの名無しさん：04/01/17 23:47

>>434
環境と完成度の説明プリーズ。

まさかJ2EEコンテナ環境ではないだろうな

436 ：428：04/01/19 06:12

>>435

J2EE環境。
普段はSpring FrameworkにAOP Allianceの実装が組み込まれてるんで
それを使ってます。
J2EEじゃない場合はNanning AspectsとかAspectwerkzも使う。

完成度は、別にAOPフレームワーク自体を作ってるわけじゃないので
普通に使えてます、という感じ。

437 ：デフォルトの名無しさん：04/01/19 23:28

>>433
> ２ちゃねらーが例に上げがちな ORBやトランザクション基盤の分離などにあるのではなく、
> 例えばﾃﾞｻﾞﾊﾟﾀの要素間に働く力の分離、ﾃﾞｻﾞﾊﾟﾀ体系の再構築 (間違ってたらスマソ)
両者は何が違うの？
つか、AOSDコミュニティ外では前者ばっかり宣伝されてるし。>>402

つか、>>404-405 は？

438 ：デフォルトの名無しさん：04/01/19 23:30

それは、トランザクション制御をAspectとして分離してるわけではなく、
単にトランザクション環境で、トランザクション制御呼び出しを分離してるだけでわ・・・。

439 ：デフォルトの名無しさん：04/01/19 23:39

>>437
いみふめい

440 ：１：04/01/19 23:42

しかし、最近キモイレスが多いな・・・。。。

441 ：デフォルトの名無しさん：04/01/20 00:04

オレはリスペクト指向プログラミングで他人のプログラムからリスペクトされまくりです

ゲッツ

442 ：Delﾌｻｷﾞｺ ◆A6VzDeLphI ：04/01/20 00:07

|
|,,∧ 　　聞いてよい？
|Дﾟ彡　
⊂ﾐ
| ,;ﾞ
|´

443 ：Delﾌｻｷﾞｺ ◆A6VzDeLphI ：04/01/20 00:13

|
| 　ｻｯ
|）彡
|
| ﾔｯﾊﾟｺﾜｿｳﾅﾉﾃﾞﾔﾒﾀ
|

444 ：428：04/01/20 19:20

>>438
トランザクションの開始・終了および例外発生時のロールバックが
１つのInterceptorとして定義されていて、あとはビジネスロジックの
メソッド単位でそれを適用してるんだけど、これじゃあ
「トランザクション制御をアスペクトとして分離している」とは
言えないのか。
そうか…。

445 ：デフォルトの名無しさん：04/01/21 01:07

本来行いたいこと（この話ではデータアクセス）から
処理上必要なこと（トランザクション制御（呼び出し））を分離させているっていうことでは
>>428の話で問題ないと思うのだけど・・・

アスペクトとして分離してしまえば、
「トランザクション制御呼び出し」だろうが
「トランザクション制御」そのものだろうが
本来行いたいことには関係なくなるし。

446 ：デフォルトの名無しさん：04/02/01 15:48

aspectjで、anonymous inner classを直で指定するのはどうすんのかな。
Test$1もだめだし、Test.1ももちろんだめ。
Class.forName("Test$1")はできるので、指定できてもいいはずなんだけど。

447 ：デフォルトの名無しさん：04/02/02 01:34

仕様上「名前がない」ものを名前で指定できるわけがない。
Class.forName("Test$1") ができるのとは関係ない。

名前をつけろ。

448 ：446：04/02/02 02:04

$1ってのはSunのjavacがそうしてるだけで、仕様で決まってるんじゃないのかな。
withincodeとMouseListener+とかって感じかなあ。

あるメソッドで2つMouseListenerを実装したanonymous classが作られてて、
片方だけに影響を及ぼしたい場合はどうだろ。
targetで区別かな。

449 ：デフォルトの名無しさん：04/02/02 02:32

だーかーらー

名前をつけろ。

450 ：446：04/02/02 03:01

名前付けたらanonymousじゃなくなるじゃん。
人の話聞いてんの？まったく。

451 ：デフォルトの名無しさん：04/02/02 23:20

お前こそ人の話聞いてるのか？
名前がないと無理だから名前をつけろって言ってるんだよ。

452 ：446：04/02/02 23:26

知らないなら無理して答えなくていいよ。
知ったかはかっこわるいよ。命令口調だとなおさら。

453 ：446：04/02/03 00:22

public aspect TestAspect{
　after():
　　execution(Test.*1.new(..))
　　&& if(thisJoinPoint.getTarget().getClass().getName().equals("Test$1"))
　{
　　System.out.println(
　　　thisJoinPoint.getTarget().getClass().getName() + " created");
　}
}

こんなとこか。
まあ、実用上これで問題無いかな。

↓447=449=451の言い訳 or 負け惜しみ or 責任転嫁 or 謝罪(これはないか)

454 ：デフォルトの名無しさん：04/02/08 22:43

447じゃないけど、
WebLogic（JLockit）やWebSphere（IBMJava）でも
大丈夫？

455 ：デフォルトの名無しさん：04/02/08 23:06

何が？

456 ：デフォルトの名無しさん：04/02/11 05:41

アスペクト指向て多重継承できるならあまり
意味はないと思わない

457 ：デフォルトの名無しさん：04/02/11 06:15

ﾅｸﾅｸﾅｲﾅﾝﾃﾅｲﾅｲ

458 ：デフォルトの名無しさん：04/02/11 10:34

多重継承をよりよく整理するために必要な概念だと思われわれわれ・・・

459 ：デフォルトの名無しさん：04/02/11 12:44

多多多多多重多多多多多重継承多多多多

460 ：デフォルトの名無しさん：04/02/11 14:39

>>をよりよく整理するために
タイミングの問題ですか（BEFORE　AFTERとか）
それ以外にメリットてある？

461 ：デフォルトの名無しさん：04/02/15 10:04

>>460
ネタ？
タイミングって、、、すげぇ用語使うな。
多重継承の問題点と課題でも、しぃらべぇればぁ？

462 ：デフォルトの名無しさん：04/02/18 01:19

アスペクト指向はお腹をいっぱいにしてくれまつか？

463 ：デフォルトの名無しさん：04/02/18 08:29

∧＿∧
　（　´∀｀）＜食べ物じゃないぽ

464 ：デフォルトの名無しさん：04/02/21 14:39

>>455
SUN以外のJDKでも大丈夫なのか？
ということかと。

465 ：デフォルトの名無しさん：04/02/21 18:41

javapressで初めて実務アスペクトＪのコードを見た

466 ：デフォルトの名無しさん：04/02/22 00:02

JDK依存のクラスライブラリなんて誰が使うんだ

467 ：デフォルトの名無しさん：04/02/22 01:33

>>466
大丈夫かっつーのは、AspectJじゃなくて
>>446が書いたコードのことだよ。
ついでにAspectJはクラスライブラリじゃないよ。

468 ：デフォルトの名無しさん：04/02/22 01:51

>>464
俺もそれが心配なんだけど、Java仕様には、こう決めろとも
コンパイラが決めろとも書いてないんだよなぁ。
まあ、命名規則が違っても、それが安定(コンパイル毎に変わらない)
してるものなら、同じような方法で対応できるっしょ。
安定してないようなコンパイラは知らない。

469 ：デフォルトの名無しさん：04/02/23 01:33

>>467
Test$1って、Test.javaをちょっといじると、$1が$2になったりして、結果
aspect側も修正が必要になってしまうから、そんなaspectは書かん方
がいいと思うが。
そういう場合は、名前ベースのpointcutでなく、型ベースのpointcut
にするとか、名前を付けるとか、他の方法を考えた方がいい。

名前ベースのpointcutは、命名規則が守られていないと正しく適用
できないのだから、anonymousインナークラスにも正しく適用できんよ。

470 ：デフォルトの名無しさん：04/02/23 18:46

AspectCって流行らないんですか？

471 ：デフォルトの名無しさん：04/02/25 20:00

流行るも何も、存在すらしてない

472 ：デフォルトの名無しさん：04/02/29 00:58

「アスペクト指向はオブジェクト指向の補完物であって、オブジェクト指向の代替物とはなり得ない」
と否定的な見解を示す方が、２ちゃんねるの外に居られるようだが、
なんでそんなに必死なのだろう？

それでは、
「オントロジー・モデリングは、将来的にオブジェクト・モデリングの代替物となる可能性を秘めて居る」
という意見があったとして、それに対してはどのような見解を示すのだろうか？

非常に気になる。

473 ：デフォルトの名無しさん：04/02/29 01:00

で、AcpectCが無い理由はなんだよ？

474 ：デフォルトの名無しさん：04/02/29 01:06

>>472
ほんの 10 年も経たない前には、
オブジェクト指向は現場では使えないと言われていたのだけどね(今でもか？)。
現在だけを見るのではなく、将来的な可能性を考えるくらいの想像力はほしい。
つか、単に新しいことを覚えるのが嫌なだけだったりして。。

475 ：デフォルトの名無しさん：04/02/29 01:10

>>474
>オブジェクト指向は現場では使えないと言われていた

これって何でですか？　パフォーマンスが出ないとかかな。

476 ：デフォルトの名無しさん：04/02/29 01:26

>>474
しかもその発言元が業界トップだったりするから、始末が悪い。ｗ

ママンみたいに優しく言ってくれなきゃ、いやだぁ～ｗ

477 ：デフォルトの名無しさん：04/02/29 01:38

>>472
間違ってはいないと思うが。
オブジェクト指向が正しく実践されて、良くリファクタリングされているコードにおいて、
アスペクト指向はその威力を最大限に発揮できる。

478 ：477：04/02/29 01:39

いや、でも補完は過小評価だな。
補完以上のものは確実にある。

479 ：デフォルトの名無しさん：04/02/29 02:09

>>475
10年前、か。
1.レガシーな C プログラマが、みみっちい高速化・最適化に血道をあげる社会情勢の元、
　マルチパラダイム言語 C++ が、オブジェクト指向「も」できる言語として勢力を伸ばしていたが、
　「オブジェクト指向プログラミング」が計算機資源をほんのちょっと余分に浪費する事が、
　重大な欠点であるかのように見なされて、「使い物にならない」という烙印を押された。
2.C++以外の、まっとうなオブジェクト指向言語処理系(SmalltalkやCLOS,Eiffel,Objective-C)の入手が多少困難だったため、
　オブジェクト指向は「酸っぱい葡萄」である、という負け惜しみが大手を振っていた。
3.当時の国内ソフトウェア技術発展の流れにおいて、
　オブジェクト指向は、ごく一部の例外を除き、自発的発展性を持たない、
　ある種の輸入文化として扱われていたような気がする。
　しかし当時は、国外でも開発方法論の標準が確立していなかった。
　その結果、発展途上にある開発方法論が確立するまで、
　発展途上にあるオブジェクト指向技術を取り入れたくない、
　ましてやオブジェクト指向技術の発展に寄与するのも困難、
　という悪循環が発生していたように思う。(単なる推測)

480 ：デフォルトの名無しさん：04/02/29 02:22

> オブジェクト指向の代替物とはなり得ない
そりゃそうだろ。取って代わるというもんじゃないだろ。

それはおいとくとしても、>>477であり、現実のコードは納期に追われて、
ただ、表に出るバグはなんとか押さえ込んだ、と言うレベルの現状。
そして後期は短くなる一方。

481 ：デフォルトの名無しさん：04/02/29 03:16

>>479
∑で無能馬鹿が税金を食いつぶして護送船団やってたのが
尾を引いているとかかなあ？
馬鹿ばっかりだったからな。あの頃。

482 ：デフォルトの名無しさん：04/02/29 11:52

アスペクト指向ってJavaでしかまだまともに使えないんだろ？
まともに使えるのかどうかも知らないけどさ。
オブジェクト指向の前例を考えても、あと１０年は掛かるな。
話にならないじゃないか。

483 ：デフォルトの名無しさん：04/02/29 13:37

オブジェクト指向分析はわかるが
アスペクト指向分析ってあるの?

それができないと代替できないんじゃないの?

484 ：デフォルトの名無しさん：04/02/29 14:19

>>475
「大人」の世界には補助輪は必要なかったから。
しかし、現実社会での人口の比率は
「幼い子供」の方が圧倒的に多かった。

485 ：デフォルトの名無しさん：04/02/29 14:26

話が飛んでるが、アスペクト指向開発自体、現時点では
ニッチを埋めるだけというのはどうなったんだ？

486 ：デフォルトの名無しさん：04/02/29 14:38

>>685
アスペクト指向が理解されていない以上、
開発も糞もあったもんじゃない。

よく分からんけど恐らく「ニッチを埋めるだけ」
の小手先のトリックなのだろう、
という解釈をされて終わり。

487 ：デフォルトの名無しさん：04/02/29 15:03

オブジェクト指向に対応した言語、オブジェクト指向で設計された
ライブラリやフレームワークが提供されて初めて、一般的になった。
アスペクト指向も同じだろ。
現状では、新しいもの好きや、アスペクト指向の価値が理解出来る人間以外、
使わないと思う。

488 ：デフォルトの名無しさん：04/02/29 15:04

日本語書いてくれよぉ。

489 ：488：04/02/29 15:10

>>488は>>486へ。

>>487
> アスペクト指向の価値が理解出来る人間以外、
というより、アスペクト指向に問題意識が偏ってる人間、ね。
なんでも最初はそれでもいいけど、広く見たときにほんとに使えるものであるかどうか。
大体、指向なんていうほど、ご大層なものなのか、と。
OOの代替なんていってるやつは本気でいってんのかと。まさに偏ってんじゃないのかと。

490 ：476：04/02/29 16:39

件の発言に関し、気に食わない点は、
オブジェクト指向から派生した新技術を、全てオブジェクト指向のバリエーションである
言い切ってしまうような傲慢さ、である。
宗教信仰者の単純な「信仰告白」、例えば
「オブジェクト指向は情報技術進化の最終形である」とか
「どのような新しい概念も、全てオブジェクト指向の理想の、実現形態である」とか
を聞いてるみたいで、ちゃんちゃらおかしいのである。

オブジェクト指向技術が世の主流になった今日、
新技術や技術シーズの多くは、
確かにオブジェクト指向となんらかの接点を持っている。
しかし、それら新技術の目的は、必ずしも
現在のオブジェクト指向を補完したり、
かつてのオブジェクト指向の理想を実現すること、
とは限らない。オブジェクト指向とは直交した概念を扱いながら、
それをオブジェクト・モデルにマッピングしている事もある。

例えば、
デザインパターン、リファクタリング、アスペクト指向は、
ソースコードのモジュール間に働く相互作用を、
うまく検出し、設計～実装にダイレクトにフィードバックするための試みである。
それは、確かにオブジェクト指向の概念の上に構築されてはいるが、
業務システム開発で有効なビジネス・モデリングやユースケース駆動開発に代表されるような
いわゆる「オブジェクト指向開発方法論」とは、全く無関係に存在し得る体系である。

それらの、新しい技術的萌芽を、妙なイデオロギーで歪めて、
オブジェクト指向開発方法論の下位概念である、と貶める意図が、
私には全くもって理解できない。

491 ：デフォルトの名無しさん：04/02/29 16:51

被害妄想も甚だしい。大袈裟すぎる。
つうかそもそもユースケースって別にOOと関係ないじゃん。自分で自分の言ってる事に反してるよ。

492 ：デフォルトの名無しさん：04/02/29 16:54

降臨されますたか？

493 ：デフォルトの名無しさん：04/02/29 16:55

神ｷﾀ━(ﾟ∀ﾟ)━( ﾟ∀)━( 　ﾟ)━(　　)━(ﾟ　)━(∀ﾟ )━(ﾟ∀ﾟ)━!!!!

494 ：デフォルトの名無しさん：04/02/29 16:57

>>491

いや、オブジェクト指向開発方法論の構成要素を上げただけなんだけど、何か？

495 ：デフォルトの名無しさん：04/02/29 17:04

元々オブジェクト指向って
オブジェクト間のメッセージ通信の意味しかないだろ。

classとかinheritanceとかあんま関係ない。
Smalltalkとかの古代のＯＯ言語の実装から
おまけ的にくっついてきただけ。

genericとかtemplateは畑も違うし。

なんでもかんでも「オブジェクト指向」って言うやめろ。
こんなとこで叫んでも無意味なのはわかってるが

496 ：デフォルトの名無しさん：04/02/29 17:07

というか、アスペクト指向のスレで何が言いたいわけ？
OOPとAOPは直交概念というのは既出だが？

497 ：デフォルトの名無しさん：04/02/29 17:09

それともニッチを埋めるだけというのが、真を付かれて逆ギレしたか？

498 ：490：04/02/29 17:23

>>495
それは、単なるメッセージ・パッシングでしょ。オブジェクトと無関係 (ﾌﾟ
ﾌﾟラズマって言いたいだけじゃないかと、小一 (ﾌﾟﾌﾟﾌﾟ

>>496-497
ﾌﾟ逝一まだ粘着してたのか。
おまぃさんは、話題が貧困だから、あんまお話したくないよｗ

499 ：デフォルトの名無しさん：04/02/29 17:24

ちゃねら～相手にマジ議論ｶｺﾜﾙｲ

500 ：デフォルトの名無しさん：04/02/29 17:48

なんで俺がプ逝一なんだよｗ
まともにレス出来ないんなら、板違い。こっちへ→ http://etc.2ch.net/denpa/

501 ：デフォルトの名無しさん：04/02/29 18:35

普通のちゃねら～の反応：　「ﾌﾟ逝一」？何、それ（　ﾟдﾟ）ﾎﾟｶｰﾝ
荒らしのお決まりの反応：　お、オレはﾌﾟ逝一じゃねぇよ、何言い掛かりつけてんだよ(脂汗

502 ：デフォルトの名無しさん：04/02/29 19:28

例の過疎板製造人の反応：
　　○△□(自分の気に入らないもの全て)は板違い。こちらへ → デムパ板

503 ：普通のちゃねら～：04/02/29 19:31

「ﾌﾟ逝一」？何、それ？

504 ：１：04/02/29 19:35

レスを読み取れない低能煽り人の居るスレはここですか？

505 ：デフォルトの名無しさん：04/02/29 19:48

aop

506 ：デフォルトの名無しさん：04/02/29 21:00

ここは病人だらけのｲﾝﾀｰﾈｯﾂでつね。

507 ：１：04/02/29 21:12

鬱病の人は、カキコしなくて結構です。
お引き取り下さい。つーか、スレ違いだよ>>506

508 ：１：04/02/29 21:14

じゃ、終了って事で。
■■■終了■■■

509 ：デフォルトの名無しさん：04/02/29 22:06

　>>495がトンチンカン

510 ：デフォルトの名無しさん：04/02/29 22:07

人のせいにしない

511 ：デフォルトの名無しさん：04/02/29 22:16

客観的に見て、>>495はトンチンカンな事を逝ってるね。
>>498は、それを辛うじてフォローして居る訳だが、
>>495はそれに気づいているのかいないのか不明。

で、腐った空気を嗅ぎ付けた>>510は、
ハイエナのごとく揚げ足取りを始めて居る。

と、これが今のこの糞スレの状況か。

512 ：デフォルトの名無しさん：04/02/29 22:18

とりあえず>>1は、何か聞かれたときに知識を提供する以外、レスしないで欲しいな。
それなりの議論はあるスレなのに、>>1が自分でスレを荒らしている。

513 ：デフォルトの名無しさん：04/02/29 22:19

ここは揚げ足取り大好きで、有意な議論をするのが著しく困難なｲﾝﾀﾈｯﾂですねｗ

514 ：デフォルトの名無しさん：04/02/29 22:20

>>512
きみのレス番号、あげてみそ。

515 ：デフォルトの名無しさん：04/02/29 22:22

>>512みたいな荒らしは今後一切このスレに書き込みをしないでくれ。

516 ：1：04/02/29 22:25

じゃ>>499-513は、削除人さんにあぼーんしてもらう事にして、
>>498から議論続行↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

517 ：1：04/02/29 22:26

じゃ>>499-515は、削除人さんにあぼーんしてもらう事にして、
>>498から議論続行↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

518 ：デフォルトの名無しさん：04/02/29 22:31

1が仕切り出すと碌な事にならん
碌な事にする程のスレでもない、か

519 ：デフォルトの名無しさん：04/02/29 22:33

移行推奨。
「OOPの次はAOPだそうですね？」
http://pc2.2ch.net/test/read.cgi/tech/1004962559/

520 ：デフォルトの名無しさん：04/02/29 22:40

>>518
>>1として、移行推奨スレは、Yahoo e-groupの関連テーマですが、
あんたはなんでそこで仕切り出すの？
実名掲示板で続きをやってくれ、頼むからｗ

521 ：デフォルトの名無しさん：04/02/29 22:41

結論： >>495, >>512 は、質問に答える能力のない荒らしですた。

522 ：デフォルトの名無しさん：04/02/29 22:43

移行推奨（>>1以外）。
「OOPの次はAOPだそうですね？」
(p)http://pc2.2ch.net/test/read.cgi/tech/1004962559/

523 ：デフォルトの名無しさん：04/02/29 22:45

実名が好きなら自分で晒せばいいのに。
だいたい、>>1と七誌を使い分けてるくせに。

524 ：デフォルトの名無しさん：04/02/29 22:53

え？漏れは e-groupの方にも居るよ。
もまいさんも実名さらしてはいかが？

あと、>>476=>>490=>>1であることは言うまでもない、

525 ：デフォルトの名無しさん：04/02/29 23:07

じゃ、>>499以降は荒らしによる議論妨害と、その余波による無駄レス、って事で、
>>499以降全部削除って事で。

しかし、移行推奨荒らしはじめたかれ、
このスレの意図が読めてないみたいだね。
ちゃんとスレ読んでれば、こんな稚拙な荒らしはできないはずなわけだがｗ

526 ：デフォルトの名無しさん：04/02/29 23:07

あｑｗせｒｔｇｙふじこ

527 ：デフォルトの名無しさん：04/02/29 23:24

>>1、あっちまで荒らすのはいい加減にしろ。

528 ：デフォルトの名無しさん：04/02/29 23:26

荒らしは放置でよろしく。
例えば >>527みたいなの。

529 ：デフォルトの名無しさん：04/02/29 23:31

のっけから触ってんじゃン、お前ｗ

530 ：デフォルトの名無しさん：04/02/29 23:34

しかし、ホントこの板、人っ気ないな。
居るのは低能な荒らしばっか。
おいしいネタを提供しても、
それをうまく料理する能力もなく、
スレを荒らして回るだけ。

２ちゃんもそろそろ不要かなぁ～（ｗ

531 ：デフォルトの名無しさん：04/02/29 23:36

>>530
君のような書き込みしかしない人にとっては不要でしょう。

532 ：デフォルトの名無しさん：04/02/29 23:37

>>531
荒らし煽りは、コミュニケーション能力に問題ある人物の、ヒステリー症状。
２ちゃんはそんな奴の吹きだまりだから、まっとうな人間は近寄らない。
これ常識。

533 ：デフォルトの名無しさん：04/02/29 23:37

IoDeleteDevice(>>530);

534 ：デフォルトの名無しさん：04/02/29 23:37

糞スレageんじゃねぇ。ヴォケが！

535 ：デフォルトの名無しさん：04/02/29 23:39

dokoga oishii neta nanoka,
wakarann towa , hontou ni hisan dana.

536 ：デフォルトの名無しさん：04/02/29 23:40

なんだこのスレ。HSPスレ以上だな。
つうか、マジ真性はいってねぇ？>>530とか。
おもろいからもっとやれ。
ただしsageでな。

537 ：デフォルトの名無しさん：04/02/29 23:47

ルサンチマン大爆発ですねｗ
そろそろ議論を本題に戻して、と。

538 ：デフォルトの名無しさん：04/03/01 00:02

>>537
い、いや、戻すならなんか書けよ。

539 ：デフォルトの名無しさん：04/03/01 00:05

土日は暇してる学生が書き込むから総じてレベル下がりまくり。

540 ：デフォルトの名無しさん：04/03/01 00:15

ルサンチマンてｗ
何だかんだ言ってる>>1がいちばん匿名の恩恵に与ってんじゃねぇか。
それともリアルでこうなんだろうか。（（（（（；゜Д゜）））））ガクガクブルブル
つうかなんか書け。

541 ：デフォルトの名無しさん：04/03/01 06:40

書くネタも持たずにスレを荒らし続ける>>539 みたいなのは、今後一切無視でよろしく。

542 ：デフォルトの名無しさん：04/03/01 06:41

>>539
I also think so.

543 ：デフォルトの名無しさん：04/03/02 00:56

誰か>>483に対する見解を述べてくれませんか?
私も同じ疑問を持っています。

OOや構造化手法は(元はプログラミング言語や手法のみだったけど)
分析手法にまで体系化されていますよね。
AOには今のところそういう上流からの裏づけがないので、
ニッチOOとか単なる実装技法とか言われるんだと思うのですが。
今後そういうレベルの"パラダイム"が生まれる可能性はあるのでしょうか?

544 ：デフォルトの名無しさん：04/03/02 02:02

>>543
あるにはあるけど、まだメジャーなものは無いね。

ただ、実装レベルにフォーカスしてる部分が多いので、
上流まで適用されるのは結構遅いかもしれない。

とりあえずUMLに書けるようにならんかなぁ。
ステレオタイプを使えば、とりあえずは書けないこともない気がしないでもない。

545 ：デフォルトの名無しさん：04/03/02 11:43

>>543
今後1年のうちに大きく変わるんじゃない？次のJavaのバージョンから、
実行時のバイトコードの変換がJREでサポートされるようになるし、
コード変換の行き着く先は、AOPなんで。

と、それを見越したように、dWで連載が始まったな。
ttp://www-106.ibm.com/developerworks/java/library/j-aopsc/

546 ：デフォルトの名無しさん：04/03/14 14:48

>>545
THX!!!
後で読んで見るよ。

日本のジャヴァ・ワールドの方も、二回連続でAOPの連載が始まった。
なんだっけ？SoftBankの廃刊雑誌といい、ジャヴァワールドといい、
この手の技術解説はオブジェクト・テクノロジー研究所が担当なのね。

記事の内容は、Reflectio 2001 のAOP 勉強会に出ソビレタ当時、
漏れが妄想してた内容と大体一致。なんだかんだ言っても、
AOPみたいな技術を一番と必要としてるのは、
Webアプリサーバ、J2EE～EJB系の巨大フレームワークなのよねぇ～！！！

ちなみに、ジャヴァワールド2004/4の第一特集は「"COBOL→J2EE"システム移行ガイド」
ＳＵＮが盛んに叫んでた「エンタープライズ・コンピューティング」の実態が、
メインフレームベースのCOBOLの移行とは。。。かなり泣けるケツ待つでつね。

いい加減、Java以外の先端技術に移行しなくちゃねぇー、と思い初めてはや４年、
なかなか次に移れないワタシ。。。

547 ：デフォルトの名無しさん：04/03/14 14:56

蛇足。
第一特集の方も、なかなか読み応えある。

今まで漏れ認識では、
Web & Desktop computingの一部：ＯＯ
クラサバ & RDBMSの世界のしと：ＤＯＡ（画面と帳票とＤＢｴﾝﾃｨﾃｨとか）
メインフレームの人：　　　　　ＰＯＡ（何でもファイルで中継ぎするバッチ処理とか）

かと思ってたんだけど、

実際はメインフレーム、ＣＯＢＯＬの世界の人は、
ＤＯＡを中心に置いて仕事を進めてるのね。
今、ＤＯＡとＯＯの間を結ぶ仕事始めたばっかりだから、
なかなか参考になりまっせ＞＞ｼﾞｬｳﾞｧﾜｰﾙﾄﾞ編集部殿

ところで、この手の世界、ＯＯだけでなく一気にＡＯＰまで突っ走れないだろうか？
などと妄想する日曜日の昼下がり。皆様なにをしておいででせうか？

548 ：デフォルトの名無しさん：04/03/14 15:48

AOPに一番近いのはデバッガでの実行トレースだと唐突に思った。
あのトレースに出力レベルやs/nを設定できたら大体似たような感じになるよね。
コードにログ出力用のメタ情報が付随してるようなかんじで。

だとしたらAOPはコード生成側じゃなくて実行環境にこそ向いているものだと思う。
それをコード側で処理しようとするから胡散臭いことになってるんじゃないか。

549 ：デフォルトの名無しさん：04/03/14 15:55

>>547
はぁ。

550 ：546：04/03/14 16:01

ｼﾞｬｳﾞｧﾜｰﾙﾄﾞの記事、斜めにざっと読み終えた。

JBoss AOP＝AOPのサブセット、
　　　　　　J2EEのdeployment時設定を、アスペクトとして捕らえて、
　　　　　　JBoss Intercepterというテクニックで実装した物、
って感じか。

JBoss AOPがAOPのフルセットとは事なるっつう議論が、
　　http://www.TheServerSide.com/news/thread.jsp?thread_id=21156
にある、つう情報が非常にありがたい。これから読み逝ってきます。。。
OOシンポジウムで千葉先生が言ってた「J2EEをAOPするだけがAOPの目的ではない！」っつう発言と重なってて、なかなか興味深い

551 ：デフォルトの名無しさん：04/03/14 16:10

だから、Dynamic Proxy APIでいいじゃんっていってんじゃんオマエラ。

552 ：デフォルトの名無しさん：04/03/14 16:11

>>548
デバッグ・トレースは、
・CPUが持つ1step実行機能(元々デバッガ向け機能)と、
・バイナリに付いてるデバッグ情報(コードとの対応関係、シンボル情報、型情報)
によるものでしょ。

AOPで,プロファイラやメソッドレベル・トレーサの実装を検討できるかもね、
って程度にしか、関係ないと思うけど。

何で脈絡無い思いつきを自信満々にカキコするですか？

553 ：デフォルトの名無しさん：04/03/14 16:12

まじ、２ちゃんの低能嵐って、うざいなぁ～。
話わかんねえ癖にクチバシつっこむんじゃねぇ、と。

554 ：デフォルトの名無しさん：04/03/14 16:16

メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？

DynamicProxyAPIにインスタンス生成常に任せて、InvocatioinHandlerで
InterceptingFilterができるジャン、外部ライブラリ要らないじゃん、
って言ってるだけなんですが、ﾜﾀｼの発言は低能ですか？

555 ：デフォルトの名無しさん：04/03/14 16:29

荒らしはすっこんでろ！
誰もDynamicProxyの話なんかしてねぇーんだよ。

他の人の話にちゃんと受け応えできるようになってから、カキコ汁！

DynamicProxyでAOPしたいなら、そーゆースレ自分で立てろよ

556 ：デフォルトの名無しさん：04/03/14 16:31

そこでブチ切れでつよ(笑

557 ：デフォルトの名無しさん：04/03/14 16:34

おバカちんでつね>>554

558 ：デフォルトの名無しさん：04/03/14 16:37

しかも、JBossのIntercepterだけがAOPじゃないよね、
つう学者さんのネタふってるそばから、InvocationHandlerでInterceptingFilter(ﾌﾟﾌﾟﾌﾟ

春、ですねぇ～

559 ：554：04/03/14 16:44

何でこんなに攻撃食らうのか、よくわかっていませんが…
IoCコンテナのAOPってｺﾚでやってるんじゃないの？

J2EEに限らず「どこでもAOP」できるよね？

560 ：デフォルトの名無しさん：04/03/14 16:49

IoC？そりゃ、なんの話？
今の議論となんか関係あるの？
荒らし相手にマジレスしてるほど暇じゃないんだけどさぁ

561 ：デフォルトの名無しさん：04/03/14 16:59

これだから、実装の話しか理解できん下級プログラマは使えない、と。ﾔﾚﾔﾚ

562 ：デフォルトの名無しさん：04/03/14 18:03

>552 あんたのデバッガは低機能なんだな。 perl -d ですらもうちょっとマシな仕事するぞ

563 ：デフォルトの名無しさん：04/03/14 18:32

激しくスレ違い。さっさと巣にカエレ

564 ：デフォルトの名無しさん：04/03/14 18:43

http://info.2ch.net/before.html
頭のおかしな人の判定基準

・「みんなの意見」「他の人もそう思ってる」など、自分の意見なのに他人もそう思ってると力説する人
　他人が自分とは違うという事実が受け入れられない人です。自分の意見が通らないとコピペや荒らしなど
　無茶をし始めるので見かけたら放置してください。

・根拠もなく、他人を卑下したり、差別したりする人、自分で自分を褒める人
　他人を卑下することで自分を慰めようとする人です。実生活で他人に褒めてもらう機会がないが
　プライドだけは高いとか、匿名の掲示板しか話し相手のいない人です。可哀想なので放置してください。

・自分の感情だけ書く人
「～～がムカツク」とか自分の感情を掲示板に書くことに意味があると思っている人です。
何がどのようにムカツクのか論理的に書いてあれば、他人が読んでも意味のある文章になりますが、
そういった論理的思考の出来ない人です。もうちょっと賢くなるまでは放置してあげてください。

565 ：デフォルトの名無しさん：04/03/14 18:44

>>554
interceptされる側がインターフェースを実装して、
アプリケーションが生成時に必ずProxy.newInstanceして、
それで自由にcrosscuttingできていると言えるのかね。

566 ：デフォルトの名無しさん：04/03/14 18:49

ああ、こうしてスレは腐っていくのね。
まったく、ソフトウェア技術の低レベルな所しか理解できてない初心者が、
大口叩く匿名板は、使い物にならないね

567 ：デフォルトの名無しさん：04/03/14 18:51

それから、DynamicProxyの実装の話をしたい人は、別スレでどうぞ。
動的自由度の話は、あっちのスレの話題であって、こっちのスレは関係ありません。
なんで脈絡なく、へんな話題振ってくる香具師がいるかと思ったら、あっちのスレの話題じゃんｗ

568 ：今日の恥ずかしい厨房発言：04/03/14 19:10

>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？
>>554
> メソッドコールをクロスカッティングコンサーンとやらと認識することにして、
> 型関係なしにそのクロス(以下略)にフックかけていろいろするんでしょ？

569 ：デフォルトの名無しさん：04/03/14 19:38

あっちのスレを荒らすのは止めていただきたい。
ちなみに漏れはこのスレには半月ほどレスしてませんので。

570 ：デフォルトの名無しさん：04/03/14 19:49

つまり、お前が荒しなんだな。
さっさと回線切って引き篭もれ

571 ：569：04/03/14 19:52

>>このスレ
ってのは、もちろんこっちのスレ「↑↑↑アスペクト指向とは何か↓↓↓」ね。

572 ：デフォルトの名無しさん：04/03/14 19:59

粘着ｷﾓﾁﾜﾙｲ

573 ：デフォルトの名無しさん：04/03/14 22:04

しかし、本当にレベル低いね～、この板。
海外のプロジェクトの仕事小耳に挟んで、それを脈絡無く主張する厨房。
まっとうな議論なんて、できやしねぇよな、こんな厨房板じゃ。

574 ：デフォルトの名無しさん：04/03/15 01:05

日本のジャヴァ・ワールドの方も、二回連続でAOPの連載が始まった。
なんだっけ？SoftBankの廃刊雑誌といい、ジャヴァワールドといい、
この手の技術解説はオブジェクト・テクノロジー研究所が担当なのね。

記事の内容は、Reflection 2001 のAOP 勉強会に出ソビレタ当時、
漏れが妄想してた内容と大体一致。なんだかんだ言っても、
AOPみたいな技術を一番と必要としてるのは、
Webアプリサーバ、J2EE～EJB系の巨大フレームワークなのよねぇ～！！！

ちなみに、ジャヴァワールド2004/4の第一特集は「"COBOL→J2EE"システム移行ガイド」
ＳＵＮが盛んに叫んでた「エンタープライズ・コンピューティング」の実態が、
メインフレームベースのCOBOLの移行とは。。。かなり泣けるケツ待つでつね。

いい加減、Java以外の先端技術に移行しなくちゃねぇー、と思い初めてはや４年、
なかなか次に移れないワタシ。。。

575 ：e：04/03/15 01:06

第一特集の方も、なかなか読み応えある。

今まで漏れ認識では、
Web & Desktop computingの一部：ＯＯ
クラサバ & RDBMSの世界のしと：ＤＯＡ（画面と帳票とＤＢｴﾝﾃｨﾃｨとか）
メインフレームの人：　　　　　ＰＯＡ（何でもファイルで中継ぎするバッチ処理とか）

かと思ってたんだけど、

実際はメインフレーム、ＣＯＢＯＬの世界の人は、
ＤＯＡを中心に置いて仕事を進めてるのね。
今、ＤＯＡとＯＯの間を結ぶ仕事始めたばっかりだから、
なかなか参考になりまっせ＞＞ｼﾞｬｳﾞｧﾜｰﾙﾄﾞ編集部殿

ところで、この手の世界、ＯＯだけでなく一気にＡＯＰまで突っ走れないだろうか？

576 ：e：04/03/15 01:06

577 ：デフォルトの名無しさん：04/03/15 01:48

粘着荒しうざ。やり口が分かりやすすぎて萎える。

578 ：デフォルトの名無しさん：04/03/15 01:53

あっちでも粘着してるのはここの>>1ですか？
悪意を持って自演してるのなら、自分という人間を見つめ直すことを強く薦める。

579 ：デフォルトの名無しさん：04/03/15 01:57

荒らしの最近の口癖は「おまえは荒らしだ」だそうです。可哀想な人。
>>577-578はスルーで、また～り議論を継続って方向で。

580 ：デフォルトの名無しさん：04/03/15 03:20

>>543
要求分析で現れる、システムに対する非機能的特性が、アスペクトと関連し得る
ってな話は雑誌ジャバワールドの記事にも載ってるよね。それだけじゃ不満足なのかな？

581 ：デフォルトの名無しさん：04/03/15 12:14

> アスペクトと関連し得る
ってだけじゃなくて、
具体的にどこまで体系化されてんの?体系化されうるの?
っていう問いじゃないの?

582 ：デフォルトの名無しさん：04/03/15 12:18

http://pc2.2ch.net/test/read.cgi/tech/1004962559/529
http://pc2.2ch.net/test/read.cgi/tech/1004962559/521
http://pc2.2ch.net/test/read.cgi/tech/1004962559/518
http://pc2.2ch.net/test/read.cgi/tech/1004962559/515
http://pc2.2ch.net/test/read.cgi/tech/1004962559/514
http://pc2.2ch.net/test/read.cgi/tech/1004962559/511
は、ここの1さんですか? ほかの人ですか?

583 ：デフォルトの名無しさん：04/03/15 12:24

>>581
きみんところの分析屋、もしくはグループのメンバーが優秀だったら、
即座に取り入れられるだろうし、そうじゃなかったら、体系化されてても使いこなせない、
ただそれだけの話でしょ。ちっちゃな事例から始めるのが吉ですね。

584 ：デフォルトの名無しさん：04/03/15 12:33

んー、どういうのをアスペクトに切り出すか、切り出すとよいか、(分析フェーズで)切り出せるか、
ってところは、それなりに収束してるの? ってことじゃないかな?
優秀な人が集まっても、10人10色の俺様AOAで大変になっちゃうのではないかと。

585 ：デフォルトの名無しさん：04/03/15 12:34

あと、OOAとの共存(置き換え?)方法もね。

586 ：デフォルトの名無しさん：04/03/15 12:41

ジャヴァワールドの記事でも嫁。
後、分析設計方法が確立していない場合、
JBossとかAspectJ使った実装からリバースして分析設計方法決めるのが、
よくある手口でしょ。
ちょうど、OOD/OOAが、旧来の分析設計手法とOOPのすり合わせで誕生したように。
分析設計手法まずありき、ではなくて、実装屋の頭の中に収まる暗黙の分析設計手法があり、
次にそれが外部化されて共有知識になる、ってどの分野でも一緒だけどｗ

587 ：デフォルトの名無しさん：04/03/15 12:48

引こもりの人なのかなぁ。
まともに社会的訓練受けた形跡が見受けられない発言だなぁ。
「優秀な人が集まっても、10人10色の俺様AOAで大変になっちゃうのではないかと。」
10人10色にばらけちまうのは、プロジェクトまとめてる人の方針なり、個々のメンバーの素質の問題でしょ。
ばらけてもいいから、問題解決方法いろいろ出させて、次にそれを共通手法にまとめていくのか？
あるいは、密接な協調作業が必要だから、リーダが何も言わなくても、自分たちで共通案をまとめるのか？
10人10色でばらけて、それがプロジェクトにとって命取りになるんだったら、
試行場所選択について、協調作業について、なんらかの欠陥のある、優秀じゃない人達なんだろうね。

588 ：デフォルトの名無しさん：04/03/15 12:52

教育機関の研究者には、協調性のないお山の大将、も居るようだけどｗ
企業でそれやるのは、むちゃくちゃ能力あって放っておいても実績出せる人だろうね。
そしたら、そーゆー人が集まって協調作業するはずもないしｗ

589 ：デフォルトの名無しさん：04/03/16 00:00

>JBossとかAspectJ使った実装からリバースして分析設計方法決めるのが、
>よくある手口でしょ。
よくある手口なのか？
実装をリバースしてどう分析設計方法が決まるんだ？
というか、つまりは決まって(収束して)ないんじゃん。

590 ：デフォルトの名無しさん：04/03/16 00:54

JavaWorldになんか大したこと書いてあったか？
とくに、アスペクト指向分析なんて、
ちょいと妄想こいたのが漏れちゃった程度じゃん。

591 ：デフォルトの名無しさん：04/03/16 01:01

リスペクト指向

おまいら、俺をリスペクトしな

592 ：デフォルトの名無しさん：04/03/16 01:06

>>589
歴史をご存知ない？
OOA/OODも、OOPと従来の分析設計手法の両側の積み上げがあって、
成立したって、上に書いただろ。前レスも読まずに煽るとは、程度が低いなｗ

>>590
書いてあったけどｗ

593 ：デフォルトの名無しさん：04/03/16 01:10

>>589って、典型的な負け組みだなｗ
儲け方が確立してから、のこのこ出てくるような、永遠の負け組み

594 ：デフォルトの名無しさん：04/03/16 01:10

>>592
なんだこいつ？真性基地外か？ただのアフォか？
話わかってて書いてねぇな。駄目だこりゃ。

595 ：デフォルトの名無しさん：04/03/16 01:12

594=1

596 ：593：04/03/16 01:41

>>594,>>595
基地の人をからかうのは、なかなかおもしろいな。
昼から夜の一時まで掲示板に一日中張り付いて、
孤独を癒そうとするあんたには、泣けてくるね

597 ：1：04/03/16 01:42

相変わらず、低スキルなガキがうろついてるねぇ

598 ：デフォルトの名無しさん：04/03/16 01:44

文末にｗつけるアホが常に粘着してるからねえ。

599 ：デフォルトの名無しさん：04/03/16 01:45

>>594-595
テンパってるね。カキコがぎこちないよ。
強情張らずに「理解できませんでした」って謝れば、
説明してやらないでもないのにｗ

600 ：デフォルトの名無しさん：04/03/16 01:46

な、>>598、謝っちまえよ、
そしたら、少しは面白い話してやるからｗ

601 ：デフォルトの名無しさん：04/03/16 01:51

>>600
ｗ君を見ているほうが面白いので、一人で暴れてていいよ。

602 ：デフォルトの名無しさん：04/03/16 01:54

おれ、中学生にキミ呼ばわりされる覚えはないんだけどｗ
なんか、２ちゃんてキショイ餓鬼が多くて、付き合いきれんなぁ～

603 ：デフォルトの名無しさん：04/03/16 09:29

>>602
現実社会での地位を持ち出す奴ｷﾀｰ

604 ：デフォルトの名無しさん：04/03/16 12:22

ｗ君、次はどんな基地っぷりを晒してくれるんだろう。
o(^-^)o ワクワク

605 ：デフォルトの名無しさん：04/03/16 12:42

屑はスルー、っと。

606 ：デフォルトの名無しさん：04/03/16 12:47

ｷﾀ━━━━━━━━(ﾟ∀ﾟ)━━━━━━━━ｯ!!
弁当最後の一口吹き出しちまったよ！

607 ：デフォルトの名無しさん：04/03/16 12:57

カフェで優雅にカフェ啜ってますが、何か？

608 ：デフォルトの名無しさん：04/03/16 13:03

お前ら実は楽しくじゃれ合ってねえ？

609 ：デフォルトの名無しさん：04/03/16 13:10

カフェで優雅にカフェ啜りながら2chするなんてすごすぎるぅぅ！（≧▽≦）ノ
しかも優雅に！しかもカフェでカフェすする！超越しすぎ！！
夜は、優雅にフレンチディナーをとりながら2chカキコキボン！

610 ：デフォルトの名無しさん：04/03/16 22:55

夜は、自宅でワインなど嗜みますが、何か？

おまぃら、下らないネタでよろこんでるんじゃねぇ～よ

611 ：デフォルトの名無しさん：04/03/16 23:49

このスレが荒れるようになったってことは
AOPも一般的になったってことだなと感慨深い。

612 ：デフォルトの名無しさん：04/03/17 00:12

ｗ先生、今晩のワインはどちらの銘柄でしたか？

613 ：デフォルトの名無しさん：04/03/17 02:32

ヲチしてたけど、こう撃沈されてぐぅの音も出ないのを見たら、
なんか哀れになってきた。どうしてもリアルを想像しちまう。

614 ：930：04/03/17 07:54

うん、そうだね。厨房いじめすぎたかな。

615 ：デフォルトの名無しさん：04/03/17 12:34

きょうも優雅に脳内カフェからレスをしてくるんだろうか。

616 ：デフォルトの名無しさん：04/03/17 12:56

ん？今、カフェ。Business checkをOCLで記述して整理したくて、OCLの原書流し読み中。
隣の席は、なんか来年の新卒就職活動してるねぇーちゃんたち、かな。
むやみやたらに元気あって、何にでもチャレンジする彼女らがうらやましい、かな。

617 ：デフォルトの名無しさん：04/03/17 15:53

http://www.aspectc.org/

618 ：デフォルトの名無しさん：04/03/18 01:16

基地と戯れるスレ？

619 ：デフォルトの名無しさん：04/03/18 02:00

ところで、コードジェネレータ/コード生成ウィザードをアスペクト指向で書くという提案、
誰かサンプルつくらねぇ？言語はAOP言語ならなんでもよし

結構いいテーマだと思うけどｗ

620 ：デフォルトの名無しさん：04/03/18 11:11

コードジェネレータとAOPが相性がよいから？わるいから？

621 ：デフォルトの名無しさん：04/03/19 12:29

さっぱりわかんないなあ。すごく簡単に書いてみてよ。

622 ：デフォルトの名無しさん：04/03/19 12:52

>>620
ふつ～、コード生成ウィザードで、
最初にオプションを選択して、一度コードを生成しちまうと、
後から生成後のソースコードを読み込んで、オプションを変更するよーな事ができない。
(UMLモデラーには、再読み込みしてコード解析できるのも多いけど)

仮に、生成するコードに「単なるスタブ以上の機能記述が仕込んである」として、
その「機能記述」を後から変更したくなったら、コードの中身を変更しなくちゃならない。
変更するファイル数が少なければいいんだけど、
ファイル数が多いと、手数がかかって面倒だ。

そこでAOPの出番ですよ！
コード生成のターゲット言語をAOP言語にして、
上で仮定した「単なるスタブ以上の機能記述」を
アスペクト(crosscutting concerns)として記述しといてやれば、
(生成済コードを再解析＆変更しなくても)
簡単に自動生成コード中の機能記述を変更できる、っつうストォリィー。

623 ：デフォルトの名無しさん：04/03/19 12:54

それで？処理系と動きがわかる一番簡単なプログラムおしえてください。

624 ：デフォルトの名無しさん：04/03/19 19:46

本体のコードを変更せずにコードを制御できることがアスペクトの特徴みたいだから
うまくこれを生かせる場面があれば・・・

625 ：デフォルトの名無しさん：04/03/19 20:40

>>622
generation gapじゃねぇか

626 ：デフォルトの名無しさん：04/03/19 22:20

Generation Gapもそうだけど、
そもそも生成ソースはブラックボックス的にするのが定石と思う。
そうならないのは、ほんとにただのキータイプを省くだけのテンプレではないかと。

627 ：デフォルトの名無しさん：04/03/20 00:50

まあ、ｗ大先生の見解を聞こうじゃないか。
きっと、Ch. Margauxの豊かな余韻にのって、漏れらじゃ気付かない、
このお題に隠されたAOPの真理を語ってくれるよ。

628 ：デフォルトの名無しさん：04/03/20 10:44

>>625
generation gapって、実務的に使えるの？
ざ～っと考えると、あ～んな問題やこ～んな問題が気に掛かる：
・最近のコード生成ウィザードは、
　generation gap classを自動生成してくれるないの？
　もし、自動生成されないならば、
・generation gapサブクラス・コードの「雛型」作成が、煩雑だね
・自動生成クラスの生成および参照(の幾つか)を、
全部、generation gapサブクラスに書き換えるのが、煩雑だね。
・自動生成クラスで、フィールドやメソッドをprivate宣言している場合、
　サブクラスによるオーバーライドが面倒だね。
　情報隠蔽の観点でいくと、親クラスをサブクラス以外から不可視にすべきなのかなぁ～
etc,etc.

629 ：デフォルトの名無しさん：04/03/20 13:28

問われている肝心の問いに対して、全然関係ない批判を展開して、
自分に向けられた問いから目を逸らそうとしている。その理由は何か。

630 ：デフォルトの名無しさん：04/03/20 13:52

>>628
概念と実装を混同してる、いい例だな。

631 ：デフォルトの名無しさん：04/03/20 13:54

厨ですな～、的外れな揚げ足取り。
最近、近所に Be! つうカフェができたんだけど、
そこでスペシャリティ・コーヒー飲んでまた～り中。
インテリアの雰囲気良くて、落ち着けるんだよね。
Be! って、元ｱﾎﾟｰ重役の人の会社かよっ！つう突っ込みはなしの方向で。。。

632 ：デフォルトの名無しさん：04/03/20 13:57

>630
　概念レベルの指摘ですが、伺か？
　>>628
　＞・自動生成クラスで、フィールドやメソッドをprivate宣言している場合、
　＞サブクラスによるオーバーライドが面倒だね。
　＞情報隠蔽の観点でいくと、親クラスをサブクラス以外から不可視にすべきなのかなぁ～

633 ：デフォルトの名無しさん：04/03/20 14:07

コード生成に対する普通のソリューションに指摘の余地があるということ、
コード生成にそれ以外の解として、ほかでもないAOPが適している理由は別の話だが？
指摘した点がAOPではこううまくいく、という話すらない。

634 ：デフォルトの名無しさん：04/03/20 14:13

>>632
これで概念レベルの指摘ねぇ。
役員会や顧客向けの資料は死んでも作れない奴だな。

635 ：デフォルトの名無しさん：04/03/20 14:20

>>632
あ～。めんどくせ～。

オーバーライドしたいメソッドがprivateなのは、generation gapの
問題じゃねーだろ。

636 ：デフォルトの名無しさん：04/03/20 16:55

相変わらず、中途半端な厨ばっかＷ
>>634
おまいねぇ、このコンテキストで「概念」つったら、ソフトウェア工学上の概念だよ！
概念＝顧客・役員向け説明　と捉えた >>634 は、
どうせヘタレソフトウェア会社の営業かなんかなんだろｗ
おまぃらは、枯れきった古い技術だけつかってりゃえぇーやんｗ

つか、役員向け資料つっても、ビジネス提案とか、新技術紹介とか、勉強会とか、
いろいろあるのを知らないのかねぇ～

>>635
う～む、行間読めない厨房は、目先の言葉に踊っちまってだめだな

637 ：デフォルトの名無しさん：04/03/20 16:57

>>633
屁理屈は上等だが、きみの意見には、
面白みも新たな地平を切り開く意気込みも感じられん。
あの～、あなたを説得したら、研究費出してくれますか～(www

638 ：デフォルトの名無しさん：04/03/20 16:58

さ～て、週末恒例、頭が発展途上の厨房が押し寄せて参りました・・・。

639 ：デフォルトの名無しさん：04/03/20 17:32

> 概念＝顧客・役員向け説明　と捉えた >>634 は、
日本語の読解力に致命的な欠陥があるようだ。
ワインだけじゃなくて、他のクスリも嗜んでいるのだろうか。
リアル世界ではえらく苦労してそうだな。周囲が。

640 ：デフォルトの名無しさん：04/03/20 18:00

>>637
指摘されたことを繰り返して逃げるばっかりだね。

>>639
リアル世界では彼に周囲の人は存在しないと思われ。
唯一、ママンはいるかも知れんが。

641 ：デフォルトの名無しさん：04/03/20 18:37

都合の悪い指摘を屁理屈呼ばわりして逃げるのは、ＤＱＮの特権。
こいつを取り上げるのは酷ってもんだぜ。

642 ：デフォルトの名無しさん：04/03/20 18:51

　　厨房って、話の本筋理解してないのに、
　　「おまぃは○×だから、だからおまぃはヴァカなんだ・・・」
　　ってな揚げ足鳥が大好きだね（ﾌﾟ

643 ：デフォルトの名無しさん：04/03/20 18:59

>>633　のような指摘の無価値さ加減について。

ソフトウェア工学的にも、実用的にも、まだまだ未解明な問題について、
これからみんなで取り組んで、理解を深め、可能なら試行例を増やし、新しい分野を切り開いていきましょう！
というのが、アスペクト指向、AOP、AOSDの、現在の位置だと思う。

ところが、厨房というのは、どんなに未知の問題であっても、
(どっかに専門家がいて、完璧な答えを出してくれる・・・)
というような幻想を持っている。
まぁ、学生さんにありがちなんだよね、既知の知識の膨大さに圧倒されて、
世の中の森羅万象全てについて、合理的な理解と説明が行われている、ってな幻想。

644 ：デフォルトの名無しさん：04/03/20 19:15

>>643の
日本語訳
「上のお題は、自分でも意味分からないまま適当に出しました」
意味
「僕も分からないんだから、まともなレスなんかできないもん。仕方ないじゃん」

645 ：デフォルトの名無しさん：04/03/20 19:36

厨房の質問って、わかりにくくていけねぇ。>>633
もっと平易な言葉で、丁寧に、
どこまで理解していて、何が理解できないのか、
説明してごらんｗ

＃ひねくれた質問を、きれいに要素分解できないあたり、やっぱ厨かｗ

646 ：デフォルトの名無しさん：04/03/20 19:39

>>636
お前が言葉の選択を間違ってるんだろ。
具体的な議論がしたけりゃ、しっかりした文章を書け。行間に頼るな。

647 ：デフォルトの名無しさん：04/03/20 19:41

>>636
とりあえずだ。

読者が行間を適切に読むことを前提にした文章を書く時点で、
技術系の人間としては失格だと思う。

648 ：デフォルトの名無しさん：04/03/20 19:41

＞＞６４５
中身無い議論が大好きな引きこもりリア厨>>633が、
きちんと意味の通った質問なんてできる訳ないだろ。かわいそうだよ。

彼が唯一できるのは、自分が理解できないのは全て相手が悪いからだ、って主張を繰り返すだ事けだよ(この板の傾向として

649 ：647：04/03/20 19:41

まさか、こんな内容で被るとは・・・

650 ：デフォルトの名無しさん：04/03/20 19:41

厨房の質問って、わかりにくくていけねぇ。>>633
もっと平易な言葉で、丁寧に、
どこまで理解していて、何が理解できないのか、
説明してごらんｗ

651 ：デフォルトの名無しさん：04/03/20 19:48

なんか、微笑ましい自演を始めたな。

652 ：デフォルトの名無しさん：04/03/20 20:01

課題:生成後の自動生成ソースをあとから要因を変更することができない。
普通の解:自動生成ソースをブラックボックス化して入れ替え可能にする。例）GenerationGapパターン
普通の解の問題:>>628 （意味不明。GenerationGapに言いがかりつけてるだけに見える。
　　　　　　　　　　　　　→行間に大切なことが埋め込まれているらしい）
AOPによる解、または
AOP使用の優位性、または
それらの可能性、または
それらの予測:未。

653 ：デフォルトの名無しさん：04/03/20 20:05

誰か、>>652を健常者向けに日本語翻訳してくれませんか？

654 ：デフォルトの名無しさん：04/03/20 20:09

>>648
ただでも寒いのに、さらに寒くさせるジエンしてんじゃねぇよ。プ

655 ：デフォルトの名無しさん：04/03/20 20:25

はぁ～あ、自作自演厨が、人様捕まえて「自作自演」呼ばわりとは、目出てぇ～や。
自作自演厨って、自分が普段やってる悪事を、全部他人がやってる事にするから、付き合い切れねぇや。

さっさと、し　ね　。

656 ：デフォルトの名無しさん：04/03/20 20:29

デムパ(>>652)来襲っすか。
来週の週末も、大変っすね＞＞厨房

657 ：デフォルトの名無しさん：04/03/20 20:30

ヒップホッパーで流行の
リスペクト指向
とは関係ありますか？

658 ：デフォルトの名無しさん：04/03/20 20:33

>>657
をぢさんが、精一杯若者ぶってるって感じ。地獄に堕ちろ(･∀･)ｐ

659 ：デフォルトの名無しさん：04/03/20 21:45

俺は、すべてを理解した。
何も聞かないでくれ。

660 ：デフォルトの名無しさん：04/03/21 00:21

ふ～ん、やっぱ天然かぁ。
なんで学術スレ(死語)に、しつこく変なレスするのかと思ってたら、
やっぱ頭の調子が悪い人かぁ～。

661 ：デフォルトの名無しさん：04/03/21 01:36

荒らしのやり口が見え見えで、反吐がでるよ

662 ：デフォルトの名無しさん：04/03/21 19:34

>>633　>>622浴嫁！
　　　　　例えprivate宣言,final宣言して、参照/拡張を制限したい部分であっても(>>628)、
　　　　　「簡単に自動生成コード中の機能記述を変更できる」つうこと。

　　　　generation gap では、overrideしてカスタマイズする都合上、
　　　　生成クラスのprivateやfinalを外す必要があり、
　　　　それを子クラスで拡張して private, final追加しても、単に子クラスが拡張しにくくなるだけで、
　　　　親クラスの情報隠蔽は不充分なままになる。
　　　　だから、子クラスからしか見えない親クラス定義みたいなのが必要なのかなぁ～、と、矛盾を指摘してるんだよ
　　　　

663 ：デフォルトの名無しさん：04/03/22 02:49

>>662
ん～。ちょっとずつ行間が読めてきた気がする。ってか行間に頼るなよ！

generation gapで子クラスがやっていることを、
アスペクト記述でやろうとしてるんだな？
そして、オーバーライドではメソッドをprotected以上にする必要があるので
情報隠蔽が崩れるが、AOPならprivateなメソッドを変更できるので
崩れないと。そう言いたいんだな？

664 ：デフォルトの名無しさん：04/03/22 12:19

> generation gap では、overrideしてカスタマイズする都合上、
> 生成クラスのprivateやfinalを外す必要があり、

ここがよく分からん。普通全体としてはテンプレメソッドに落とすんじゃない?
(もちろん子供がユーザがいじるクラスで、親が自動生成クラス(当たり前だが))
生成オプション変えた場合は変更は親の中で閉じさせるので、
privateやfinalをはずす必要がなんであるの?

ん?本体が自動生成で、ユーザがいじるのはアスペクトってことか?

665 ：デフォルトの名無しさん：04/03/23 12:46

>>664
君の言ってる事は、前提が違う。いつも話が脱線するのは、君が頭の中で勝手なシチュエーションを想定するからじゃないかな。
素直に人の話を聞く練習しといた方が早く、社会復帰できると思うよ。

666 ：デフォルトの名無しさん：04/03/23 13:11

>>665
>>665

667 ：デフォルトの名無しさん：04/03/23 17:41

どういう前提?

668 ：デフォルトの名無しさん：04/03/23 19:11

馬鹿が多すぎ。

669 ：デフォルトの名無しさん：04/03/23 22:57

>>667
行間読め

670 ：デフォルトの名無しさん：04/03/23 23:02

このおっさん、内容は行間で語るわ、文句は具体性ゼロだわ、ほんまに技術者？
どうとでも逃げられる曖昧なことしか言わない。
ま、ボロが出ないようにってことだろうけど。

671 ：デフォルトの名無しさん：04/03/23 23:28

ｶﾞｷとｵｻｰﾝが暇を潰し合って気が付くと仲良しになってるｽﾚはここですか？

672 ：デフォルトの名無しさん：04/03/24 00:19

煽りと判りつつ釣られてみる。

このスレ、ここ100レス程、内容に進展なし、やん。

こちらの考えが、きみの貧弱な頭に刻み込まれるまで、
忍耐強い教師の役目をする暇は、今の漏れには無いんだよ～ん。

673 ：デフォルトの名無しさん：04/03/24 01:12

たしかにスレは進展してないけど、この100レス程で、
君は随分成長したじゃないか。よきかなよきかな。
もう退行するなよ。

674 ：デフォルトの名無しさん：04/03/24 01:31

AOP厨も大変だな。

675 ：デフォルトの名無しさん：04/03/24 15:54

IBM、アスペクト指向プログラミング技術の実用化へ
http://headlines.yahoo.co.jp/hl?a=20040324-00000011-zdn_n-sci

> 　IBMのソフトウェアグループ戦略/開発担当副社長ダニエル・サバー氏が3月24日に
> 英ランカスターで開かれるAspect-Oriented Software Developmentカンファレンスで、
> その詳細を明らかにする計画。また同氏はここで、アスペクト指向のソフト開発技術は
> 今や商用化に十分な信頼性を確立したと宣言するという。

676 ：デフォルトの名無しさん：04/03/24 23:27

(IBMやマイクロソフトが手を付けそうな)研究途上技術の動向をきちんと把握していないと、
(IBMやマイクロソフトを出し抜いて)生き残るのは、難しい。

677 ：デフォルトの名無しさん：04/03/24 23:28

>>673
お、おまえｶﾞﾅｰ(汗

678 ：デフォルトの名無しさん：04/03/25 00:18

>>675
お、WSADに標準でAJDTとプラグインが乗るのかな？
しかし、J2EEとはどう折り合いをつけるんだろう。

679 ：デフォルトの名無しさん：04/04/03 11:57

今日は厨房来ないの？
おにぃさん、さびしぃなぁ～

銀座のオープソカフェよりかきこ★

680 ：デフォルトの名無しさん：04/04/03 18:29

脳内カフェおじさんは今日も元気でつね。なんかネタ振れよ。

681 ：デフォルトの名無しさん：04/04/06 23:39

237 名前：デフォルトの名無しさん [sage] 投稿日： 03/02/27 07:42
assertionを記述することは、デバッグにおける
原因探索の無駄を省くとは思うが、「コード化」
だけを考えたら、直接の御利益はないかもね。

とはいえ、バグっても人が死なないシステムなら
ゴメンナサイとか謝っちまえばいいのか（笑）
238 名前：デフォルトの名無しさん [sage] 投稿日： 03/03/03 13:17
Design by Contract (DbC) 周りで、
制約条件をOCLで記述する iContract が流行っているらしい。(JavaWorldで既出)

単なるassertionだけでなく、実装コードを埋め尽くすつまんない条件分けコード
を一掃するのに使えれば、いいのかな？

239 名前：デフォルトの名無しさん [sage] 投稿日： 03/03/03 13:44
iContract、AspectJ (@www.eclipse.org) に組み込んで使えるらしい。
下のFAQによると、複数のクラスにまたがるinvariants(invariants cross-cutting)
を扱えるようになるのがメリットらしい。
　http://www.reliable-systems.com/tools/iContract/FAQ.htm

個人的には、複数のAspect間の干渉を排除するヒント情報として活用できたらいいと思った

682 ：デフォルトの名無しさん：04/04/07 02:16

IBM には Subject-Oriented もあるよん

683 ：デフォルトの名無しさん：04/04/07 12:23

漏れは Separation of Concerns の方が関心あるよ

684 ：デフォルトの名無しさん：04/04/07 12:24

ちなみに、Separation of Concerns 、略して SoC とかすると、
システムLSI屋さんは、勝手に「System on Chip」とか理解しちゃうから要注意だよん

685 ：デフォルトの名無しさん：04/04/08 07:57

閑話休題

Aspectと、Parametric Polymorphismの関係は、どないなんでしょう。
ず～っと前から (パッチやプリプロセッサ/マクロの型安全性ってな意味で)気になってる。。。

686 ：デフォルトの名無しさん：04/04/14 17:29

さて, Aspect C について語って貰おうか

687 ：デフォルトの名無しさん：04/04/14 20:34

>>686
語ってやるから物をよこせ。

688 ：デフォルトの名無しさん：04/04/15 05:49

>>687
こっ・・・ここです
つ)) http://www.aspectc.org/Home.1.0.html

AspectC++でした.ごめんなさい.

689 ：デフォルトの名無しさん：04/04/20 23:52

で、新しく出たAspectJの本はどうなんだ。
よくまとまってはいると思うが、
漏れはそんなにAOPに興味無いので買うほどではなかった

690 ：　：04/04/27 22:58

オブジェクトにアスペクトが複数のっかったりしたら、コードのメンテ大変だろうな。

691 ：デフォルトの名無しさん：04/04/28 20:26

そのあたりは新しいツールで解決すると思う。

692 ：デフォルトの名無しさん：04/04/28 22:17

いや、そういう問題じゃないと思うよ。

693 ：デフォルトの名無しさん：04/04/29 12:33

べたべたの手続き記述は、実際の処理自体だからそれだけわかればコードそのままでいいけど、
オブジェクト指向もそうだけど、関心事をまとめた概念を作って概念をコード化するってのは、
実際の処理以外の概念を把握するというコストが掛かる。このコストは結構馬鹿にならない。

694 ：デフォルトの名無しさん：04/04/29 20:41

天国　ＯＯの理想：　　　　　　読み易さ、拡張し易さ、使い易さ＞書き易さ
↑
戦場　べたべた手続き型：　　　読み易さ＜書き易さ
↓
？？　大規模ﾌﾟﾛｼﾞｴｸﾄでｦｰﾀﾎｰﾙ：客の苦労＞拡張し難さ＞テスト～運用中のデバグの回数＞読み難さ＞書き難さ＞設計時の問題解決＞分析の適切さ＞プロマネの努力量

695 ：デフォルトの名無しさん：04/04/30 01:18

>>693

要するに、手続き至上主義で育った旧世代プログラマが
「手続き疑うなんて非常識！」とか了見狭い田舎者丸出し発言してるだけ、かと。

俺は、旧石器人見るような目で、彼らを眺めているんだが、
きっと彼らが引退生活に入っても、彼らが洗脳した被害者が同じ事言い続けるんだろうなぁ。。。
日本人て、個人が充分確立していないから、アフォな先輩が居ればアフォに染まるのが正しいと思ってるのが９９％だし。

696 ：デフォルトの名無しさん：04/04/30 01:30

>>695

漏れの近くにも時々そーゆー原始人が居るよ。
・UNIX並列計算クラスター上での科学技術計算で、
　計算結果をいちいちファイルに落としてから次の処理にまわさないと気が済まないPOA主義者とかｗ
・DOAからOOAへの移行をしている筈の現場で、
　RDBの外部キー制約やらNULL制約の使用を禁止してる２大トップ・メーカとかｗ
・設計で、処理本体と、ホーア論理の事前条件を分離しちまってｗ
　挙句に、その事前条件をルールエンジンやらAssertion機構に任すわけでもなく、
　「事前条件をファーストクラスのオブジェクト」として扱う羽目になってる謎設計とかｗ
　

697 ：デフォルトの名無しさん：04/04/30 01:34

ホーアの事前条件、事後条件、不変条件って、
正常系の処理に対してアドホックな部分と見なせるから、
もしかするとアスペクトとして分離すればすっきりするかもね？！

ただしアスペクトの数が数百個とかなっちまうけどｗ

やっぱ、>>681 みたいな位置付けで処理するのが、現時点ではまっとうな道なんだろうなぁ～

698 ：デフォルトの名無しさん：04/04/30 22:50

>>965
ステレオタイプの決め付けでレスの内容を無視して
相手を罵倒するのはいただけないね。
原始人扱いするのは勝手だが、事実を書いただけ。

699 ：デフォルトの名無しさん：04/04/30 23:03

未来人を罵倒するのもいただけないね。

700 ：デフォルトの名無しさん：04/05/01 09:53

未来人て誰？

701 ：デフォルトの名無しさん：04/05/01 09:56

965さん、頑張って反論してくれ

702 ：　：04/05/01 11:23

アスペクト指向というのが、コードの集約を目指しているのに、
結果としては、コードの分散につながるという面は否定できない。

703 ：デフォルトの名無しさん：04/05/01 12:40

>>965まで続くのか、このスレ？ｗ

704 ：デフォルトの名無しさん：04/05/01 12:51

>>693
そうかもね。

ただ、漏れ様認識としては、
・データ構造すら集約せずに手続きだけに注目するＰＯＡは、類人猿、
・データ構造と手続きを認識してるものの、両者の対応付が面倒なＤＯＡは、中世の迷信深い人、
を見てる気分になるけどねｗ
やっぱ、データ構造と手続きを１セットにして、分析してなきゃ、現代人と呼べないのでわ？
第一、オブジェクトの識別にコストが掛かる、、、ってアンタ、
必要な識別作業をやらなきゃ手抜きだし、必要以上に識別作業に手間隙かけてたら、効率悪いのあたりまえ、
やっぱスキルと知性を持って、最重要なオブジェクトは最初に確実に押さえ、周辺部分は経験と直感で適当に済ませて、
後で補足・拡充するのが、ナウいヤングのハートにバッチグー、ですわよ

705 ：３桁の数を処理できない人：04/05/01 21:37

オブジェクトの識別？
俺は、クラスやアスペクトが表している概念や仕様を分散したコードから読み取る作業を言ったつもりだけど。

＞必要な識別作業をやらなきゃ手抜きだし、必要以上に識別作業に手間隙かけてたら、効率悪いのあたりまえ、
いや、そりゃ当たり前と言うか当たり前すぎて何も言ってないのと一緒では？

706 ：デフォルトの名無しさん：04/05/02 01:24

自分の発言すらくつがえしちまうような >>705 のお相手をする暇はありませんです。

707 ：デフォルトの名無しさん：04/05/02 11:18

>704
おまいはいいかげん適材適所って言葉を覚えろ。
OOが全てじゃないって

708 ：デフォルトの名無しさん：04/05/02 12:54

お怒りになったのならゴメンなちい(何故か低姿勢)。

漏れは、別にオブジェクト指向至上主義者ではなくて、
どっちかっつうと型システム至上主義者です。

「型」を、プログラムの表明の一種と捉えて、
究極的には「型」を詳細に定める事で、
プログラムの詳細を自動生成できる所まで持って逝こう、
などという２０世紀の夢を、未だに捨て切れずに居る人種です。

ですので、オブジェクト指向というのは、
その目標に至る１step、１ﾏｲﾙｽﾄｰﾝに過ぎず、
型システムの将来へ向かってさっさと先へ進むべきだと、
常々考えております。

それはさておき。

「オブジェクト指向が全てではない」とのお達しですが、
旧来手法では処理を細分化し過ぎて、簡単なプログラムを作るのに莫大な工数が掛かるにもかかわらず、
細分化の弊害で、本来一致してしかるべき仕様間に矛盾があったり、処理実装が二度手間、三度手間になって、
結果として品質もコストパフォーマンスもよろしくない結果になってしまうのは、
いかがなものか、と思います。
もし、システムをオブジェクト指向で適切に設計することで、
規模を縮小し、生産性を向上し、品質を向上することができるのであれば、
現実的に「オブジェクト指向がより適した解である」と言ってもよろしいのではないでしょうか。

709 ：３桁の数を処理できない人：04/05/02 14:47

なにも覆してませんが？
このネタに関係ない一般的過ぎる事いってもネタへの反論にもなってないよと書いただけ。

710 ：デフォルトの名無しさん：04/05/02 21:29

型もクラスもいらねえよ

ってのはおいといて、構造化手法くらい学んでから御託並べやがれ。
それにAOPスレに書く話でもないし。

711 ：デフォルトの名無しさん：04/05/02 22:11

>>710
構造化手法？何か見落としでもあったんかい？！

それはさておき、ＰＯＡ→ＤＯＡ→ＯＯ→ＡＯＰってな、系譜を語ることは、
このスレ的に意味あることだと思うけど（唯我独善、正統な継承者ﾓｰﾄﾞ

712 ：デフォルトの名無しさん：04/05/02 22:37

AOPがOOの後継とか言ってるのがもう駄目々々

713 ：　：04/05/02 23:57

たしかに現時点では、AOPって消え去ってもおかしくないよな。

714 ：デフォルトの名無しさん：04/05/03 05:22

>>712
ははは。しゃれのわからんｶﾞｷﾝﾁｮ発見。

>>713
連続ﾚｽ始めたらもうおしまいだな

715 ：デフォルトの名無しさん：04/05/03 05:26

しかし、なんか因縁付けてくる癖に、
問いかけてやっても何も答えない、
そんな無責任なｶﾞｷﾝﾁｮの相手をいちいちやってる
俺って、なんて心の広い人間なんだろう。

ﾊｯﾀﾘ知ったかぶりばっかしてると、皆に嫌われるよ。
自分の発言には責任を持て。自分の発言に何か質問されたら、
必ず何か答えろ。それが、おまえがまっとうな人間になるための第一歩だ。

716 ：デフォルトの名無しさん：04/05/03 06:00

>>709
　>>705って、妙にﾊｯﾀﾘかました発言(>>693)をする癖に、

　＞オブジェクトの識別？
　＞俺は、クラスやアスペクトが表している概念や仕様を
　＞分散したコードから読み取る作業を言ったつもりだけど。

　えらく地味～な仕事しかしてないのねｗ
　運用保守やってるＩＴ土方か。マジメに相手して損した。

717 ：　：04/05/03 06:49

>>715
２ちゃんねるにようこそ。

718 ：３桁の数を処理できない人：04/05/03 10:01

>>716
そういうくだらない差別的な見方で思考停止するのはどうだろね。
自分がやるかどうかは関係なく、システムのコストは保守コストが一番大きいというのは常識だと思うが。
保守でなくて開発だって、０から作るよりバージョンアップの開発のほうが圧倒的に多い。
現実のニーズを無視して、自分のオナーニこそが高貴思っていては子は生まれない。

719 ：デフォルトの名無しさん：04/05/03 10:16

>>708
悪いけど、その論法を使えば「オブジェクト指向」自体の批判も出来るよ。

・・・
オブジェクト指向では処理を細分化し過ぎて、簡単なプログラムを作るのに莫大な工数が掛かるにもかかわらず、
細分化の弊害で、本来一致してしかるべき仕様間に矛盾があったり、処理実装が二度手間、三度手間になって、
結果として品質もコストパフォーマンスもよろしくない結果になってしまうのは、
・・・
もし、システムを旧来の設計手法で適切に設計することで、
規模を縮小し、生産性を向上し、品質を向上することができるのであれば、
・・・

720 ：デフォルトの名無しさん：04/05/03 10:20

＞＞７１９基地外市ね

721 ：デフォルトの名無しさん：04/05/03 10:57

＞＞７１８
父ちゃんは日本一のドカタだ！

722 ：デフォルトの名無しさん：04/05/03 10:58

723 ：３桁の数を処理できない人：04/05/03 11:22

すまんが、問いかけ/質問、って、どれ？

724 ：デフォルトの名無しさん：04/05/03 12:46

------------------------------------------------------------
>>710
> 型もクラスもいらねえよ
>
> ってのはおいといて、構造化手法くらい学んでから御託並べやがれ。
> それにAOPスレに書く話でもないし。

[>>711]
構造化手法？何か見落としでもあったんかい？！

それはさておき、ＰＯＡ→ＤＯＡ→ＯＯ→ＡＯＰってな、系譜を語ることは、
このスレ的に意味あることだと思うけど（唯我独善、正統な継承者ﾓｰﾄﾞ

------------------------------------------------------------

725 ：３桁の数を処理できない人：04/05/03 13:13

ああ、そりゃ俺じゃねーや。
俺も、そのレスの言いたいことよくわからん。

726 ：デフォルトの名無しさん：04/05/03 14:42

|ヽ||´ ∀｀||＜にははっ！ぶいっ！

727 ：デフォルトの名無しさん：04/05/03 14:52

ヽ||´ ∀｀||.｡oO（知ってるがお前の態度が気に入らない）

728 ：デフォルトの名無しさん：04/05/03 16:20

莫迦が Structured Method つかうのと
まともなのが OO Method つかうのをくらべりゃ
そりゃ後者の方がよいだろうさ・・・
まともな Structured Method は別に悪くないし Structured あっての OO だし

729 ：　：04/05/03 16:56

730 ：デフォルトの名無しさん：04/05/03 17:05

すまんが、問いかけ/質問、って、どれ？

731 ：デフォルトの名無しさん：04/05/03 17:06

他人の脳内の事を気にしても仕方ないと思われ

732 ：デフォルトの名無しさん：04/05/03 17:35

|ヽ||´ ∀｀||＜ナポ、ナポ・・・ぶいっ！

733 ：デフォルトの名無しさん：04/05/03 20:27

長瀬さんのＡＯＰ本が出てたんで、あげ。
こうやって、本当の研究者でもなんでもない、
単なる勉強会講師、エバンジェリストみたいな連中がのさばってくのね、
と妙に納得。きっと彼は、MixJuiceベースで解説書書くようなアレはないんだろうなぁｗ

734 ：デフォルトの名無しさん：04/05/03 22:10

本当の研究者の仕事はもともとそんな本を書くことじゃないだろう。
普通の分業どおりと思うが、気に食わないならおまいさんが本出せば？
本当の研究者でもなく、いろいろ知ってるみたいだし、なんやら主張があるみたいだし、どうよ？

735 ：デフォルトの名無しさん：04/05/03 22:53

最近でたAspectJの本読んでるが、
もし導入したら、
システムがメンテ不能のぐちゃぐちゃになるような気がしてならない。

736 ：デフォルトの名無しさん：04/05/03 23:32

馬鹿と鋏は使いよう

737 ：　：04/05/04 00:28

>>735
現状では、GOTO文よりもタチが悪いかも

738 ：デフォルトの名無しさん：04/05/04 01:41

>>735-737のアフォはスルーしとくとして。(OOよりもAOPよりも、知ったか素人がこわひｗ)

>>734
ﾊｧ？
あんたの言う「本当の研究者」は、仮想上の脳内産物に過ぎない訳だが、
俺は具体的な「本当にAOPやってる研究者」が、一般向け解説書の監修位してもいいだろ、
って言ってるんだが。この違いがわかるかな？

例えば、別の方のAOPやってたH先生 (本郷近辺だっけ？)。
H先生の場合は、一般向け啓蒙書も執筆してるし、多少は関連のあるだろうデザパタ本の監修もやってる。

739 ：デフォルトの名無しさん：04/05/04 02:45

>>738
いちいち喧嘩腰の上、決めつけがひどいね。
ブルーバックスや新書、学生向けの本を書くのはｲｲが、
実践の現場向きの本を書くというのはそれとは随分いろいろ違うよ。
一般向けAOPの本が、デザパタみたいに「監修」で済む状況とは思わないがね。

知ったかも怖いが、おぼれて思考停止になるのははるかに痛いと思うな。

740 ：　：04/05/04 07:20

ていうか、>>738は、何を言いたいのかわからん。

やはり２ちゃんねるはこうでなければ(w

741 ：デフォルトの名無しさん：04/05/04 08:56

>>739
２ちゃんねる素人さんですか？
この板は、あなたのようなナイーヴな方には向いていないかもしれませんねｗ

それはともかく。
確かに、現場向けの本を書くのは大変そうですよね。
学生さんなら、
　・学習目的だから、それなりに高いハードルを設定できるけど、
現場向けとか言い出した日には、
　・おサルさんが間違って買って文句をつけないように、
　・あるいはロクに学習時間を割けない現場でも役立つように、
いろいろ工夫しなけりゃならんもんね、今時。
つか、上位5％位相手にして、あとは対象外にしとくのがよろしいでしょうね、最初は。
現場でいろいろ人材が育ってくれば、そのうち
　・現場でやり方広めてくれる人や、はたまた
　・原書類の要約本書いて俗説を流布してくれる人
も出てくる事でしょうね。

デザパタ本の場合は、監修ではなく監訳。
原書が出てから２年後(話の発端から10年後)なんで、個人的には遅過ぎな感じもしたけど、
結局その本あたりが発端になって、国内でデザパタへの注目が集まったのは、なかなかﾖｲと思た。
デザパタ本の内容、、、というとET++やらSmalltalkの例やら、あまりアップトゥーデートな内容とは言えず、
原書レベルでわかり易い本とは言えないけどｗ　むしろ POSAやアーキテクチャパターンの方が、実践的。
まぁ、Smalltalkあたりでフレームワーク～デザパタの存在を知りつつ、それを他人に伝え、広める手段に
困っていた俺にとっては、ありがたかったけどｗ

742 ：741：04/05/04 08:59

起きぬけでマジメに相手しちまったけど、
>>739
ていうか、>>739は、何を言いたいのかわからん。

>>740
アンタもナニを言いたいの？さっぱりわからん。

>>734
アンタの言う「本当の研究者」って誰？
まずそっからはっきりさせないと、>>734みたいな発言はハッタリ小僧のでまかせと区別がつかん罠

743 ：デフォルトの名無しさん：04/05/04 09:05

>>739
＞いちいち喧嘩腰の上、決めつけがひどいね。
＞ブルーバックスや新書、学生向けの本を書くのはｲｲが、
＞実践の現場向きの本を書くというのはそれとは随分いろいろ違うよ。
＞一般向けAOPの本が、デザパタみたいに「監修」で済む状況とは思わないがね。

大爆笑！
20年前ならいざしらず、今時、しかもコンピュータサイエンスでブルーバックス書く奴ぁ居ないっしょ。
物理でも計算機科学でも、その道の専門出版社が、「ブルーバックス」的入門書を10年も前から出してる事だしｗ
あと、監修だけで済ませたデザパタ本って、どの本の事だろう。。。ぜひ教えてくれ。見た覚えないなぁ、そんな本ｗ

744 ：デフォルトの名無しさん：04/05/04 09:21

>>743
何やら既視感のある文体ですが、コテハン辞めたんでしょうか？
それとも人違いかなw

745 ：デフォルトの名無しさん：04/05/04 09:23

>>744=キティﾀﾝの煽りはいいから、さあ。

>>734
アンタの言う「本当の研究者」って誰？
まずそっからはっきりさせないと、>>734みたいな発言はハッタリ小僧のでまかせと区別がつかん罠

746 ：デフォルトの名無しさん：04/05/04 13:41

しかし、なんか因縁付けてくる癖に、
問いかけてやっても何も答えない、
そんな無責任なｶﾞｷﾝﾁｮの相手をいちいちやってる
俺って、なんて心の広い人間なんだろう。

ﾊｯﾀﾘ知ったかぶりばっかしてると、皆に嫌われるよ。
自分の発言には責任を持て。
自分の発言に何か質問されたら、必ずきちんと回答しろ。
それが、おまえがまっとうな人間になるための第一歩だ。

747 ：デフォルトの名無しさん：04/05/04 14:32

その自作コピペがお気に入りみたいだね。
2chだからって始終煽らにゃいかん法はないと思うがね。レスする人間の問題でしょ。

研究者と書いたのは深い意味はないよ。単に研究そのものを生業としてしてる人。
理系でも文系でも、そういう人の一般向け本は実践書ではなくキョーヨー本になるのが道理で、
実践書をそうでない人が書くのは当たり前でしょうというのが>>739だけど、わかりにくかったかな。

748 ：デフォルトの名無しさん：04/05/04 14:41

>>747
一般論しか書けない時点で、アンタの負け。
＞アンタの言う「本当の研究者」って誰？
＞まずそっからはっきりさせないと、>>734みたいな発言はハッタリ小僧のでまかせと区別がつかん罠

負け厨はさっさとお逝きなさい

749 ：デフォルトの名無しさん：04/05/04 15:09

負けﾜﾗﾀ
議論なんて元からろくになされてないのに、いきなり勝ち宣言とは。
やっぱり、レスする人間の問題だね。きみの場合、
情報の量だけがアイデンティティで、自分の存在をこうやって人様に危害を加えることで確認して保ってるんだね。

750 ：デフォルトの名無しさん：04/05/04 15:24

>>749
理論はテンで駄目駄目だけど、煽りだけは得意、
人を誹謗中傷する事に生きがいを感じてるアンタにゃ、
言われたくねぇ～よｗ

751 ：デフォルトの名無しさん：04/05/04 15:29

>749は、書き込む前に必ずコレを嫁
　http://www.2ch.net/before.html

おかしな人には気をつけましょう

利用者が増えるに従って、おかしな人もそれなりに出没するようになって来ています。
おかしな人に関わるとなにかと面倒なことが起こる可能性があるので、注意しましょう。

おかしな人の判定基準

・「みんなの意見」「他の人もそう思ってる」など、自分の意見なのに他人もそう思ってると力説する人
　他人が自分とは違うという事実が受け入れられない人です。自分の意見が通らないとコピペや荒らしなど
　無茶をし始めるので見かけたら放置してください。

・根拠もなく、他人を卑下したり、差別したりする人、自分で自分を褒める人
　他人を卑下することで自分を慰めようとする人です。実生活で他人に褒めてもらう機会がないが
　プライドだけは高いとか、匿名の掲示板しか話し相手のいない人です。可哀想なので放置してください。

・自分の感情だけ書く人
　「～～がムカツク」とか自分の感情を掲示板に書くことに意味があると思っている人です。
　何がどのようにムカツクのか論理的に書いてあれば、他人が読んでも意味のある文章になりますが、
　そういった論理的思考の出来ない人です。もうちょっと賢くなるまでは放置してあげてください。

752 ：デフォルトの名無しさん：04/05/04 15:30

＞＞７４９って、いきなり第二項に抵触してるね。
　
　ｶﾜｲｿｳな人みたいだから放置してあげようよ・・・

753 ：デフォルトの名無しさん：04/05/04 15:37

偉いセンセが、監訳したデザパタ本は、知ってるよ。GoF本の事でしょ。
偉いセンセが、監修したデザパタ本情報、きぼーんぬ >>739

754 ：デフォルトの名無しさん：04/05/04 15:39

いきなり3連レスするとは。
そんなに勘に障った？普通の感想を述べただけが、それは悪かった。
でも、>>752を素で書いてるなら、きみは本物だよ。気をつけた方がいいよ。

755 ：デフォルトの名無しさん：04/05/04 15:39

4連レスだ。

756 ：デフォルトの名無しさん：04/05/04 15:55

精神病院通いのｶﾜｲｿｰな人(>>754-755)、ｷﾀｰ

マジもんの基地外と会えるとは、
ここは痛いインターネッツですね。

757 ：デフォルトの名無しさん：04/05/04 15:55

＞＞７３９
偉いセンセが、監訳したデザパタ本は、知ってるよ。GoF本の事でしょ。
偉いセンセが、監修したデザパタ本情報、きぼーんぬ >>739

758 ：デフォルトの名無しさん：04/05/04 15:59

>>739、>>749、>>754-755って、卑下されるだけの理由 (ハッタリでいい加減な事書き散らして、誤りを指摘されても反論できない)
があるから卑下されてるんだろ。そこらへん無視して、逆切れしてるから、嘲笑の対象となる・・・
ｶﾜｲｿｳな奴なんだ。ほっといてやれよ

759 ：デフォルトの名無しさん：04/05/04 16:01

「卑下」ってのは自ら謙遜するときの単語なので、他人について言及するときは使えません。

760 ：デフォルトの名無しさん：04/05/04 16:05

>>739、>>749、>>754-755って、軽蔑されるだけの理由
　　(ハッタリでいい加減な事書き散らして、誤りを指摘されても反論できない)
があるから軽蔑されてるんだろ。

そこらへん無視して、逆切れしてるから、嘲笑の対象となる・・・
ｶﾜｲｿｳな奴なんだ。

ほ　っ　と　い　て　や　れ　よ

761 ：デフォルトの名無しさん：04/05/04 16:13

>>759
俺に言われても、困る。ぴろゆきに直接言えよ

762 ：デフォルトの名無しさん：04/05/04 16:17

突いてはいけないところを突いてしまったか。悪かったな。
ひとりでこんなに連レス続けて、相当ヤバイんだな。
幾分かの余裕はあると思って突っ込んだんだが、まさかここまでとは。イ㌔。

763 ：デフォルトの名無しさん：04/05/04 16:22

ふ～ん、本筋の話題はからっきしなのに、

煽　り　は　大　好　　き　な　ん　だ　ね　、　キ　テ　ィ　く　ん

764 ：デフォルトの名無しさん：04/05/04 16:25

＞＞７３９
偉いセンセが、監訳したデザパタ本は、知ってるよ。GoF本の事でしょ。
偉いセンセが、監修したデザパタ本情報、きぼーんぬ >>739

あんたの痴性じゃ、レスできないんだろうが(ﾌﾟｯ

765 ：デフォルトの名無しさん：04/05/04 16:27

前から不思議なんだけど、
なんでプ板にはサイコが常駐してるんだろう？

いつレスしても、即レスが返ってくるからｺﾜﾋ。
鬱病スレとか脳科学スレとか誤魔化さず、あんた自身がサイコだって事、
いい加減認めたらどうなのさｗ

766 ：デフォルトの名無しさん：04/05/04 16:32

ﾌﾟ板ってどこ？

767 ：デフォルトの名無しさん：04/05/04 19:08

>766
ttp://sports6.2ch.net/wres/

>765
プ板に帰れ

768 ：　：04/05/04 19:46

いい感じに荒れてきたのぉ

769 ：デフォルトの名無しさん：04/05/05 01:34

GWもあと１日。

770 ：デフォルトの名無しさん：04/05/05 02:57

サイコーですかぁっ？！！

771 ：デフォルトの名無しさん：04/05/05 12:27

AspectC++はどうなったんでつか？

772 ：デフォルトの名無しさん：04/05/05 21:05

実務で使ってる奴挙手

773 ：デフォルトの名無しさん：04/05/06 14:41

ﾋﾟｸｯ

774 ：デフォルトの名無しさん：04/06/28 12:39

アスペクト指向をコネクションプーリングに利用するという話をよく聞くのですが、
具体例にどんなふうに利用するかなど解説したものはありますでしょうか？

775 ：デフォルトの名無しさん：04/07/19 13:14

今月のCマガ特集がアスペクト指向プログラミングでした。
つうか、それ見てここに来たんですが。

ちなみに、特集見ても何が便利なのかイマイチ分かりませんでした。

776 ：デフォルトの名無しさん：04/07/23 13:31

ｱｽﾍﾟってロギングとかの非本質的な用途以外に
ちゃんとした使い道って無いの？

777 ：デフォルトの名無しさん：04/07/23 14:12

777

778 ：デフォルトの名無しさん：04/07/23 17:14

複数OSへの対応の為に#ifdefの嵐になってる部分を分離するとか？

779 ：デフォルトの名無しさん：04/07/23 23:59

>>778
それも微妙な用途だなぁ。
なんというかオブジェクト指向が開発・プログラミングのスタイルを変えたように
アスペクト指向がそれらを劇的に変える。というようなものではないのかな。
OOPLの不便なところをプリプロセッサ的なツールを導入して緩和するって程度なのかな。

780 ：デフォルトの名無しさん：04/07/24 00:17

>>779
Dependency Injectionの実現方法として、つかえんかな。

781 ：デフォルトの名無しさん：04/07/24 01:44

「アスペクト指向における再利用のためのデザインパターン」でも
出版されないと良さが分からん。下手に使うと訳が分からなくなりそうだし。

オブジェクト指向の時は、カプセル化とか継承やポリモーフィズムも覚えても
あまりピンとこなかったけど、異種リストをみて初めてスゲーと思った。
アスペクト指向だとそういう例はないのかね。ログをとるだけじゃあちょっと。

782 ：デフォルトの名無しさん：04/07/24 01:45

Loom.net
http://www.dcl.hpi.uni-potsdam.de/RAPIER-LOOM/

アスペクト指向プログラミングを後押しする要因とは？
http://www.itmedia.co.jp/enterprise/0311/18/epic02.html

Microsoftの.NETプラットフォームのプログラマーは遅いスタートを切ったが、
怠けているわけではない。ウォルフガング・シュルト氏は、LOOM.NETと呼ばれ
るAOP実装に取り組むドイツのチームの一員だ。シュルト氏は、.NET陣営は
Javaコミュニティーの取り組みより2年遅れているものの、
AOPはMicrosoftのプラットフォームと親和性が高いと述べる。

LOOM.NETプロジェクトはMicrosoftから財政支援を得ており、
同プロジェクトの.NETプログラマーは、自分たちのコードを開発する際に、
バイナリの.NETアセンブラを用いることができる。このレベルでの作業により、
研究者の取り組みはC#でもVisual Basicでも動かすことができる。
Javaプログラマーには、このような贅沢はない。

ソフトウェア開発ベンダーのMabry SoftwareでCEOを務めるジェームス・シールド氏は、
「正直に言って、AOPはJava以外の場面で採用されたときに多くの可能性を持つものだ」と言う。
「このような考えがC#に加わったらどうなるのか、見てみたいものだ」とシールド氏は続ける。

783 ：デフォルトの名無しさん：04/07/24 08:45

>>781
コンパイラが対応しないとどうしようもないでしょ。
OOはCでも一定の恩恵は受けられたけど
# CでもOO可能と言いたいわけじゃないよ
AOは概念を既存のOOPLに取り込むのが難しいからね。
一般大衆はもうちょっとのんびり構えてていいんじゃないの。
このスレ見てても概念レベルでは十分普及してるとは言い難いし。

しかしほとんどコードが出てこないスレだなここ・・・

784 ：デフォルトの名無しさん：04/07/24 09:15

>>783
AspectJってやつじゃだめなのか？
ログをとる例ならソースを何度も見たぞ。
コンパイラが対応してるって事じゃん。

とりあえず異種リスト程度の話でいいんだが。

785 ：デフォルトの名無しさん：04/07/24 09:52

>>784
対応したコンパイラがあるとか無いとかってレベルじゃなくて
普段使ってる言語の最新バージョンがAOPの機能をサポートして
なおかつ付属のライブラリがAOベースに再構築でもされない限りは
メリットは理解できないよ。

>とりあえず異種リスト程度の話でいいんだが。
その程度の例すら現状は無い。
なぜならロギングに有効だと知識で知らされていて、「ロギングには有効」とコピペすることはできても
身近な開発においてどう適用できるかを自ら考えられてなおかつ噛み砕いて他人に例示できるほど
深く根源的に理解している人間はこのスレでも日本語のWEBでも存在しないから。

786 ：デフォルトの名無しさん：04/07/24 11:27

>>785
普段使ってる言語がサポートする必要なんて無いと思う。
異種リストを初めて見たのはObjectPascalだったが、俺は別にObjectPascal使いじゃない。
シンプルな例にライブラリなんて関係なかろ。
例えばAspectJなんてほとんど知らんが、それでもログをとる分には便利な事は分かった。
でも応用が利きそうな感じがしないんだよね、ログの例だと。

異種リスト程度の例すらないなら、そりゃハッタリだって言われても仕方ないな。
日本語に例がないのはいいとして、他の言語ならあるのか？なら誰かが訳して紹介くらいしてそうだが。

あれか、好意的に解釈すれば、オブジェクト指向で言うと90年代初頭な感じなのか？
「タイヤと車は継承関係にあります」とか無茶な文章が平然と雑誌に載ってるみたいな。
でもなあ、どれだけ潜在能力があるのか知らんが、その能力を顕在化できないなら意味無いな。

787 ：デフォルトの名無しさん：04/07/24 12:03

AspectJとかは動的にメソッドに機能追加できたり、あるクラスにフィールドを追加できたり
継承関係を変化させたりすることができるから
注意して使わないとわけわからんプログラムが出来上がる。
(アスペクトがカプセル化を破壊するとよくいわれる)

本コードの論理構造を損なわずに機能を追加できる例が、ロギングくらいしか
ないから、それが例に良く用いられる。

「指向」なんて大げさに考えずに便利だから使う程度の考えでよいとおもわれ

788 ：デフォルトの名無しさん：04/07/24 12:07

そんなこと言う前に、てめえはプログラム作ってるのか。バーか

789 ：デフォルトの名無しさん：04/07/24 13:08

雑誌でAspectJを見たときはなにやら既存のライブラリにパッチを当ててたが

790 ：デフォルトの名無しさん：04/07/24 14:11

>>785
>身近な開発においてどう適用できるかを自ら考えられてなおかつ噛み砕いて他人に例示できるほど
>深く根源的に理解している人間はこのスレでも日本語のWEBでも存在しないから。

このスレで現実的に理解してそうなのは >>548 っぽいな・・・
それに対して >>552 のようなレスが入ってしまうのが現状だろう。

791 ：デフォルトの名無しさん：04/07/24 16:28

「本質的」なサンプルが無いのはある意味当たり前なのかも。
というのも本質的なコードがいろんなクラスに横断的に偏在するなんて有り得ないから。
なぜなら(オブジェクト指向)設計はそういった本質的な機能を軸に
オブジェクトを分類していくわけだからね。これはAOPであっても変わらないはず。

人間の本質的要素は脳とﾁﾑﾎﾟであって血液では無いのと一緒ｗ

>>787
>「指向」なんて大げさに考えずに便利だから使う程度の考えでよいとおもわれ
AOPが「指向」の地位をキープできるのか、最終的には単なるリファクタリングの
一要素(の為の構文拡張)に成り下がるのかはよく分からないな。

792 ：デフォルトの名無しさん：04/07/24 17:51

>>791
>人間の本質的要素は脳とﾁﾑﾎﾟであって血液では無いのと一緒ｗ

人間の本質的要素は「魂」ですが、何か？

また、人によっては「免疫系・神経系」だという人もいるな。

793 ：デフォルトの名無しさん：04/07/24 23:55

このスレって非本質的な揚げ足取りばっかりやってるけどこれもアスペクト指向なんだろうか

794 ：デフォルトの名無しさん：04/07/25 02:22

>>787
アスペクト指向の神髄は後付での機能追加ではなく、
設計時にクラスとは別にアスペクトを抽出できる事ではないか？
機能追加に拘泥すると本質を見失うと思う。
つまり、アスペクトなしでは動かないプログラムが普通なのでは。
ロギングのように、アスペクトの有無にかかわらず動くのはむしろ異端かと。
だから、ロギングじゃなくて異種リストみたいな例を見せろとさっきから言ってる。

>>791
本質ではなく、クラスを横断して偏在する些事を抽出したものがアスペクトではないのか？

とか言ってる俺はCマガジンの特集をざっと立ち読みしただけだから、
壮大な勘違いをしている可能性もあるが。
いずれにせよ、アスペクト指向設計の話が出てこないうちはどうしようもないと思うな。
もう出てきてるんならそれを読みたい。

795 ：デフォルトの名無しさん：04/07/25 07:00

オブジェクト指向で設計してると委譲コードが多くなるでしょ。
でもアスペクト指向だとそのへんをアスペクトにしてやって見通しよくすることができる。
その意味では State/Strategy パターンや Decorator パターン、Visitor パターンなんかは
アスペクト指向のほうがすっきりかつより強力に書けるね。

796 ：デフォルトの名無しさん：04/07/25 08:29

サンプル無いの？

797 ：デフォルトの名無しさん：04/07/25 18:59

>>791 >>794
偏在：かたよって存在すること。（例：関心事が特定のクラスに「偏在」する）
遍在：どこにでも存在すること。（例：関心事がクラスを横断して「遍在」する）

>>794-796
>>344-346で同じような話をしており、サンプルがあるサイトも紹介されています。
過去ログを全部読むのが大変なら>>394のまとめだけでも読んでから
サンプルを読むとスゲーと思うかも知れません。

Aspect-Oriented Design Pattern Implementations
http://www.cs.ubc.ca/~jan/AODPs/

798 ：デフォルトの名無しさん：04/07/27 14:11

アスペクト指向自体は面白いね。
ただ、AspectJはちと強力すぎやしないか？
ロギングみたいにすべてのメソッドにコード挿入するような例は希だと思うな。
大体、ログ取るときだって手当たり次第に挿入しないだろう。
797のGoFの例だって、interfaceに実装を与えてる（Mix-In?）のがほとんどだし。

どうでもいいかもしらんが、StateとStrategyの例はいただけない。
アドバイスの中でクラスを判別するってのはなぁ……。
　　after(Queue queue, QueueEmpty qs, Object arg): ...
　　after(Queue queue, QueueNormal qs, Object arg): ...
てな感じでアドバイス自体を分けるんじゃ駄目なのかな？

799 ：デフォルトの名無しさん：04/08/01 18:54

なんかわざわざAspectJに言語変えてまでやってみたいとは思えないな。

800 ：デフォルトの名無しさん：04/08/02 18:58

既存の言語に導入する場合、Microsoft や gcc がやってるような、
勝手属性による言語の拡張とかが相性よさゲですよね。

801 ：デフォルトの名無しさん：04/08/07 00:55

横断とかどうこうよりも外からクラスをいじれるといった感覚なのはヤバいですか？

802 ：デフォルトの名無しさん：04/08/07 01:34

なんだかんだいっても、所詮はただのフック。
いまさら新しい名前付けて、なんだっつーのよ。

803 ：デフォルトの名無しさん：04/08/07 03:03

おもしろいとは思うんだが、>>799に同意だな俺は。

ログや認証だけでない、「おぉこれは！」という適用例はないものか。

804 ：デフォルトの名無しさん：04/08/13 21:15

http://www.csg.is.titech.ac.jp/~usui/bugdel/

これってどうよ？

805 ：デフォルトの名無しさん：04/08/13 21:16

sageたままだった・・・orz

806 ：デフォルトの名無しさん：04/08/14 00:27

Aspectによって振る舞いが変わるコードを書くのはAspect単体テスト
ができない今は危険。
だからAspectがなくても本質的な機能は動くという例でしか
現実に実装できない。

807 ：デフォルトの名無しさん：04/08/14 00:31

結局出来ることはログ・デバック・パッチの域を超えないのかorz

808 ：デフォルトの名無しさん：04/08/19 21:44

>>790
誰も誉めてくれないから自分で自分の事誉めてるカワイソウな>>548ハケーン！

なんでデバッガの例をそこまで持ち上げるの？
基地外か

809 ：デフォルトの名無しさん：04/08/20 02:14

いや、別に目的を達成するための手段として、便利に使うのは全く問題ない。
しかし、「指向」と名づけるところがなんか誇大広告っぽくて。

810 ：デフォルトの名無しさん：04/08/20 02:15

ループ話題ででageんなヴぉけ

811 ：デフォルトの名無しさん：04/08/23 11:38

>>548はむしろ逆に捉えるべきなんじゃないかと思う。
従来はデバッガのような特殊な実行環境でないと実現困難だったものも、
AOPだとコードとして書けるから柔軟になる、みたいに。

AspectJでは無理だけど、もっと動的にアスペクトを適用できると面白いかもな。
Decoratorパターンみたく任意に組み合わせしたり。
……すっげえ遅くなりそうだけどね（ｗ

812 ：デフォルトの名無しさん：04/09/01 21:12

それで、アスペクト自身のデバッグはできるのか？

813 ：デフォルトの名無しさん：04/09/01 22:46

デバッグが必要なほど複雑なコードはアスペクト外に部品化しろ

814 ：デフォルトの名無しさん：04/09/03 02:17

↑馬鹿発見

815 ：デフォルトの名無しさん：04/10/31 22:20:09

>> 811
JBoss AOP などのアプリケーションサーバの類が、一応 dynamic AOP ですよ。
多くのサーバが提供している AOP は、interceptor モデルを利用している
みたいです。

>> 812
アドバイス(advice)のデバッグ or テストはできそうですよね。だけど、
ポイントカット(pointcut)は難しいんじゃないですか？自分が意図しない
ジョインポイント(joinpoint)をポイントカットしてしまった場合に何とか
したいですよね。AJDT などがありますが、あくまで支援ですし。

816 ：R.M.S.：04/10/31 22:55:57

このスレの半分は千葉さんで出来ています.

817 ：デフォルトの名無しさん：04/11/01 03:19:58

ログ出力にはめちゃめちゃ便利そうなんだが
こんな感じだっけ。忘れかけてるが・・

public aspect LogAspect{
　pointcut log() : execution(* *.*(..)) && !execution(* LogAspect.*(..));
　around() : log() {
　　System.out.println("before:"+thisJoinPoint);
　　Object ret = proceed();
　　System.out.println("after:"+thisJoinPoint);
　　return ret;
　}
}

818 ：Linus：04/11/01 06:36:34

>>816
残り半分が一杉さんだったら素晴らしいのですが

819 ：デフォルトの名無しさん：04/11/02 00:02:35

>> 817
> execution(* *.*(..)) && !execution(* LogAspect.*(..))
あまり詳しく知らないのですが、execution pointcut は、
アドバイスの実行も指定できるのですか？

>> 818
なんでイキナリ一杉さん？
千葉さんと増原さんならともかく…

820 ：デフォルトの名無しさん：04/11/10 12:15:22

OOPは、ソースにあらわれない暗黙のコード実行を増やして、コードのレビューを難しくした。
それでもOOPには導入するメリットがあった。
AOPはどうだろう?

821 ：デフォルトの名無しさん：04/11/10 12:48:37

暗黙のコード実行って……C++とかJavaなんかより高級な言語は大抵背景に
言語の支援機構があるのでソースに表れないコードが実行されますが何か?
OOPの読みづらさはそんなことじゃなくてあちこち処理が飛ぶことで
把握を難しくしている点だろ。

822 ：デフォルトの名無しさん：04/11/10 22:27:53

ちゃんとしたドキュメントが揃ってれば読みやすいけど。
むしろちゃんとしたドキュメントを作る手法を考えた方がいいよ。
アスペクト指向はどうでもいい。

823 ：デフォルトの名無しさん：04/11/13 02:59:54

http://abc.comlab.ox.ac.uk/introduction
これからの AOP 言語は、abc で決まりだな！

824 ：デフォルトの名無しさん：04/11/14 22:16:52

これからはみな何研なのか明示してレスすること

825 ：デフォルトの名無しさん：04/11/14 22:23:59

おじさん指向にはもううんざりだよ、
COBOL全盛期の時代から構造化指向とかいってたけど、
結局未だにALGOLから派生したＣやPascal(Delphi)
は構造化指向を謳い文句にしていた割にアナーキーだしね

826 ：デフォルトの名無しさん：04/11/14 23:36:23

>825
Delphiは一応オブジェクト指向なんだけど……
もちろん、構造化指向でもあるけど、C++を挙げずにDelphiだけ挙げる
理由がわからん

827 ：デフォルトの名無しさん：04/11/16 00:24:51

> 825
おじさん指向ってなんですか？

828 ：デフォルトの名無しさん：04/11/16 00:31:57

"構造化指向" の検索結果のうち日本語のページ約 37 件
"オブジェクト指向" の検索結果のうち日本語のページ約 365,000 件
"アスペクト指向" の検索結果のうち日本語のページ約 13,300 件

829 ：デフォルトの名無しさん：04/11/16 03:03:33

> 828
何研？

830 ：デフォルトの名無しさん：04/11/16 07:27:49

今時、構造化指向って歳がバレるぞ(;´Д｀)

831 ：デフォルトの名無しさん：04/11/16 15:23:22

構造化指向なんて言葉は聞いたことないな。
構造化言語とか構造化プログラミングのほうがとおりがいい。

832 ：デフォルトの名無しさん：04/11/16 15:34:05

ダイクストラとかは知らずに
ただ構造化って言いたいだけなんちゃうかと

833 ：デフォルトの名無しさん：04/11/16 17:39:32

俺も聞いたことない。構造化手法じゃないのか？

834 ：デフォルトの名無しさん：04/11/16 20:28:11

構造化プログラミングの世間での認識＝ただgotoなくしただけ

835 ：デフォルトの名無しさん：04/11/16 22:32:09

>>828
今更だが、検索結果合計ってなんで「約」なんだ。ﾃｷﾄｰか。
ﾊﾟﾌｫｰﾏﾝｽ命で件数なんかどうでもいいのか。

836 ：デフォルトの名無しさん：04/11/17 01:05:27

約ってのはテンプレートでしょ
printfの書式文字列と同じ
つまり
printf("約 %d 件",件数);
深く考えてないよ

837 ：デフォルトの名無しさん：04/11/17 01:24:40

どうでもいいとは言わんが最初の10件なり20件なりを返すレスポンスタイムの
方を重視して設計するよ。
件数なんて一番どうでもいい情報だし。あ、やっぱりどうでもよかった。

838 ：デフォルトの名無しさん：04/11/17 13:19:48

検索アルゴリズム上、検索結果の件数は本来の検索対象ではないノイズを含むものになる。
実際に検索結果を一覧していくと、ノイズが取り除かれて件数が減るので
最初に表示される件数には"約"がつく。

839 ：デフォルトの名無しさん：04/11/18 01:04:40

検索結果のリストの冒頭以外は、ページを表示しているうちに変る可能性があるってことじゃないの？
最初のページの１０件なり１００件なりはあまり変らないだろうけど、
何万件もあるケースだとページを表示している間に検索結果が変ると
仮定するのはそんなにおかしい話ではないと思う。
で、>>836がFAってとこじゃない？

840 ：デフォルトの名無しさん：04/11/18 03:08:37

板違いでFA

841 ：デフォルトの名無しさん：04/11/18 16:56:33

アスペクト指向っていうのは大げさな気がする。
アスペクト化っていったほうがいい。

842 ：デフォルトの名無しさん：04/11/18 17:13:17

今のAspectJだと実装隠蔽が容易に破られると思うんだが、
多人数だと保守が難しくならないか？

843 ：デフォルトの名無しさん：04/11/18 17:28:19

言語仕様自体がアスペクトを意識したものにならないとだめやね・・・
weaveされる側が指定したpointcut以外には、
adviceを入れることが出来ないようにするとか。

844 ：デフォルトの名無しさん：04/11/18 18:07:21

>>841
普通の感覚だと、
「～指向」より「～化」の方が
より徹底していて、大げさな表現の
ような気がするけどな。

845 ：デフォルトの名無しさん：04/11/18 19:24:55

「アスペクト」自体の語が日本人にはキッツイと思う。
ぱっと見わけわからんもん。
「オブジェクト」なら一般人でも雰囲気伝わる。
この指向は名前付けに失敗した感じやね。

「フック指向」・・語感悪い。
フックプログラミングでいいか。
その他「アドバイス指向」
改名したれや（ｗ

846 ：デフォルトの名無しさん：04/11/18 20:07:05

>>842
デフォルトvirtualなメソッドになってしまうOOPLも似たような危険性があるよな。
virtualと同様の箇所にaspect指定しないとコードしこめないとかにすればいいのかも。

>>845
名前以前にJava以外の処理系よこせと。
指向って言うほど大げさだとは思わないけどな。
デザパタ導入したってデザパタ指向なんていわないわけで。
C#が採用するかどうかで普及の度合いが一気に変わって競う。

847 ：デフォルトの名無しさん：04/11/19 11:37:51

自分の物知らずを日本人一般に敷衍するバカが集うスレはここですか?

848 ：デフォルトの名無しさん：04/11/19 12:25:10

通り一遍の知識だけで批判するのは莫迦丸出し。
覚えて使ってみて経験してみていっぱしの文句言え。
頭の中だけでどうこう語っちゃうから莫迦院生扱いされるんだよ

849 ：デフォルトの名無しさん：04/11/21 01:28:17

アスペクトと聞いて何かわかる奴なんていねえと思うぜ（ｹﾞﾗ

850 ：デフォルトの名無しさん：04/11/21 18:17:37

自分の物知らずを日本人一般に敷衍するバカが集うスレはここのようです

851 ：デフォルトの名無しさん：04/11/21 20:47:04

世間一般で無名でもプログラマなら知っとこうぜ。
使う使わんは別として。

852 ：デフォルトの名無しさん：04/11/22 01:49:25

「アスペクト」というのは「明日、ぺ・クト」と読めるので、
なにかヨンさまに関係あることを言っているに違いない。

853 ：デフォルトの名無しさん：04/11/22 11:11:17

まだあったんだこのスレ

854 ：デフォルトの名無しさん：04/11/26 00:04:24

スレ違いの話題で荒れるのは、たいてい荒しの自作自演、だよな？

855 ：デフォルトの名無しさん：04/12/06 22:12:15

ExecutableUML本、発売日(2003/12/5)から一年積読状態にしてて、
ようやく目を通し始めたんだけど、なかなか面白い。

原書の当初のタイトル：「XP、AM、ほかのAAプロセスとともに、AOのテクニックをRIPのインスタンスとして用いた、MDAのためのExecutableUML」
第3章「ドメインとブリッジ」　ExecutableUMLで扱う各ドメインはただ一つのアスペクトを構成し、AOPと同様な方法で関連付けを図る

って^^;

856 ：デフォルトの名無しさん：04/12/06 22:18:16

あと、ユースケースからのドメイン識別がおもしろそうだなｗ

ちょっと前に読んだ「はじめての業務分析」は、
Catalysis流のコンポーネント・モデリング手法を業務モデリング (ビジネスモデリング)に使う、
というなかなかアレな切り口の本だったけど、あっちではユースケースをグループ化して、ドメイン＝コンポーネント
みたいな解釈してたっけ。

857 ：デフォルトの名無しさん：04/12/23 02:20:02

一杉さんはどうもアスペクト指向に飽きたっぽいな。

858 ：デフォルトの名無しさん：05/01/31 12:48:53

現状ではAspectJを使うのがいいのかな。
ということは、Spring FrameworkをEclispeで、て感じかな。
でも今度のプロジェクト、Weblogicだから
WebLogic Aspect Frameworkってのも気になるんだよな。。。

859 ：デフォルトの名無しさん：05/02/22 22:02:22

イベントドリブンとかをうまく扱えそうな気がするんだが、
なんか違うんだよな。ここに何かひとつ加えるだけで、
ほんとすごいものになるような感じなんだけど。

860 ：デフォルトの名無しさん：05/02/26 21:48:28

すでにjavacでコンパイルしてjarでアーカイブした app.jar に、アスペクトをかいたAspect.java を
ajc でコンパイルすることはできませぬか。やり方がようわからん……
javac でコンパイルした*.class は一応あるが…
AspectJは1.2です。

861 ：デフォルトの名無しさん：05/02/26 21:59:38

どうでもいいが千葉研の卒論発表はひどかったな

862 ：デフォルトの名無しさん：05/02/27 01:18:31

アスペクト指向ってつまり、オブジェクト単位のもう一個上に
アスペクト単位を持たせて横断処理毎に区切ってるってことなん？

863 ：デフォルトの名無しさん：05/03/04 18:24:42

まだ勉強仕立てなんだけどさ、pointcut の指定は、本当にこれでいいのか、と思う。

例えば、getter に対しての pointcut は call(* * *.get*()) だけども、
オブジェクトの状態を返す get* (Person.getName()) と、Singleton としての get*
(FooBar.getInstance()) は別に扱いたいかもしれない。

メソッドやクラスのシグネチャだけで pointcut を指定しても良いのだろうか。

864 ：デフォルトの名無しさん：05/03/05 01:25:42

>>863
AspectJ5からはアノテーションも対象になるぞ。

865 ：デフォルトの名無しさん：05/03/05 15:29:05

他人のライブラリに pointcut を指定したい時に、求めているアノテーションが無かったとしたらどうするの？

866 ：デフォルトの名無しさん：05/03/05 17:32:03

ライブラリにパッチ当てたいなら素直にメソッド名でやったほうがいいと思われ

867 ：デフォルトの名無しさん：05/03/12 22:27:03

斜め読みだが
#include <stdio.h>
setenv TERM vt100
で
printf()
が使えるようになるのはアスペクト指向でせうか？

868 ：デフォルトの名無しさん：05/03/13 00:09:59

高級言語は、物理層から階層的な実行環境で動いているので、
中間層の環境設定で、プログラムの動作を変えることはいくらでもできる。

こんなイメージ

プログラムコード
Ｊ２ＥＥフレームワーク　＜＝ＡＯＰ
ＪＡＶＡ　ＶＭ
ユーザープロセス、スレッド
ＯＳカーネル
機械語
ＣＰＵ

869 ：デフォルトの名無しさん：05/03/13 00:30:30

ＪＡＶＡでは多重継承を許さず、インターフェースを使う。
ある側面（アスペクト）をクラス定義に加えられるから
アスペクト指向でいいの？
http://cai.cs.shinshu-u.ac.jp/sugsi/Lecture/java/L4/04-04.html

例
//　Serializableインターフェースの定義。
　public interface Serializable {
　}

//　新しいクラスをSerializableにする。
public class MyOwnClass implements Serializable { // これだけでいい。
.....
.....
}

http://www.wakhok.ac.jp/~maruyama/summer98/node53.html

870 ：デフォルトの名無しさん：2005/03/23(水) 14:06:41

シリアル化可能って言う「関心事」が
陽に対象クラスのソースに含まれてて、
切り離しが出来ていない。
そういうのは普通はAOPとは言わないと思う。

871 ：デフォルトの名無しさん：2005/04/16(土) 20:58:53

実行環境で「陰」でやるのか？
「継承はカプセル化を破壊する」なんて言ってたな。
http://www.netgene.co.jp/java/docs/swest5pp.html

872 ：デフォルトの名無しさん：2005/04/16(土) 22:11:01

Java（5.0）のAnnotationとか
C#のattributeはAOPとは違うんですか
それも陽にクラスソースに含まれているのでダメかな

873 ：デフォルトの名無しさん：2005/04/16(土) 23:01:12

Annotation は明らかにAOPを包括した、
Java言語の外部拡張手段 (Cがプリプロセッサ込みで成立してるようなモン)

Attributeは、そもそも言語拡張手段が開発者に公開されてるの？！

874 ：デフォルトの名無しさん：2005/04/16(土) 23:38:24

「陽に」　明示的に　explicit
「陰に」　暗黙的に　implicit

875 ：デフォルトの名無しさん：2005/04/17(日) 00:00:20

>>873
＞Annotation は明らかにAOPを包括した、
＞Java言語の外部拡張手段 (Cがプリプロセッサ込みで成立してるようなモン)

Java Annotationsは、
C言語を宣言型言語として解釈する、というくらいの飛躍が、あると思うがｗ

876 ：デフォルトの名無しさん：2005/04/17(日) 09:43:44

そこでDIですよ。
http://suga.parfe.jp/tech/seasar2/DIContainer.html

877 ：デフォルトの名無しさん：2005/04/24(日) 02:29:25

DIじゃ力不足

878 ：デフォルトの名無しさん：2005/05/05(木) 00:15:15

もまいら、

　アスペクト指向分析設計の本
　　　Aspect-Oriented Analysis And Design: The Theme Approach
　　　http://www.amazon.co.jp/exec/obidos/ASIN/0321246748/

　ヤコブソンのﾕｰｽｹｰｽでAOSD本
　　　Aspect-Oriented Software Development With Use Cases
　　　http://www.amazon.co.jp/exec/obidos/ASIN/0321268881/

が出てだいぶ立ちましたが、
読み進みましたか？

879 ：デフォルトの名無しさん：2005/05/05(木) 00:17:03

おいらはまだ注文も済んでません

880 ：デフォルトの名無しさん：2005/05/05(木) 00:22:25

またそんなわけのわからん技術でおれを騙そうとしやがって！

アスポェクトだから何？
アスポえクトだからって、何がうれしいんだよ！
まずそれをはっきりさせてもいましょ

881 ：デフォルトの名無しさん：2005/05/05(木) 00:44:41

>>879
今注文した

882 ：デフォルトの名無しさん：2005/05/05(木) 00:45:07

これを導入するメリットは、特にないな

883 ：デフォルトの名無しさん：2005/05/05(木) 00:48:48

>>882
あと、原点を深く追求したい向きには、
こっちも面白いかも。

　http://www.amazon.co.jp/exec/obidos/ASIN/0262610744/

884 ：デフォルトの名無しさん：2005/05/05(木) 00:49:09

実は、俺もアスペクト指向は何がうれしいか分っていないタイプ。
横断的関心事（だっけ）を抽出できるって説明は多いけど、他のメリットは無いの？

885 ：デフォルトの名無しさん：2005/05/05(木) 00:53:40

>>884
さあ。自分で勉強したら？

>>883
某会社経営の人が
「Common Lispべったりだし、これを読んでMOPができるようになるわけでもない」
ってどっかに書いてた。

886 ：デフォルトの名無しさん：2005/05/05(木) 02:23:42

デバック(テスト)かパッチくらいしか積極的な使い道が見出せない

887 ：デフォルトの名無しさん：2005/05/05(木) 02:35:54

実際デバッグが楽になるかというと誰もわからない
パッチ？緊急時にしか出番がないだろう
誰も何が利点なのか説明できない＝ガラクタ

888 ：デフォルトの名無しさん：2005/05/05(木) 02:46:11

緊急時に使えたらそれでいいじゃん

889 ：デフォルトの名無しさん：2005/05/05(木) 02:46:43

>>886
もしかすると、積極的に使うものじゃないのかもね
呼び出しトレース出す時に、こんな方法もありますが何か？
と提案する程度かな。

ヘビ等の爬虫類が進化したら使いこなせたかもしれないが、
哺乳類から進化した我々ではアスペクトを有効に使いこなす事は、
どうやらできそうにないみたいだ。

890 ：デフォルトの名無しさん：2005/05/05(木) 02:48:14

>>888
緊急時に得体の知れない物を使う余地などない

891 ：デフォルトの名無しさん：2005/05/05(木) 02:59:25

横断的関心事とか言うからわけがわからなくなる
クラスの外からクラスの中にソースコードを差し込む仕組みと言ったほうがしっくりくる

892 ：デフォルトの名無しさん：2005/05/05(木) 03:09:41

ここにも頭の悪い粘着が来てるのか

893 ：デフォルトの名無しさん：2005/05/05(木) 03:21:18

↑↑↑アスペクト指向とは流行りもの↓↓↓

894 ：デフォルトの名無しさん：2005/05/05(木) 05:52:59

>>886-893　わざわざ深夜に連続投稿　乙。

895 ：884：2005/05/05(木) 09:35:36

>>885
勉強してみた。
面白いと思ったのは、別に全ての実装者がアスペクト設計を知る必要がないわけね。
言語仕様からフレームワークを強制する事で、ベテランとトーシロを分ける事ができて、
それが今の人海戦術開発にとても適合している、ということね。

しかし、永続オブジェクトをフローから抽出できる点が素晴らしい。
後付けでオブジェクトをポリシーの中に含めてしまった場合、適用範囲によってはテストが大変かなぁーと。
C#/VB.NETにも、そういう様な仕掛けが既にあることから流行廃りの問題じゃないな、と言う事は薄々感じている。

896 ：デフォルトの名無しさん：2005/05/05(木) 11:33:37

>> しかし、永続オブジェクトをフローから抽出できる点が素晴らしい。

どこから出てきた話ですか？

897 ：デフォルトの名無しさん：2005/05/05(木) 12:05:09

>>894
デバックとパッチ以外の使い道は？

898 ：デフォルトの名無しさん：2005/05/05(木) 12:34:46

上のほうにいっぱい書いてあるねぇ。

899 ：デフォルトの名無しさん：2005/05/05(木) 12:52:18

抜粋してくれ

900 ：デフォルトの名無しさん：2005/05/05(木) 14:14:14

さぁ。

901 ：デフォルトの名無しさん：2005/05/06(金) 02:04:29

ないのかよｗ

902 ：デフォルトの名無しさん：2005/05/06(金) 06:43:11

確かに上に書いてあるなぁ。

903 ：デフォルトの名無しさん：2005/05/06(金) 06:56:22

じゃあそれを抜粋してくれ

904 ：デフォルトの名無しさん：2005/05/06(金) 07:33:58

毎日がエブリディなオマエと違って
こっちは暇じゃねぇんだよ。
スレ１００万回読み直して、自分で抜粋しろ。

905 ：デフォルトの名無しさん：2005/05/06(金) 07:35:16

ほんとレベル低いな

906 ：デフォルトの名無しさん：2005/05/06(金) 12:20:10

やっぱりないんだなｗｗｗ

907 ：884：2005/05/07(土) 00:01:19

>>896
AspectCを弄っていて、俺が便利だと思ったからそう言う話をした。

概念の勉強するより、実際に触った方が学習早いなこれは。

908 ：デフォルトの名無しさん：2005/05/07(土) 00:16:02

もっと詳しく。
フロー、というのがよくわかりませんでした。

909 ：デフォルトの名無しさん：2005/05/07(土) 00:42:21

どうせ主張系の人だろ

910 ：884：2005/05/07(土) 02:51:08

>>908
いや、書いたままなんだけど。
永続オブジェクトと書いたけど、別に系統の違うオブジェクトをまたぐぐらいの寿命でも有効なんだけど。

フローと書いたのは、データに対する計算そのもの。
例えば、商品の原価計算とか。この場合の永続オブジェクトは、DBに格納するエンティティ。
商品のエンティティがそんなに多くなく規則性がある場合、エンティティのやりとりはアスペクトコードに
全て任せる事にすると、フローはエンティティを知らずに計算だけを行う事ができるよね。
そうするとアスペクトコードは商品のまとまりごとに異なる（もしくは同じ）エンティティを呼んで処理を行うだけになる。

このフローで扱うエンティティの制御を、オブジェクトの継承で実現しようとすると大変なのは分ると思う。
ただ、この例で言うと結局はマトリクス表とアスペクトコードのにらめっこになるし、商品オブジェクトが系統分けできていないと
商品オブジェクトに手を入れなくてはいけない。
アスペクト指向設計はオブジェクト指向設計がきちんと出来ていないとうまく機能しないという事を付け加えておく。

911 ：884：2005/05/07(土) 02:54:18

理解に間違いがあったら、指摘してねエロイ人。

912 ：デフォルトの名無しさん：2005/05/07(土) 04:56:40

概念と単語の結びつき方が、特殊に感じられます。
あなたのやっておられるのは、データと処理を分けて扱う
データ指向(DOA等)じゃありませんか？

もちろん、DOAへのAOの適用も大切だと存じますが。

913 ：デフォルトの名無しさん：2005/05/07(土) 05:09:10

単なる主張系と判定

914 ：デフォルトの名無しさん：2005/05/07(土) 07:29:40

おれのアスペクトどこ？

915 ：デフォルトの名無しさん：2005/05/07(土) 16:56:41

>>910
それのどこに横断的関心事という概念があるんだか不明。
使い方のレベルが結局シンタックスシュガーと大して代わらんではないか。
>>912にも同意。

916 ：884：2005/05/07(土) 20:42:24

>>912
確かにやっていることはデータ指向でした。アスペクト指向を変に理解していたのに今は反省している。
まあアスペクト指向言語の副産物ぐらいの考えでいきます。便利そうだし。

>>915
>それのどこに横断的関心事という概念があるんだか不明。
ロギング等と比べれば、横断の割合は少ないですけど、一応１クラスツリーをまたがる
横断を抽出している為、ぎりぎり「横断的関心事」と言えるんじゃないでしょうか？

>使い方のレベルが結局シンタックスシュガーと大して代わらんではないか。
正直スマンかった。

917 ：デフォルトの名無しさん：2005/05/08(日) 02:28:32

いくら思想を唱えたって使い道が無きゃ誰も使わないよ

918 ：デフォルトの名無しさん：2005/05/08(日) 05:37:42

じゃ、この概念はなかったということで。

終了ッ！

919 ：デフォルトの名無しさん：2005/05/08(日) 10:12:23

カワイソウなお人だな

わかんなきゃ、来なきゃいいのに(ｗ

920 ：デフォルトの名無しさん：2005/05/09(月) 16:48:38

どんなに崇高な思想でも使い勝手が悪ければ使われないのはSmalltalkが証明してる

921 ：デフォルトの名無しさん：2005/05/09(月) 17:05:29

8 名前：仕様書無しさん [sage] 投稿日： 2005/05/09(月) 05:23:28
今後、凝集度を議論するときには、
Separation of Concernsの考慮が必要になるだろう

922 ：デフォルトの名無しさん：2005/05/18(水) 23:32:06

age

923 ：デフォルトの名無しさん：2005/05/18(水) 23:33:49

ageしか書けない可哀想な人↑

924 ：デフォルトの名無しさん：2005/05/18(水) 23:36:51

sage

925 ：デフォルトの名無しさん：2005/05/18(水) 23:37:41

埋め

926 ：デフォルトの名無しさん：2005/05/18(水) 23:38:15

＃1000取り合戦
　　　　　　　　まもなくここは　乂1000取り合戦場乂　となります。

　　　＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ（:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　　　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　（　　　　）　　　（　　　　）　　　（　　　　）　　　）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　（　　　　）　　　（　　　　）　　　（　　　　）　　　（　　　　）

927 ：デフォルトの名無しさん：2005/05/18(水) 23:41:31

＝＝＝＝＝梅嵐禁止＝＝＝＝＝

928 ：デフォルトの名無しさん：2005/05/19(木) 13:51:28

ぬるぽ

929 ：デフォルトの名無しさん：2005/05/20(金) 13:33:02

このスレはなんなんだ
今日もネタもないのにageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　(⌒Y⌒Y⌒)　　　　三￣￣￣￣＼　　　　　　　ζ　　　　　　　　　　＿＿＿_
　　　　／＼＿＿／　　　　/　　＿＿＿＿|　　　／￣￣￣￣＼　　　　　　／　　　　　＼
　　　/　／　　　　＼　 /　　＞　　　　　|　　 /　　　　　　　　＼　　　／　　／￣⌒￣＼
　　 / ／　　,,,,,、　,,,,､ヽ; /　／　,,,,,、　,,,,､ヽ　/＼　　,,,,,、　,,,,､､=;　　　/　　／　,,,,,、　,,,,､ヽ
（⌒ /　ｰi"￣ﾌ‐!￣~~| |＿ｰi"￣ﾌ‐!￣~~| |||||||ーi"￣ﾌ‐!￣~~|　　｜　／i"￣ﾌ‐!￣~~|
（　 (6 　　`ー‐'､ ,ゝ--''|.|　(6　`ー‐'､ ,ゝ--''|(6---　`ー‐'､ ,ゝ--''|／⌒ (6　　`ー‐'､ ,ゝ--'|
（　｜　　　　/ "ii" ヽ　| |　　　　　/ "ii" ヽ| ｜　　　　/ "ii" ヽ　|（　　｜　　　/ "ii" ヽ　|
　　＼　　 ←―→ ）／　＼　　←―→ ）　　＼　　　←―→ ）／－　＼　　 ←―→ ）　
　　　　＼＿＿＿_／　　　　　＼＿＿_／　　　　 .＼＿＿＿_／　　　　＼＿＿＿／
　　　　＿＿＿＿　　　　　　　　　　　　　　　　　　＿＿＿＿_ 　　　 /＼　/＼
　　　／∵∴∵∴＼　　.／⌒゛~￣￣￣＼　　／＼＼＼＼＼　　／　￣　　＼
　　./∵∴∵∴∵∴＼ ./　＿＿＿＿|＼_＿＼/　　　＼＼＼＼＼／　　　　　　　　＼
　../∵∴／　,,,,,、　,,,,､ヽ|＿し／　,,,,,、　,,,,､､ /／　,,,,,、　,,,,､　ヽ＼　/　　　　,,,,,、　,,,,､ヽ=;
　｜∵/ｰi"￣ﾌ‐!￣~~| |∴ｰーi"￣ﾌ‐!￣~~|｜/ ーi"￣ﾌ‐!￣~~|｜ーーi"￣ﾌ‐!￣~~|
　..(6　　　`ー‐'､ ,ゝ--''| (6 　　 `ー‐'､ ,ゝ--''| 6　　　`ー‐'､ ,ゝ--''||　　　　`ー‐'○ゝ--''|
　..｜　　　　/ "ii" ヽ　|｜　　　　/ "ii" ヽ　 | ｜　　　　/ "ii" ヽ　|｜　　　　/ "ii" ヽ　|
　　＼　　 ←―→ ）／　＼　　←―→）／　＼　　 ←―→ ）／　|＼　　　←―→ ）／　
　　　　＼＿＿＿_／　　　　　＼＿＿／　　　　＼＿＿＿／　　　＼　＼＿＿＿／/

930 ：デフォルトの名無しさん：2005/05/21(土) 21:25:39

ぬるぽ

931 ：デフォルトの名無しさん：2005/05/24(火) 23:09:30

アスベスト指向

932 ：デフォルトの名無しさん：2005/05/26(木) 22:20:45

東工大が開発したAOPオープンソース・ソフト，日立ソフトがJava開発環境に採用
http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20050520/161263/

　東京工業大学がアスペクト指向(AOP)に基づいて開発したオープンソース・ソフトウエアを，日立ソフトウェアエンジニアリングが同社のSuperH向けJava開発環境の標準機能として採用した。
日本の大学が開発したオープンソース・ソフトウエアがそのまま実際の製品に採用されるケースは少なく，産学連携の一つの形態として注目を集めそうだ。

　東工大が開発したのは，Javaのデバッグを支援するソフトウエア「Bugdel」。東工大大学院情報理工学研究科の大学院生薄井義行氏と，助教授の千葉滋氏が開発した。
BugdelはJavaプログラムにデバッグのためのプログラムを埋め込むEclipseプラグイン。
アスペクト指向技術を利用し，デバッグ対象のプログラムとデバッグのためのプログラムを分離して記述することができ，これによりデバッグの効率を高めることが可能になる。
アスペクト指向とは，複数のオブジェクトが共通に利用する機能を，独立したモジュールとして実装できるようにするプログラミング技術。Bugdelは千葉助教授が開発したJavaバイトコード変換ツールJavassistを利用して開発されている。

　また，指定した箇所でプログラムの実行を一時停止するブレーク・ポイントの設定も可能。
通常，ブレーク・ポイントを設定するためには，そのためにコンパイルしたJava実行環境（JavaVM)を使用する必要があるが，実行速度の低下が発生し，本番と異なる挙動が発生する可能性がある。
Bugdelでは通常のJavaVMでブレーク・ポイントを設定できるため，本番に近い環境でデバッグが可能になるとともに，デバッグのための作業も削減できる。

933 ：デフォルトの名無しさん：2005/05/26(木) 22:21:09

　Bugdelを利用したのは，日立ソフトのSuperH向けJava実行環境「SuperJ Engine」のための開発環境。
SuperHは日立製作所が開発したRISCプロセサで，SuperJ Engineは，主に組み込みシステム向けのJava実行環境として数十社が利用している。
開発環境としてはEclipseを使用しており，2005年4月からBugdelを標準のプラグインとして正式採用した。

　日立ソフトは，ブレーク・ポイント機能など実際の開発現場で重要となる機能を要望としてまとめ，東工大の薄井氏らがこれを実装した。
日立ソフトは，開発環境マシンとターゲット・マシンとの通信など，Bugdelを利用するためのSuperJ Engine特有の部分などを開発した。

＜“AOP”関連＞
米BEAがEclipse Foundationに参加，JRockit対応プラグインを無償提供 (2005/02/23)
米JBoss，さまざまな開発環境を組み込めるミドルウエア「JEMS」を正式発表 (2004/12/14)
「趣味で開発したソフトが正式業務に」――電通国際がオープンソースJava APサーバーSeasar2の有償サポート (2004/10/28)
「目的は新しい技術を追うことではなく，実案件の課題解決」――Java軽量コンテナ「Seasar」開発者比嘉康雄氏 (2004/07/09)
【連載◎開発現場から時代を眺める by arton】第4回 (2004/05/25)
「大学から実社会で使われるオープンソースを」――東工大助教授／JBoss開発メンバー千葉滋氏 (2004/03/26)
日本発の「世界最先端」，オープンソース軽量コンテナに熱い視線――Seasar2説明会から (2004/04/13)
J2EEのキーパーソン，BEAのScott Dietzen氏，大いに語る (2004/03/23)

934 ：デフォルトの名無しさん：2005/05/26(木) 22:23:33

みんなやることやってるな～。
漏れは某SIer社内じゃどーにもならなくて、いろいろ手を打ったけど研究する場所の確保に失敗したですよ(ｹﾞﾗｹﾞﾗ

さ～てと、次の５年計画でも立てるか～

935 ：デフォルトの名無しさん：2005/05/27(金) 00:07:54

このスレ的には↓みたいなのはどうなのよ。
# http://www.programmers-paradise.com/web/template-system.html

> 今のところアスペクト指向を使ったテンプレートシステムは登場していない。
> だからこそ、今、その研究価値がある。

936 ：デフォルトの名無しさん：2005/05/27(金) 00:14:53

THX! 拝見しました

937 ：デフォルトの名無しさん：2005/05/27(金) 03:06:51

>935
……でも、アスペクト指向とからめるのはちょっとなぁ……HTML/XMLの要素を
横断する関心ごとはあるけれど、そもそもそれを処理するのがテンプレートシステムな
わけだし。

938 ：936：2005/05/27(金) 06:08:40

そっちの話ではないみたい。

939 ：デフォルトの名無しさん：2005/05/28(土) 01:30:36

何の話？

940 ：デフォルトの名無しさん：2005/05/28(土) 02:03:10

ＸＭＬ厨お断り

941 ：デフォルトの名無しさん：2005/06/02(木) 01:59:28

AspectJまたはAJDTの現在のバージョンはアノテーションに対してポイントカットできるのでしょうか？

942 ：デフォルトの名無しさん：2005/06/02(木) 02:09:22

>>941
Google

943 ：デフォルトの名無しさん：2005/06/02(木) 02:20:41

googleでいろいろ検索してみたのですができるとはっきり書いてあるサイトを見つけられなかったので質問してみたのですが・・・
どのようなキーワードで見つかったでしょうか？

944 ：デフォルトの名無しさん：2005/06/02(木) 02:35:54

>>943
http://www.google.co.jp/search?q=AspectJ+AJDT+annotation

http://eclipse.org/aspectj/aj5announce.html

これじゃ不満かね。

945 ：デフォルトの名無しさん：2005/06/02(木) 04:04:51

またお前かよ

946 ：デフォルトの名無しさん：2005/06/02(木) 04:09:57

誰でも知ってる次期仕様にGoogle返しの自作自演とは馬鹿だな

947 ：デフォルトの名無しさん：2005/06/02(木) 12:42:36

>>944
それってアノテーションでアスペクトを書いてるんですよね？
そうじゃなくて特定のアノテーションを持ってるメソッドなどに対してポイントカットできるかどうか知りたいのですが・・・

948 ：デフォルトの名無しさん：2005/06/07(火) 17:09:32

「殻と場」Encapsulator & Field
ttp://www.sra.co.jp/people/aoki/SmalltalkTextbookJ/textbook33.html

上のページを読んでたら、AOPで制約プログラミングや契約プログラミング
ができそうな気がしてきた。

949 ：デフォルトの名無しさん：2005/06/15(水) 00:32:19

ほれ
ttp://www-128.ibm.com/developerworks/java/library/j-aopwork3/

950 ：デフォルトの名無しさん：2005/08/04(木) 19:06:32

アスベストそっくりっていう話は未だ出てこなかったのかよ。

951 ：デフォルトの名無しさん：2005/08/04(木) 19:07:23

というわけで

　ア　ス　ベ　ス　ト　指　向

置いておきますね。

952 ：デフォルトの名無しさん：2005/08/04(木) 19:10:34

>>950
>>931

953 ：950==951：2005/08/04(木) 19:21:30

>>952
ただ950でage忘れて、単にageと書くのも気が引けたから951を書いてみただけ。

954 ：デフォルトの名無しさん：2005/08/04(木) 19:32:31

>>953
>>931

955 ：デフォルトの名無しさん：2005/08/05(金) 12:03:33

アスベスト指向

956 ：デフォルトの名無しさん：2005/08/05(金) 21:29:55

昔たくさん湧いた「ログ以外に使い道あるのかよ(ﾌﾟｹﾞﾗ」と煽る連中は
もうどっかに消えてしまったんでしょうか。

957 ：デフォルトの名無しさん：2005/08/05(金) 23:03:52

ではご期待に応えまして。

ログ以外に使い道あるのかよ(ﾌﾟｹﾞﾗ

958 ：デフォルトの名無しさん：2005/08/05(金) 23:10:54

アスベスト指向が？

959 ：デフォルトの名無しさん：2005/08/06(土) 03:41:36

必死に下らない事書いてスレ埋めてるのって、
やっぱ運用チームの人間なんだろうな。空気読めねぇみたいだし。

960 ：デフォルトの名無しさん：2005/08/06(土) 07:53:33

なに、その運用チームて

運用チームみたいな妄想をここでご披露してくれるお前は
はたして空気読めてるのかねえ

961 ：デフォルトの名無しさん：2005/08/06(土) 12:44:55

最近S2AOPをブラブラ触ってみてるんだけど、ログ用として見ても
正しいタイミングで詳細なメッセージを表示しようとすると、山ほど
インターセプターを書く事になるんだけど、こういうもんなのかな？
どうも上手く使いこなせないorz

ちなみに、Seasar2Wikiのサンプルプロジェクトに行けば、S2AOP
をログ以外の用途で利用してる例が見られる。

962 ：デフォルトの名無しさん：2005/08/06(土) 14:59:37

ログ・パッチ・デバッグ以外の目的で使われた例をみたことがない

963 ：デフォルトの名無しさん：2005/08/06(土) 18:22:43

後付けならなんとでも言えるからな。
永遠に追っかけやってりゃいーじゃん。

これが２ちゃんクオリティ

964 ：デフォルトの名無しさん：2005/08/06(土) 21:01:07

ログ・パッチ・デバッグ以外の目的で使われた例はまだですか？

965 ：デフォルトの名無しさん：2005/08/06(土) 21:04:08

>>963
ちなみにログ・デバッグ・パッチの話は後付けじゃないぞ(>>807)

966 ：デフォルトの名無しさん：2005/08/06(土) 21:09:49

Springの宣言的トランザクション管理はAOPで実現されてんだっけ？

967 ：デフォルトの名無しさん：2005/08/06(土) 21:56:37

キチガイの分際で埋め立てすんなよクズ