OOPの次はAOPだそうですね？

今度はAOP（アスペクト オリエンテッド プログラミング）だそうです。
OOPも、満足にやってないうちに、その次が出てきてしまいました。
われわれはどこへ向かっているのでしょうか？

www.aosd.net見てね

てゆうかお前らブビ坊が進んでないだけ>1

みんな、関数ライブラリじゃなくクラスライブラリ使ってるぞ。

>>3
ぷ。
クラスライブラリ使って、オブジェクト指向のつもりだって。

google検索。アスペクト オリエンテッドで出てきたのは「OOエンジニアの輪」の
眼鏡のおばちゃん。javaよりCが好きだと。

おばちゃんからの引用

”Java よりは C 言語のほうが好きですね。変形していくところとか、
アスペクトオリエンテッドなところとか。C 言語のほうがいいですね。
それに、Java は遅くていやです（笑）。でも、Java と UML がなかった
ら、日本のオブジェクト指向は影も形もなくなっていたかも知れませんよね。”

ふ〜ん

>>4
ＯＯ信者の平均レベルはその程度じゃんか　藁

新しいパラダイムを無視しつづければそのうち構造化に戻って
くるかも。歴史は繰り返すっていうし。

日経が取り上げてないから>>1はネタ。

次はＯＯＰ＋＋が出てきます。

>>9
藁。CACMに出てたんだけど。

>>11
投資情報に流さないと動かないよ−ん。

>>10
するとＣ＋＋＋＋が出てくるな。

Ｃ＋４
数字はトレンドバージョン

マ板の連中が多いようだな…

>>15
普通かけもちじゃないか？

次ぎはHOPです

>>17
ハゲオリエンテッド？

その次はHSPです

AOPも理解できないCOBOLERは逝って良し！

>3000部出たら「売れた」、1万部いったら「ベストセラー」ですよね。
>“OMT”と“GoF”が2万部で、酒匂さんの訳されたMeyerさんの「 オブジ
>ェクト指向入門 」(アスキー出版)が1万部だそうですよ、正確には知り
>ませんがそういう噂です。

専門書ってこんなに厳しいのか・・・。

ていうか、追いかけるのもう面倒くさいんだけど。それに日本の学者
は、新しいパラダイムとか考えてないの？輸入には熱心だけど。

>>21
3000部でいくら入るの？印税って1割？だと、300ｘ3000で30ﾏｿか。
2割でも60ﾏｿだから、どっちみち少ないね。

>>22
日本産は国内で無視されるかアメリカに因縁つけられて終わりだ

>>24
ルビ房発見！

意外にもTRONマニアかもよ？

それよりなによりやっぱＡＯＥだよ

>>27
ネットゲー板 逝け

日本語のサイト発見。アスペクト指向ね。

http://dolphin.c.u-tokyo.ac.jp/~kazu0/aspectj-primer/primer-fornewcomers/node1.html

解説してちょ>1

>>29
誰か、そのページを200字以内に要約して発表してくれ。

こっちのほうがよさげ?(←まだ読んでない)

http://www.race.u-tokyo.ac.jp/~yoshimi/AOP/index-j.html

〜〜　激しくアスペクト！！(ﾟДﾟ)　〜〜

SubjectOrientedってのも(何種か)あるみたい。

>>30
私の現状の理解だけど。OOPの短所は、クラスを横断するような
グローバルな動作や処理を局所化し、適切にドメイン単位の処理を
分離することが難しい。例えば、点や線、矩形などのグラフィクス
オブジェクトを考えてみると、これらをある特定の画像表示ハードウェア
で表示するための処理は、個々のクラスにそれぞれ埋め込むような
書き方に（OOの必然？）なってしまうか、または情報の隠蔽を無視する
ような汚い方法になってしまう（ようである）。
AOPは、このような短所を克服するための、複数のクラスを横断するような
処理を局所化する機能をOOPに追加するものである。

簡単に言えば、いわゆる業界人のよく使う言葉だが、クラス構造を
複数クラス横断的な”切り口”で見て、その切り口に対する処理を明示的に一個所
に書けるということだと思う。

で、どうかな。

>これらをある特定の画像表示ハードウェアで表示するための処理
アーキテクチャパターンのレイヤーパターンで終りでは。

ＡＯＰなんて、最下層で力仕事やってるＰＧに降りてくるのに、
確実に１０年以上かかります。
君らは、そのときに覚えればいいよ。

>>36
私はAOPの布教者ではありません。

基本的にはどのパラダイムを使っても、ある特定の仕様を満たすシステムは
作れますよね。AOPでは、特にソースコードの保守性や視認性、わかりやすさ
の向上をめざしているようです。

本体のコードに触らずにコンパイル時に取り付け取り外し
可能っていうのはイイ。Radみたいな環境を想定して、
機械的に生成されたコードを全く見なくても済むならイイんだが。

>>35
ほうほう。
だが、簡単に言われたところが、さっぱり分からん(ｳﾄｩ

Decoratorパターンをうまく実装できるって感じ？

29のURLにあるHello Worldのサンプルプログラム見るとちょこっと感じはつかめる
かと。

>>40
もっと簡単に言うならトリガー指定のグローバル関数が書けるってことだと。

>>41
Decoratorパターンて、デザインパターン関係ですか？勉強してないのでわかり
ません。

すまん、マジで聞きたいんだが、
例のHelloWorldのサンプルで、
HelloWorldを継承したクラスでprintouts()をオーバーライドして
その中からHelloWorldのprintouts()を呼び出した場合、
before(): printouts()やafter(): printouts()は、
いつ呼ばれるんだ？
継承したクラスのprintouts()呼び出しの前後にも呼び出されるのか？
それともその中から呼び出されたHelloWorldのprintouts()
の前後にだけ呼び出されるのか？

rubyもやってるみたいだな。

しっかし、日本の研究者は紹介ばっかりやってないで、
自分でなんかやれっつーの。
ただの翻訳機械かよ

で、自分でやると叩くっと。ﾒﾓﾒﾓ。

海外の連中も自分でなんかやる時には、
かなり攻撃とかされてるぞ。
C++なんかもその一つだ。

C++ はアレだからなぁ…

>>43
Aspectjを使ったことがないので推測しかできないですが、
スーパークラスのprintouts()の呼び出し前後が正解だと思います。
正確なジョインポイントでの起動が前提になっていると思いますね。
開発中にデバッグ用のトレースを入れて、リリース時にトレースを
はずすようなことが簡単にできそうです。aspectj開発者も、そういう
ところから導入してほしいと言っているようです。

>>45
おっしゃる通り。いわゆる禿同です。

>>49
どちらにせよ初期化処理と終了処理のような事には使えないというわけか。
トレースへの利用は確かにできそうだが他に使い道が思いつかん・・・。

２ちゃんで言語をつくろう！スレッド指向言語”--２”

>>1
>OOPも、満足にやってないうちに、その次が出てきてしまいました。

さしあたり、OOPの拡張と認識しておいて良いと思います。
そもそもOOPを駆逐するような性質のものでは全くないので、
やはり過渡期においては「いいとこ取り」が健全かと思われ。

通常のOOPLでは難しいリファクタリングの延長として
捉えてみるのも良いと思います。
とりあえず、メソッドの本質と関係の薄いコードを
コピペする様な状況を回避するには便利です。

あと、デザパタの実装としてAOPを採用するのは、個人的には
時期尚早と思います。(非常に小規模のチームであれば別ですが。)
AOPの利点としてDPが挙げられていますが、
当分は別々に考えて良いと思います。

# お節介ですが、AOPよりデザパタの方が業界的にも重要かと思われ、
# そちらを優先されてはいかがかと。。。

>>39
>機械的に生成されたコードを全く見なくても済むならイイんだが。

AspectJとJUnit併用している者ですが、
JUnitのメッセージはajc生成コードの方を参照しているので
ちょっと面倒になります。

>>43=>>50
細かいようですが、printouts()はpointcutなので、
「呼び出す」と言った類のものではありません。
1さんの言葉を借りると「トリガー指定」って感じです。(>>42参照)

おそらくprintouts()ではなくてprintMessage()と仰りたかったと思います。
そうだとしてお答しますが、オーバーライドしたprintMessage()においても、
before、afterの実行は一度ずつです。

# 念のため言っておくと、before、afterも勝手に実行されます。
# プログラマが「呼び出す」必要はありません
# HelloWorld派生クラスの各printMessage()実装に対して、
# ajcが自動的にbeforeとafterを実行するコードを付加してくれます。

>どちらにせよ初期化処理と終了処理のような事には使えないというわけか。

具体的にどのような処理なのかにもよりますが、
初期化/終了にも使えるのでは？

#ただし、AspectJの場合C++のデストラクタのような
#タイミングは無理ですけど。あたりまえですね。

>>53
JUnit使ってますか。結構使えるって聞いてるけど、実感としてどうですか？

>>52
デザパタですか。う〜ん、一人で隅でごりごり書いているような人間
にはどうなんですか？ま、とにかく私のの要求はシンプルで、ただ
１つ「楽したい」だけですね。だからつけはずしの出来るトレース
機能なんてすごく魅力あるんですね。

失礼しました。sageで進行中なのを失念してました。

デザパタは楽で楽しいＹＯ！>>56

クラスやメソッドを書くのは塗り絵の枠を書くみたいで精神的に楽。
インターフェースの変更も、中身の修正も閉じてるから楽。

このスレの最初で、クラスライブラリ使ってるってそれでOOのつもりかってのが
あったけれど、それでも最初の一歩としてはいいんじゃないですかね。

システム標準の、例えばStringクラスとかを使いこなしていけば、汎用性のある
良いクラスとは何を対象にどのように作れば良いか判ってくると思うのだ｡

C++の初心者が陥りがちな、関数を取り合えずメソッドにしてみました、
みたいなプログラムよりOOコンポーネントを使いこなした
構造化プログラミングレベルのコーディングの方が優れてると思うのだが。

>クラスライブラリ使ってるってそれでOOのつもりかってのが

これ書いたのは学生だから放置で良いＹＯ！
自分がその次（この場合オブジェクトベースOOP）を知ってることを誇示したいだけ。

>>59
>>4はただの煽り。メール欄をみてみそ。

アスペクトって何？

as・pect
n.　一側面，　様相；　光景；　顔つき；
【文法】　（動詞の）相；　方向，　向き；
【占星】　星位．

側面指向

うーん。あんまｶｺﾖｸﾅｲ

何か流行りそうにないな。
OOPを補完するだけみたいな感じだし。

オブジェクトはｶｺｲｲけど、アスペクトてアスベストみたいだもんＮＥ！
http://www.ag.wakwak.com/~hepafil/

日本人って舶来モンに弱いよな、２１世紀なのに未だに。

オブジェクト指向なんか、流行り始めた頃は
よく分かってもいないくせにマンセーな奴ばかりで、
ちょっとでも疑問を差し挟めば叩かれまくった。

ちゃんと実体が理解され始めてから今度は
継承に疑問を差し挟んだら叩かれまくった。
今じゃ継承ってあんまり使わん方がいいって感じだもんね。

>>54
before()でファイルを開いてafter()で閉じるなんてことはできないな。

>>58
そうなんですかぁ。ちらっとデザパタのスレ読みましたけど、なんか勉強量が多そう
ですね。E.Gammaって名前よく出てきますね。昔ACMのOOPSLAに一度行った時に講演
聞きました（ET++に関して）。スェーデンだかスイスだかフィンランドだかの寒い
とこの人ですね。ま、冷やかしで一回行ったきりなんですが、90年ごろか。長髪で
いい意味でのハッカーぽいかっこいい人でしたね。ヨーロッパ人はOOが好きですね。

>>55
>JUnit使ってますか。結構使えるって聞いてるけど、実感としてどうですか？

１年前にRMIと組み合わせてServlet用のユニット作って以来、愛用してます。
すごく良くできてます。っていうか、さすが美しいです。

ただし、大人数のプロジェクトに導入するのは慎重にした方が良いかも。
VB厨かき集めて頭数合わせたようなプロジェクトだったらお勧めしません。
最低限のOOPスキル持ってない人には、やっぱテストコード書くのも無理。
(もちろんレベル高いVB使いなら話は別ですが。)

あと人海戦術しか知らんCOBOLERくずれが実権握ってるプロジェクトでも
用心されたし。
「全てのメソッドに条件網羅でテストコード書け！」とか
言い出しかねないんで、ヤブ蛇が懸念されます。

まあ、お一人で組んでらっしゃるそうなので、杞憂ですね。
(うらやましい…)
ってことでお勧めです。
「楽」できますよ。

>>56
>>58さんが良い事言いました。
「楽」で、尚且つ「楽しい」です。（と私も思いました。）
GoFの本、読まれましたか？
ある程度OOPLでの開発経験があれば面白いですよ。
寝転んでヒマ潰しに読むくらいのスタンスでもそれなりに有益だと思います。
入り口の段階では、とりあえずOOA/OODの知識はそれほど必要ないです。
後になってリファクタリングなんかとの関連もだんだん分ってきます。
学習初期に陥りやすいのは、フレームワークとの混同などでしょうか。
スレ違いですね。この辺にしときます。

>>52で書いたことと逆になっちゃいますが、
お一人で組んでるのであれば、AOPLでデザパタを実装するのも
アリかと思います。
もちろん、ある程度融通の効く開発でなければ危険ですが。

まあ、備えあれば憂いなしってことでAO、DP共にお勧めします。

>>68
こんな寛治？
---------------- HelloWorld.java ----------------
package ajtest.helloworld2;
import java.io.*;

class HelloWorld {
　PrintWriter pw;
　void printMessage() {
　　pw.println("Hello world!");
　}
　public static void main(String[] args) {
　　new HelloWorld().printMessage();
　}
}

---------------- Trace.java ----------------
package ajtest.helloworld2;
import java.io.*;

aspect Trace {
　pointcut printouts(HelloWorld hw):
　　instanceof(hw) && receptions(void printMessage());

　before(HelloWorld hw): printouts(hw) {
　　try {
　　　hw.pw = new PrintWriter(new FileWriter("temp.txt"));
　　} catch (IOException ioExcp) {}
　}
　after(HelloWorld hw): printouts(hw) {
　　hw.pw.flush();
　　hw.pw.close();
　}
}

--------------------------------------------
血がってます？(だったらｽﾏｿ。)

>>72
そうそう、それで（Javaはあんまり詳しくないんだが）

class GoodbyWorld extends HelloWorod {
void printMessage() {
super.printMessage();
pw.println("Goodby world!"); //←こういうのには使えないって事？
　}
}

>>73
使えるっす。
この場合、"Hello…"の前後と"Goodby…"の前後で２回ずつ開閉します。
(無駄な気もしますが…)
さっき確認したので信用してね。

＞日本人って舶来モンに弱いよな、２１世紀なのに未だに。
コンピュータに関しては英語圏が中心だからしょうがないよ。
日本語で論文書いても日本人しか cite しない。
cite してもらうには IEEE や ISO/IEC などに英語で書かないとだめ。
理論を盛り上げるには多くの研究者を巻き込まないといけないので、
もっとも研究が盛んなアメリカでやらないと見向きもされない。
少なくとも向こうに共同研究者がいないと話にならない。

W3C に慶応大学の名があっても日本語のページはないし、
日本語の Technical Report 提出されないしねえ。
（「日本語」を「英語以外」に置き換えても可だね）

>>74
73の例の GoodbyWorld.printMessage() を呼び出した時

before(GoodbyWorld hw): printouts(hw) -> 開く
before(HelloWorld hw): printouts(hw) -> また開く？
HelloWorld.printMessage()
after(HelloWorld hw): printouts(hw) -> 閉じる
GoodbyWorld.printMessage() // これは可能？
after(GoodbyWorld hw): printouts(hw) -> また閉じる？

こうなるって事か？
カウンターを使って開いた回数を数えていれば問題なさそうだが、
すべての場合で使えるとは限らないような気がするなぁ・・・

>>29や>>32は、まだ読んでないけど
AOPはデザパタで言うところのVisitorパターン?

メッソド実行や参照ごとにイベントが発生してるのと同じようなイメージ？

>>76
トホホ。。。
テストしたときのmain()がご質問の趣旨と血がってた。
↓正しくはこう。

before　　　　　←ファイル開く
Hello world!　　←基底クラスのメソッド
Good-by world!　←派生で追加した分
after　　　　 　←ファイル閉じる

'super.printMessage();'
の前後のbefore/after実行はありません。無駄なく一度ずつ呼ばれます。
（詳しいことはajc生成ソースを見てね。暇な時にでも。）
低能技術者は俺です。
腹かっさばいて逝って来まーっす！

>>78
あとconstructorとかcatchまわりも指定できますね。(pointcut)
このpointcutごとの挙動を定義するのがadviceらしいです。

>>77
GoF本のVisitorパターンみると、「目的」の記述に
"クラスに変更を加えずに、新しいオペレーションを加える。"
という一文があるんで一見当てはまりそうだけど、違う気がする。

オペレーションの追加がありそうな部分を見抜いて、予め「仕掛け」を
作っておくのが多くのパターンに共通するやり方で、それらうち
二重に折り返した多態を使うのがVisitorパターンではないだろか…

少なくともこのスレで挙げられた例には、「仕掛け」も「多態」
も見あたらない。aspect側から一方的にロジックを追加している。

C#はAttribute?とかいうのを使ってAOPみたいなことができるそうですが、
どうなんでしょう？

>>82
名無しさん#さんがサンプル作ってるよ。
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1003826049&res=12
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1003826049&res=13

lispで自動化
仕組みを作のが面倒臭いが。

>>81
なるほど、目的は似てるけど実装方法がずいぶん違うようだ
Visitorは
1.オペレーションの追加を予測し、visitorを受け入れる仕掛けを
　前もって、用意しなければいけない
2.オペレーションが追加される側のオブジェクト構成が変化すると、
　visitorも変化させなければならない
という欠点があるからねぇ

>>83
面白かった。ありがとね。
AspectJと比べるとかなり面倒なソースだけど、
素のC#で使えるのは良いですね。
もしかして、この辺りからアスペクト指向も普及してくんですかね。

AO関連のパターンって、どっかで発表されてないかな？
AOのアナパタ、デザパタ、イディオムとか。
あと、AOの問題をOO的に解決するパターンとか。

>>86
聞きたいんだけど、AspectJってコンテキスト(JoinPoint)にこちらから
情報を追加することはできるのかな？WebでAPIリスト見た感じ、getterしか
ないからできなさそうなんだけど。

で、C#のContextAttributeでは、コンテキスト独自のプロパティを
管理できるんだよね。単に実行前後で呼び出されるってだけじゃなくてさ。
だからAspectJに比べるとコード量がぜんぜん違うんだと思うんだけど。

>>88
ContextAttributeは、本来Remotingで使うものよん。
AOPを意図した機能とは言いがたいかも。

処理の前後でインターセプションができるからこんなお遊びもできるよ、
という程度で作ったのが >>83 のサンプルね。

>>88
おっしゃる通り、JoinPointはread onlyです。
ただしJoinPointに相当するのはIMessageSinkだと思います。
コンテキストに近いのはどちらかと言うとaspectの方ではと思います。
(どちらにしても、少しこじ付け気味ですが。)

だとするとintroductionってのを使えば、ご要望の処理は可能です。

例えば>>83の例をもとにして言うと、DepositやWithdrawの
実行に通し番号をつけてBankAccountのインスタンス毎に管理するような
処理を、BankAccountの変更無しに追加できます。

>>89
C#って食わず嫌いだったけど、結構楽しそうだね。

>>89
あー、♯さん、やっぱり自分で書いてておわかりでなかったんですね。
Remotingで使うものですよ、もちろん。でもRemotingのRemoteっていうのは
Context外って意味なんですよ、.NET Frameworkでは。で、それは実は
.NET Framework new!ではなくて、MSはMTSのときにすでに実装しているんです。
ですから、コンテキスト属性は、AOPを意図したもの「です」。MSはCOM+の
ときから、Aspectって言葉使ってましたよ。
↑だからえらいなんて言いたいわけじゃないです。AOPを意識しているって
ことを説明したいだけ。

>>90
なるほどなるほど。AspectJ、なかなかやりますね。aspectj.org、もうちょっと
漁ってみよう。
ContextAttributeって書いちゃったからだめだったんですね。あそこは
コンテキスト属性って書けばよかった。

>>13
>>14
++をたてに並べるからC#なんだってさ。
++
音楽で少し高いって意味もあるらしいけど。

++を斜めに重ねて並べるってかんじだが
Visual C++のことを、出る前にC#と呼んでたのが懐かしい。

>>1
薄っぺらなトンデモ系っぽい本だが
Agent Oriented ProgrammingがOOPの次に来るとか
書いてあるやつを持ってる。
http://www.amazon.co.jp/exec/obidos/ASIN/4797305754/ref%3Db%5Fbr%5Fl%5F8%5F2/250-1168776-9396231

Aspectとはぜんぜん違って、AIとか遺伝的アルゴリズムとか
そっち系みたいな感じだったけどね。
個人的にはAspectの方に共感を覚えるかな。

>>93
詳細をｷﾎﾞﾝﾇ。

でも、Agent Oriented Programming も結構前からあるよね。

> AIとか遺伝的アルゴリズムとか

だったっけ？

>>94
エージェント指向はどちらかというとアーキテクチャレベルの話だからねえ。
自律的（って何？）なプログラムをエージェントと呼び、
人間に代わってエージェントプログラムが色々面倒な作業をやってくれるといいなあ、という感じ。

実装で有名なのはこれくらいかな。
plangent , beegent - 東芝
aglet - IBM

>>91
> でもRemotingのRemoteっていうのは
> Context外って意味なんですよ、.NET Frameworkでは。

それは知りませんでした。ありがとうございます。
マシン境界としか考えてなかった．．．。

漏れがふだん見ているMLでも、1年以上も前から議論になっていた．．．。(；´Д｀)

　http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=dotnet&F=&S=&P=9965

自律性とは「自分のことは自分でやる」ってこと。

この自律性を、三角形が自分自身を描画したり、台帳と伝票が
語り合ってしまう程まで過激に取り込んだのがオブジェクト指向。

…かな？

>>96
現在、Bee-gentダウンロード中。
plangentはキャラクターが可愛くないからダメだ。
agletは、なんか今alphaworksつながらないんで、また今度にする。

>>96
そんな事は関係無くトレンド転換するのがソフト業界。

↓こんなの見つけた。
http://www.fipa.org/

'The Foundation for Intelligent Physical Agents'
だってさ。エージェント界のOMGみたいなもんかな。

って、エージェント技術のスレってなかったっけ？

>>100
一言居士

OOP(ウープ)
AOP(？？？)

UMLのアスペクト指向拡張の論文見つけた。
再利用可能なアスペクトとか、
crosscutting concernsとAspectJ・HyperJをマップするやりかたとか。

ttp://www.dsg.cs.tcd.ie/~sclarke/ThemeUML/

>>94
どうも有り難うございます。エージェントに関する話題ってちょっと昔に流行って
ましたよね。最近あまり聞かなくなってたというか。この世界も結構流行とか
ありますからね。

とりあえず、私はaspectjを使ってみようと思っています。アスペクト指向はすぐに
広まりそうな感じします。

これ以上珍語増やさないでくれ！

アスペクト出版

アスベストかと思った。ゲホンゴホン。

AOPに関する論文はあるみたいだけど、
AOPのみで書籍化されたものってあるの？

あーこれいいな、C++でも織り込み用のプリコンパイラ作れば、
AOP風に組めるかも。作る･･か？
objectに対して、aspectをブチブチ差し込む辺りが気持ちよさそう。

ここにオブジェクトである　犬さんと　猫さんがいます。
犬さんと猫さんは、それぞれ独立している生き「物」です。

犬さんの中には猫さんを含んでいないし、
猫さんのなかにも犬さんは含んでいません。

また、犬さんはネコ科ではないし、猫さんもイヌ科ではありません。

しかし、犬さんと猫さんは仲良しで、
犬さんが１回鳴く毎に、猫さんは１回鳴きます。

一見、猫さんと犬さんはそれぞれ独立しているように見えますが、
何らかの関係も持っているようにみえます。

この状態をあらわす場合、適切であるのが、様相関係です。

※猫さんは状態によっては必ずしも鳴き返さなくても良いような場合も
あるかもしれません。

他言語の拡張としてのAOPLじゃなくて、
ピュア(?)なAOPLってあるの？

エサが足りなくなって共食いするのはどう？>>111
ないんじゃない？>>112

aspectjのサンプルのトレースaspectを試してみましたが、とてもいいですね。
jbuilderにaspectj IDE拡張を入れればビルドもらくらくだし。なんか、いままで
やりたくてもできなかったことが出来るという感じです。

クロスカットの方法もバリエーションが豊富で、クラス全体…そのクラスのメソッドコール
すべてとか一発でセットできますね。すごいです。ほんとお勧め。

>>109
javaプログラマーならaspectjのドキュメントを読めばよろしいかと。書籍はまだ
ないと思いますね。まだ、一般には認知されてないようです。
日経が取り上げるまではまだしばらくかかりそうです（藁

>>114=>>1
言語仕様も面白いけど、使い回しがいいのもポイントですよね。
ドキュメント類も分りやすいし。
ちなみにSOPのHyperJも持ってるけど、マニュアル読んだだけで
萎えちゃって、全然使ってません。

# JBuilderっすか・・・。いいっすね。
# 私の自宅でのJava開発環境はJDK＋秀丸＋DOS窓です。
# うらやましっす。

>>115
マニュアルはたしかにわかりやすく書いてありますね。だからすぐに使い始められる。
あとはJUnitを征服すれば、とりあえず今回の新技術導入は終わり。
jbuilderも今回新規導入したものです。私もいままではは、jdk+mule+DOS窓で
ぐりぐり書いてました。JAVA APIマニュアルを見ながらプログラム書くのは
もう疲れてしまいました。jbuilderいいです。もっと早く使えばよかったと反省しきり。

age

sageでも書き込むといい事ある？

dat落ちさけれるらしいです.
良スレage してもいい？

ネタ切れ？

ネタはあるがチョト準備中sage

このスレのこと忘れてた。本年も宜しくお願いします。

去年aspectjを使ってトレースクラスを入れてみましたがとてもいいとおもいま
した。今年はもっと本格的に使いたいと思っています。

どうでもいいけど、そろそろ折り返して
短くコードが書けるようにならんかね。

思い出したように age

OOPは「ウープ」と発音するそうですが、
AOPは「アオップ」ですか？それとも「アオープ」ですか？

>>35

>>32を見ると ,

>(例えば、オブジェクト指向プログラミングのような)モジュール型 のプログラミングでは、
:
>コンパイラの最適化の効果を無視 すれば、ソースにおいて連続するコードは、そのまま計算機上で連続し たコードとなります。
:
>アスペクト指向プ ログラミングを用いれ ば、ソースコードからコンパイルされたコードへの直接的 なマッピングという制約を受けなくなります。

となっていて 更に進んだモノに思えます .

ＭＯＰ＝マムコ指向ペニス

> OOPは「ウープ」と発音するそうですが、

はつみみです

http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/AOP.asp

さんくすです
これからよみます

>>129
アラン・ケイとかがでてるＣ＋＋の紹介ビデオで
確かに「ウープ」っていってたよ。

>>125
「ク-リトル-リトル」

まだ落ちてなかったのを幸いに維持カキコ

>>65
それはOOPも同じじゃん。
構造化プログラミングを補完するだけ。

維持させて

将来のために保守

EclipseにAspectJのプラグインが出るということで保守

様相指向ＯＳなんてのが出てる。
http://www.nexwave-solutions.com

ところで、汎用言語を無節操に拡張しても複雑になるだけなので、
実装ターゲット別に専用言語があったほうがよさげ。
待ち行列処理やマルチスレッド等のプログラミングが容易な電話交換機用のCHILL、
（HDLを知らないCプログラマにも馴染み易い）ハードのシステム設計用のSpecC
やASIC設計用のSystemC
各コンピュータメーカ社内には、一般公開されてない専用CPU用の専用言語がごろごろあるけど。

良ｽﾚageるだけではなんなんで、

うい。
http://www-6.ibm.com/jp/developerworks/java/020405/j_j-aspectj.html

>>139
どの辺に技術概説が書かれてるの？＜様相指向ＯＳ
ざっと眺めたけどふっつーの宣伝文句ばっかり。

Aspect Oriented Programming Using Aspectj
http://www.amazon.co.jp/exec/obidos/ASIN/0672324105/ref=sr_aps_d_1_1/249-7964749-6873932
こんなのがある。洋書ですね。ていうかまだ発売してないし。

JAVA WORLDでも特集あったし、いよいよブレイク？
マクロの無いJavaではトレース用に使うだけでも凄く便利になるので試す価値有り。

あげ

age

クラス同士の関連のコードをaspectにしておけば
お互いのクラスに連結用のコードが入らなくて綺麗。

すべてのクラスのログを取る場合の例を読んだけど、

Interface ILogger
{
public void writeLog(String log);
}

をすべてのクラスに付けるんじゃ駄目ですか？
もしくは

class Logger
{
public static void writeLog(String log);
}
をつくるとか。

あ、これがクラスを横断する処理？

>>147
それじゃログ書きたい所全部にwriteLog()をかかないと駄目だし。
やめたくなった時も大変。

Asplectを使えば既存のクラスの定義を変えずにログを差し込むことができる。

差し込むだけじゃなくて書き換えることや(Advice)
特定のクラスに定義自体を付け足すこと(Introduction)もok。
aspect自身が属性やメソッドをもつことができるし。
クラスの外からコードを操るって感じ。

>Asplectを使えば既存のクラスの定義を変えずにログを差し込むことができる。
でもやっぱりhowが抜けてるよね。
理想はあっても、実現手段がないんじゃどうしようもない。

ちなみにlog4jは知ってます？

>>149

あほ？AspectJ知ってる？

>>150
まあ、その程度で
>Asplectを使えば既存のクラスの定義を変えずにログを差し込むことができる。
これが実現できてると思ってるなら別にいいけど。

log4j使えば？

javaのライブラリーってたくさんあるけど
AOPで書き換えると便利、っていういい例ないですか？

便利かどうかなら、書き換えても同じでしょ。
素直に実装できるかどうかだと思われ。

ちょっと読んだ感じでは
マクロ、イベントハンドラを後付けできるようにしました
という印象を受けたが。

自分はマクロ嫌い派なのでいやかも。

>>149
実装にまだまだ問題があるらしいですね。
複数のAspectが干渉したときどうするのか?とか。

Aspectの代役にlog4jってAOPはログ用にしか使えないって暗喩ですか(w;
UNIXのコマンドプログラムにAOPを応用してあとから拡張できる
コマンドを作成って研究も見たことがありますし
もっと応用範囲は広いと思うのですが・・・

>>101
昔からあるよ。
「ほう、オブジェクト指向の次はエージェント指向か」っちゅう
能天気な人がまだたくさんいた頃から。

ちなみにエージェントスレはこっち
http://pc3.2ch.net/test/read.cgi/tech/1029316720/l50

なんか、考え方がサパーリ。
メソッド実行の前後になんかするってのは、便利そうだけど、
それってどんな「切り口」なの？
「切り口」の考え方がわかるようなほかの例、激しくきぼん。


ちなみにこんなのもあるけど、関係あんのかな？
http://www.etl.go.jp/~epp/jp/mj/

>>157
日経エレクトロニクス 2002/7/1号(No.825) P32
「OSと階層構造は使わない　ソフト開発の新手法が登場」
って記事に、アスペクト指向プログラムの事例があるよ。

DVDプレーヤにJPEGビューアを動的に組み込むっていう事例。
いわゆる「プラグイン」そのものなんだけど、ファーム全書換とか
じゃなくて、

１．JPEGビューアモジュールをDVDプレーヤ内部に追加
　　↓
２．JPEG画像閲覧時にビューアモジュールが呼び出される
　　↓
３．ビューアモジュール起動前に「ディペンデンシ・マネージャ」
と呼ばれるモジュールが起動して、ビューアモジュールの動作に
必要なハードウェア制御モジュールとのプロセス間通信に必要な
情報を提供
　　↓
４．ビューアモジュールがハードウェア制御モジュールを呼び出し、
JPEG画像展開・表示

とすることで、開発や保守の効率を上げているそうだ。
興味があればバックナンバーを読まれたし。

>>158
なんか、OPEN-R（AIBOのアプリケーション層）みたいだな。

サンクス。
しかし、切り口ってのはなんなのか、まだピンと来ず。
みんな判ってる？

>>158

ビューアがディペンデンシ・マネージャに必要な機器を要求。
（もしくはディペンデンシ・マネージャがビューアに問い合わせ。）
ディペンデンシ・マネージャがビューアに機器ををラッピングしたクラスのインスタンスを渡す。
ビューアはそれを使って機器を制御。

ビューアは同じインターフェースのディペンデンシ・マネージャがあれば他機種にも流用可能。

デザインパターンのビルダーだかファクトリーだかって感じ？
まだOOばっかな俺・・・。

ちゃんと理解してないけど、なんか汚いと言うか、
もう一皮むけて洗練されて言語に練りこまれないといけない気がする。
スコープとか、ＯＯとの整合とか。それに、
メソッドの前後だけ（と思ってる）っちゅうのは
いかにも取って付けたって感じ。
もっとシステマティックな理論の整備がほしい。

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

これって、オブジェクト指向に対する話じゃなくて、
構造化に対する話じゃないのか？

オブジェクト指向でも
template method パターンや decorator パターンには
素直に適用できますね。

>>164
オブジェクト指向とは直行する概念。確かAspectC(非oo)ってあったような。
うーん行番号時代のコードにも一応weaveできそうだから構造化にも直行するかも。

こんなのもあったね。まあココまでするかなぁって気もしたけど（ｗ
http://www-6.ibm.com/jp/developerworks/java/020719/j_j-aspectj2.html

英語質問で質問できるか！萎え＞＞都内某所

age

書くべき事も持たずにageないように(笑

AOPについて勉強すれ、と言われたので色々見てました。
AspectJはなんか便利そうだったけど、OOPの拡張って
感じでいまいちAOPの概念がつかめません。
他にAspect Orientedな言語の実装とかはないんでしょうか？

OOP と AOP は直行している概念だぞ。。。

けどC言語とかLispでのAOPとか見ると
OOでないAOPはできる感じがした。
AOPはOOPの延長上にあるわけじゃなくて、
全く別のパラダイムじゃないの？

直行直行って、本当は直交じゃないのかと問いたい。

「アスペクト」という概念がようわからん。
どっかいいサイトない？　…できれば日本語で（ﾖﾜ

アスペクトage

なんかくだらねーな。AOP とか言ってる間にさえずらず何かプログラム作れや。

>>177
そうだな。
ＯＳとか、コンパイラとか、
構造化プログラミングとか、オブジェクト指向とか言ってる間に
みんななにかプログラム作ってれば良かったな。機械語で。
そうすれば楽しい世界になってただろう（ｗ

アナル・おまんこ・プレイを推奨する

>>177 はカイジ厨。

アスペクト指向に向いていることっていうのは、つまり、
オブジェクト間のやりとりがやたら多い場合に便利、ってことでよろしいか。

MT:G や遊戯王をゲーム化しようってときに便利な気がする。
あるカードの効果を起動しようとしたら、割り込むカードがまたいくつかあって
カードの起動が終った後も、割り込むカードがいくつかある。（その組み合わせで
またいろんな割り込みが続く）

EventListener を沢山使えばいいんだろうけど、アスペクト指向プログラミング
やってりゃさらにスッキリ書ける。


という認識でいい？

>>181
詳しい説明ｷﾎﾞﾝﾇ。

>>181
あー、それはいいかも。
ログ取る以外のまっとうな使い方だね。

>>181
どういうの？
わかるようで、いまいちイメージが沸かない。
(カード)ゲームだけに使える話？

>EventListener を沢山使えばいいんだろうけど、ア
ヤヴァイよ。
OO最初からやり直して

AOPはアプリケーション間の連携に影響が出そうな気がする。

183>>184

例えば普通のシミュレーションゲームを想定して、
・攻撃可能対象を検索
・目標設定
・命中率計算
・命中したならダメージ計算
みたいなフローがあるとしようさ。
で、命中率に修正があるようなカードが存在する場合、
命中率計算の前に命中率修正メソッドを割り込ませる、
というふうに使えるのではないかと。
フローが複雑にならないと手間のオーバーヘッドが大きくなってしまいそうかな?

>>185
ＯＯによる解があったとしても、より優れた別の方法論があるのなら、
ＯＯでの解に拘泥する必要はない。
そして、ここはその　より優れた(希望的観測)別の方法論　を語るスレだ。

なんか、理系板の人混じってますけどｰ。
AspectJの親玉のアメリカンジョーク聞かしてやりたかったな。

>>189
聞かせて

>>187
説明サンクス。
なんとなく適用箇所がわかってきたような気がする。
けどそれをスマートにやるにはAspectJとかじゃあ無理だよなぁ。

>>191
無理なの？
てきとーにメソッド切ってやりゃ簡単にできそうな気がするが。

普通にメソッド単位でやってちゃあ
AOじゃないような気がする・・・ってのは違うの？

複数の命中率修正が発動してると、
修正順序とかコントロールする必要あるよね？
あるいは片方が無効になったり。
どうやるの？

あ、193宛てではないです。

>>193
ああ、OO の持ってる構造で引っかけるだけじゃ AO じゃないってことか。
確かに純粋な AO からすると、AspectJ は貧弱らしい。
でも実用的なツールとして使うには十分でしょ。

>>194

そういうプログラム作ったことあるけど、普通にコールバックのためのインターフェース作ってやっても割とすっきり作れた。

interface BattleListener extends EventListener {
..public BattleEvent invokeBefore( BattleEvent e);
..public void invokeAfter( BattleEvent e);
}

みたいなのを作れば、イイんでないの。

（>>194のいう重複、例えば、魔法を食らって「マホカンタ」「マホキテ」どっちを優先するかは、それはそのオブジェクトに優先度の値を持たせて実装すると思う）

>>181 の場合であったとしても、まだ AOP を持ち出すシーンではないような気がする。
AOP で実装するとこんなにスッキリするよ！　という実装例は出るかどうかは疑問。
イベントリスナ機構でもコード量は同じくらいなんでないか。
（俺は全く AOP 経験はないが、多分そう。実装例があれば見たい）

AOP が有効なシーンは、ちょっとOOPと離れたところで、限定的にのみ使えるという程度で、あまり大きなパラダイムに成長するかというと、そうは思わない。
特殊機能の一つみたいな感じでないか。

「マホキテ」って魔法食らってから発動するもんなのか。
じゃあ例としては適さないな。

（ドラクエやってねーのがバレバレだぁ）

メソッドの前後なにかするだけじゃ、限界がありまくりだよな。
ただのフックだし。もっと強力なweavingはないんか。

Ruby はゴリンゴリンにクラスの再定義できるから、それはアスペクト指向的かなと思った。

>>189
早く聞かせろYO!

>OOPの次はAOPだそうですね？

いえHTTPです。

>>200
Rubyがわからん漏れに説明してくれ。

>>199
＞ただのフックだし。もっと強力なweavingはないんか。

手放しで賛美するつもりは無いんだけど、ただのフックと捉えてしまうと
本質を見過ごすことになると思われ。
フックの機構をフックされる側のコードと切り離して合理的に一括管理
できるってのは、いくつかある利点の中でもわかり易い部類だと思うんだが。

>>204
漏れは>>199じゃないけど、AspectJの実装を見てると、
「これってAOPなのかなぁ？」
と思ってしまう。
ただスマートにフックできるだけ、って感じがいなめない。

AOPか？という観点を考えなければ大変いいと思うけど。

>>205
＞ただスマートにフックできるだけ、って感じがいなめない。

例えばC言語とC++があったとして、C++のメソッドのオーバーライドに
ついて「ただの関数ポインタのテーブルじゃん？」って言うのは不毛な
見方だと思うわけ。join pointsとadviceを指して単なるフックって
言うのはそれに近いんじゃないかと。

もう少し言うと、AspectJのフック技法って
・あるアスペクトに属する事柄はまとめて記述する。
・別のアスペクトに属する事柄は別々に記述する。
というようなコンセプトの中で使用されて意味があるわけで、そうでない
場合はむしろ明示的な呼び出しとかTemplateMethodパターンとか既存の
フック技法を使った方が良い場合もあるはず。
（そういう意味で、>>187のような使い方は違う気がする。）

＞AOPか？という観点を考えなければ大変いいと思うけど。

上で書いたように漏れの考えは逆。
単なる構文糖として導入したところで、かえってスパゲティ化が促進される
気がする。あくまでもアスペクト指向の実装技術のひとつであることを意識
しないと利便性よりリスクの方が大きいと思う。

AOPでxUnitが変化するのではないか？　　とsageでこっそり言ってみる。

>>207
CactusはすでにAspectJ導入してるね。
とsageでこっそ(略

>>208
これって、Cactusのソースで使われてるだけ？

>>209
LogAspectとLogManagerAspectってのがあって内部的に使ってる
だけですね。少し物足りない使い方ですが。

結局ログかよ！

なんか書き込め。

結局、簡単な実装例が出てこないあたりで
AOPってだめなんじゃない？

ログのようなケースでしか役に立たないなら、
フレームワークを一つ用意すればいいだけ。
log4jのようにね。
結局プログラミングスタイルとしては成立しないんだよ。

クロスカットの単位がメソッドの前後だけってのが、
パワーを激減させてるんじゃない？
もっとメソッドの中身にも溶け込むようなweavingができれば、
一気に強力になっていろいろできそう。
ついでに、一気にデバッグも大変になりそうだけど。

元論文の、画像処理の方に味噌がありそうなヨカーン．
でも読むのメンドイから、誰か翻訳か解説してちょ。マジで。

劇的な変化はハードウェアとともに

Lispしかり
Smalltalkしかり

Knuthしかり
Dijkstraしかり

>>216
KnuthとDijkstraは、どう言う意味？
つか、単に、昔はマシンが遅かったってだけじゃないの？

>>215
元論文ってなに？
Web上で見られるんだったら要約するから教えれ。

よろ！

論文
http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-ECOOP97/for-web.pdf

関連ページ
http://www.race.u-tokyo.ac.jp/~yoshimi/AOP/index-j.html

ここも面白いよ。AspectJ以外にもAOP関係はいっぱいある。
ttp://staff.aist.go.jp/y-ichisugi/ja/mj/soc.html

「AspectJ以外にも」っつーか、ＡＯＰ以外にも
似たようなのがいろいろあるみたいね．

>しかし、一般には複数のクラスを横断する形で関連するコードを記述せざるを得ない場合もあります。つまり、現在のオブジェクト指向言語では、 separation of concerns が「できない場合もある」のです。
できない場合が具体的に何なのかを示せれば、
（問題の解決方法が妥当かどうかも重要）
Aspect指向も日の目を見るかもしれないね。

いろいろ、文句を書いてきたけど
AOPを知る努力もしてるんで、AOP研究者の人は
もっと世間に研究成果を公表して欲しい。

>>222
>>219の論文にある例は？

>>223
あの具体例だと意味がわからないんだけど、
もしよければ有効性をわかりやすく書いてもらえるかな？

>>222
＞できない場合が具体的に何なのかを示せれば、

上の方にあるレスでフレームワークがあるとAOPLはいらなくなる
事を示そうとしてLog4jが引き合いに出されていたけど、それって逆。

Log4j使ってそれを更にcommons-loggingで抽象化しても
ログ処理の起点となるコードが呼び出し側に残るじゃん。
tangiling in the codeの一番わかりやすい例だと思うんだけど、どう？
Log4jでもできないからAOPを使ってるわけ。

>>225
確かに具体例としては判りやすいけど、
ログ以外に一般的に何かないかと。一般的に。
ログだと、縺れは縺れでも大して困らない気が。

>>226
いや、知った風なこと書いてはみたけど情けないことに
俺も良い使い道が思いつかないんよ。

>>227
良い使い道というか、すなわち、良いアスペクトがね。
「ほら、こんなアスペクトを分離したら、コードがこんなにスッキリ！」
みたいな例がたくさんほしいよね。
というわけで、>>218に期待。

メインのコードでは他のアスペクトを意識しなくて良い、
ってのがＡＯＰの利点とすると、
メインコードのメソッドは他のアスペクトの都合なんか考えない単位になる。
ＡＯＰがメソッド単位でしかWeavingできないのなら、
アスペクトは都合の悪い単位でしか記述できず、
アスペクトにできることは必然的に非常に限定されることになる。

メソッド単位のＡＯＰはもうダメポ。

前から気になってたんだけど、メソッドの前後にフックするだけじゃ
ないんだが・・・。
（・・・もしかして、釣られてんのか？おれ。）

>>230 どんなの？
条件付フックじゃなくて？

>ログ処理の起点となるコードが呼び出し側に残るじゃん。
AOPでも、ログを出力するクラス、しないクラスを
識別するための記述が必要でしょ？
それが一括で（一箇所に）書けるか書けないかの違いじゃないの？
もちろんlog4jも、一ファイルである程度管理する事は可能だけど。

あと具体的にっていうのは、
具体的に一般化して示せれば、
こういうケースでは、こう使えるという手法になりうるけど
非常に特殊なケース（ログとり）でしか使えないなら、
それはプログラミングスタイルにはなりえないと思う。
すなわち、AOP的なロギングコードを記述するための方法にしかならない。

でも、逆にこう考える事もできる。
複雑なプログラムにはログを出力したいケースが多い。
（だからこそlog4jのようなものがあるし、JavaAPIにもある）
ならばそれを言語機能に加えればいいじゃないか。
じゃあ、どうすればいいか？
という事を考えればいいんじゃないかな？
俺はロギングでのAOPの有効性をまだ理解できていないんだけど
それがわかっているなら
言語機能として組み込んでみればいいんじゃないかな？
もちろんAOPという一般的な枠組みではなく、ロギングに特化した方法でね。
実行時にログ出力、非出力を切り替えられるのは
(if文を使わなくて）
Javaを使っている人には魅力的に思えるよ。

アスペクト指向とは違うのかもしれないが、separation of concernsに対しては
MixJuiceやRubyのModuleってのはなかなかいい方向性だと思う。

　　　Ruby廚さん、出番ですよ！
　　　モジュールを熱く語って下さい

MixJuiceは >>157

去年のレスで.NETも最初からAOPを意識してるとかあったな。

メソッドの属性か。現実にはあの当たりが妥当か？

AspectJの使い方解説
http://www.oucc.org/~tail/aspectj/

ほしゅ

保守sage

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

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

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

↑↑↑アスペクト指向とは何か↓↓↓
http://pc3.2ch.net/test/read.cgi/tech/1031056945/43

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

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

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

MJのモジュールの組み合わせって、どのくらいの自由度なの？
module B(extends A)とmodule C(extends A)は共存できるのでしょうか？

module B' = B - A と
module C' = C - A を作って
A, B', C' を組み合わせる方が
設計的にはかっこよさげ

使えれば何でもいいよ・・・。

Rubyのモジュールって要はインクルードマクロじゃん。

>>248
何もわかってない人は来なくていいよ

OO さいこう!!

248がいいこと言った！

251=248

>252
違うよ。ばーか。

251=バカ

254=超ウルトラスーパーバカデラックス

255=超ウルトラスーパーバカデラックス 文化包丁と果物ナイフもプレゼント

>>256
バカは、バカっていう奴がバカさ。バーカ。

ネタ切れ?

2ちゃんで言語をつくろう!スレッド指向言語"--2"

OO 最っ高!!

Ruby厨ども、>>248に反論してみろよ。Ruby最高とかばっか書いてないでさ。

最近「Ruby厨」ってコテハンはいなくなって、
からあげ（なんとか）って人しかいないね。
個人のホムペの掲示板とかまで来たりして宣伝してるし。
キモイからやめてほしい。

なんで Ruby 厨に荒らされてんだ？

AOP は面白いけど、
既存の言語にライブラリでの提供じゃなくて、
新しい言語となるとユーザが増えないね。
このまま立ち消え？

>>219
元論文を読むと今の AspectJなんかにできることは
AOPが目指していることのほんの一部みたいだね。
今は20年前のOOと同じような状況なんだろうから
これからに期待だな。

アスペクトは設計段階で見つけるものなの？

>>265
コードを書いてて気付くこともある。

.NET の実装するアスペクト指向

http://www.ascii.co.jp/pb/msdn/article/a25_0045.html

>>267
いまいち。

>>267
ちうーか、随分古いかと。
前半はCOMの知識が無いので理解できんかった（鬱

最近AspectC#なるものが出たらしい。
http://aosd.dsg.cs.tcd.ie/AspectCSharp/AspectCSharpHomepage.htm

Hyper/Jはもう新しいバージョン出ないの？
結局よくわからんまま終わるのか

結局、ログ程度しか使い道無いんじゃないのか？
ＰＡＲＣ発ってだけじゃないのか？
ＯＯＰほどのインパクトは、どう考えてもなさそうだ.

うーん、よくわからん…。
ようするに「おら！飯を食う！」って言ったら
食事アスペクトがフォークとナイフと食べ物を用意してくれて、
食い終わったら勝手に片づけてくれるっていう事？

それってエージェントとガベージコレクタ？

オブジェクトを横断する？
facade の中に state や strategy が入っているようなオブジェクト群を
ひとつのまとまりとして扱えるっていう事か？
正直、わけわからん。難しい言葉じゃなくて
もっと優しい言葉で説明してほしい…。

>>273
それってエージェント？
ガベコレは違うと思う。

なんとなくちょっとだけわかった気がする。
誰もイベント送出しないイベントドリブンか？

そもそも、実行時にメソッドのアクセス権さえ変更出来ないような
安全重視の言語でアスペクトを利用しても、ログくらいにしか使えないだろ。

おぶじぇくと＝あるごりずむ＋でーた
あすぺくと＝��(オブジェクトiのメソッド) ＋ ��(オブジェクトjのデータ)

と書いてみるテスト。

アスペクトってのは、ある共通機能が、継承関係によらず、複数のクラスに
あることを言うっぽい。

フックとコード挿入でそれを実現したり、クラスにメソッドやフィールドを追加して
実現したりする。

>>278
それだけ読むと Delphi/VBの イベントみたいな感じだね

>>279
インスタンスが一つならそう見えることもあるかも。
でも、アスペクトは、複数のクラスにまたがって同じ機能がある場合も含む。
というかそっちが主。
その場合、イベントハンドラとはまた違う。

>>280
それは違う

>>281
どう違う？

>>281のリンクは>>279の間違い

これで「２ちゃんねる」は匿名掲示板の看板を下げたわけですが、
「２ちゃんねるガイド」の説明がまだ直っていないみたいです

>誰もが自由に書き込みが出来る匿名掲示板のシステムには、
>アンダーグラウンド（UG アングラ）のイメージが付きまと
>いますが、運営者としてはそういうスタンスではありません。

本運用になったら直すのでしょうか
あとNiftyみたいにですます調で書き込みしないといけなくなるかも (^^;

年初めからこれじゃあ今年いっぱいかぁ

ID変わった・・・

精神病患者のオナニーサイト
http://www.enjoy.ne.jp/~gokaino1/

メールきた。

あーあ、このままじゃ、まんこなめ放題だよ。はぁ......。

お前ら暇だな

>>136
ネ（ｒｙ

保守

コピペ厨はうざいが実際どーなるんやろか

Abone

漫画喫茶なんて言うのはやめてくれよ。
まあ俺もだいたいその方法想像つくけど。

じゃどうすりゃいいんだよ(;´Д`)

ニュー速への流民が増えそうですね

第3者が見て情報価値の低い書きこみ＞「質の低い」

ＩＰ取ろうが取るまいが
捕まるときは捕まるし
別に今までと大して変わらんと思われ。
ただ、今はちと過渡期なので
まわりが様子見な感じだけど
すぐに元に戻ると思われる

http://newspolls.yahoo.co.jp/public/archives/2076384460/p-ne6-7?m=r
賛成が多いけどさぁ、ちょっと怖いな。。

全く無関係な機関に告発すれば大丈夫。
例えば、新聞社数社に告発すれば、大丈夫。

それで受け入れられないなら、そもそも正当な告発では無く、貴方の
言い分が変なのかも。

1 ：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ ：03/01/08 17:13 ID:???
　　　そんなわけで、qbサーバでIPの記録実験をはじめましたー。

11 ：ひろゆき ◆3SHRUNYAXA ：03/01/08 17:16 ID:rLfxQ17l
　　　全レスです。

22 ：ひろゆき ◆3SHRUNYAXA ：03/01/08 17:19 ID:rLfxQ17l
　　　家族構成と小学校時代の恥ずかしかった思い出も記録されます。

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

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

89 ：ひろゆき ◆3SHRUNYAXA ：03/01/08 17:29 ID:rLfxQ17l
　　　＞一般人からも見れるところ？ 〉記録所
　　　既存のdatとは別に保存してるので、サーバがクラックされない限りはみれません。

　　　ただ、既存のdatと別なので、書きこみあたりの保存容量がほぼ2倍。

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

これでｉランドと同じになったわけか…。おっと、これも記録されてるな。くわばらくわばら。

早すぎ。まだ何も書いてない。

また明日。

問題は「真実を言ったらﾐﾝｼﾞｮｸｻﾍﾞﾁｭニダ」の訴訟好きキムチさんな訳で

なじぇ〜

内Pのレッド吉田、頼むから「今日のレッド」の時に
ネタ帳見ながらやるのやめてくれ、一応カネ貰ってんだろ

最高裁への上告は認められなくなったから、これで事実上判決確定だよ。
逆転も何もないって。
勢いで上告なんかしても一発で上告却下(門前払い)だよ。

二審も一審を支持。これに対して上告しようにも、
刑事訴訟と同様、自由に上告できるってもんでもないのです。
民事訴訟法312条 （上告の理由） 1項
「上告は、判決に憲法の解釈の誤りがあること
その他憲法の違反があることを理由とするときに、することができる。」
http://www.m-net.ne.jp/~doba/goto/hon.htm

ようするに上告しても今の制度では100％無駄。
これで完全終了ってことか。

やっぱりな・・・・

>ｽﾊﾟｰﾊｶｰにＩＰから本人のメアドを割り出してもらう
Hackerの名を汚すな。馬鹿。
IPからメールアドレスだと？
馬鹿か。割り出せるのは契約者の接続アカウントだ

書き込めた！　　倉庫板さんオツ！感謝！

結局ログかよ!

（＾＾）

（＾＾）

（＾＾）

保守

保

ダンジョンシージのプログラマのGame Developers Conferenceのスライドを眺めてたら
突然アスペクト指向という言葉を思い出してこのスレに来てみた。
http://www.drizzle.com/~scottb/gdc/game-objects_files/frame.htm

オブジェクトの階層構造が、視点を変えるとあっさり崩壊してしまうんで、
替わりにいろんな視点から見た外観とか特徴をベースに考えてみようって感じ……でいいの？

>>320
そんな感じ。
で、違う視点で見て浮かび上がった機能を、既存のクラス階層を
横断して実装できるようにするのが、AspectJ とかのツールなわけだ。

hosgu

ほっしゅ

あと少しで板の底だったのに。何てことしやがる。

そうだそうだー。

クラスなんか邪魔。

でもクラスがないとジョインポイントが作れない。

ほしゅ

ほしゅ

Ｃ＃のAttributeって、
Aspectの一種とみなしても良いですか？

>>330
良くない。

C#でアスペクト指向するならAspectC#

となるとunsafeやdelegate,propertyがCのポインタ演算のように邪魔になる。

http://aosd.dsg.cs.tcd.ie/AspectCSharp/AspectCSharpFAQ.htm
AspectC#では、以下の機能は未サポートということですが・・・

・Inner classes.
・structs.
・Delegates and Events.
・Attributes.

世の中には
Aspect を、Attribute の延長線上に捉えて、
Attributeが目指す所を、AOP(AOSD)でよりよく実装できる
と考えている人も居るみたいですね。

これ↓、どういう意味なんだろう？

http://pc2.2ch.net/test/read.cgi/tech/1016437480/353
353：デフォルトの名無しさん 投稿日：02/12/14 19:49
　　　>>341
　　　＞C#にはアスペクト指向的な要素が全くない
　　　ContextAttribute


これ見て誤爆したのかな？
http://www.ascii.co.jp/pb/msdn/article/a25_0045.html

AOPの 分散処理(EJB)適用例として、
JAC (Java Aspect Components)つう のが出てますが、おまいらどう思いますか？
　http://jac.aopsys.com/

>>332
はっきし言ってアスペクト指向にはそんなものお荷物で邪魔です

　----------------------------------------
　JAC (Aspect Component)がサポートする機能：
　----------------------------------------
　・シームレスな　　 オブジェクト永続化機能 　(コレクションや参照をきちんと扱う)
　・フレキシブルな　クラスタリング機能　　　　　(ブロードキャスト､ロードバランス､データ一貫性､キャッシング)
　・素早く簡単な　　 ユーザ定義､プロファイル管理､アクセス権チェック､認証機能
　・データ健全性を保証する機能
　・RADサポート：
　　- GUIアスペクト　　　　　　　　　　　　　　　　　- Swing や Web クライアントUI の開発を加速
　　- UML AF IDE (UML Aspectual Factory)　- UML上で aspect を設定して、実行可能なJavaソースを生成する
　----------------------------------------
EJB使ってる現場で、即使えたら便利そうなんだが。

技術が安定供給されて、ビジネス上の利用価値が定まって、
現場に浸透するまでの時間が長いんだよなー。

思ったより動きはえーなぁ。
うかうかしてらんない。

AOPの分散処理応用って、
今まであまり聞いた事なかったけど、
実は皆やってるのねぇー

＃Reflection 2001 聞きに逝っとけば良かった・・・

>>331
> となるとunsafeやdelegate,propertyがCのポインタ演算のように邪魔になる。
delegateは邪魔になる可能性ありそうな気もするけど、unsafeやpropertyはなぜ？
propertyなんか、ただの「プロパティアクセス→メソッド呼び出し変換」だよ。

JAC、中々良さげな予感。(まだ開発者版だけど)

AOP用IDEが持つ「知的増幅作用」を見てしまうと、
手動AOPなんて、手でリファクタリングしているのと同じくらい野暮ったく見えてしまう。

MDA環境はさしずめ、
犀の河原の石積み(可視化機能はあるが、知的増幅作用は期待できない)
ってところか。

>>333
誤爆ではないのでは？AOPの実装はAspectJだけじゃない。

>>341
ContextAttribute がAOPってのはどういう事でしょうか？
　http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemruntimeremotingcontextscontextattributeclasstopic.asp

AspectJが提供する機能のうち、
　http://www.eclipse.org/aspectj/

　the clean modularization of crosscutting concerns such as:
　1)error checking and handling,
　2)synchronization,
　3)context-sensitive behavior,
　4)performance optimizations,
　5)monitoring and logging,
　6)debugging support,
　7)multi-object protocols

直接的には 3)、>>333の実装で間接的には 5),6),7)あたりをサポートするのかな？

×ContextAttribute がAOPってのはどういう事でしょうか？

◎ContextAttribute は、C#の提供するアスペクト指向的な要素、なのですか？

次世代AOSD言語を標榜する JAC のアスペクト設定ファイルが、
C#の enum と attribute っぽく見えてしまうのは、気のせいでしょうか？
　http://jac.aopsys.com/demo.html

>>344　ってゆーか
　JAC はAOP言語(AOSD言語)じゃなくて、　Aspect コンポーネントだし。
　そのURLにあるaspect configuration なんて、コンポーネントの属性設定でしかないわけだし。

アスペクトと聞くとどうしてもゲーム会社を思い浮かべてしまう(ToT)

>>341
AOPの総本山 aosd.net 見ると、山のように処理系や開発ツールがありますね。
　http://www.aosd.net/tools.html

今現在、活きのいいのはどれなんだろう？

＃AOSD 2003 逝きたい age

>>342
正直間違いもあるかもしれんけど、
　1)error checking and handling,
extensible C# 参照
　2)synchronization,
SynchronizationAttribute参照
　3)context-sensitive behavior,
separation of concernsはこれなしには成り立たないだろう
　4)performance optimizations,
　5)monitoring and logging,
　6)debugging support,
　7)multi-object protocols
範囲が広すぎてわかんないんだけど、この辺も「実装すればできる」ってレベルなのかな。

separation of concernsと、それをどう実現するかってことだから、.NETのContext関連の
機能は実現方法のフレームワークとしてInterceptionパターンベースの機能を提供してるってこと。
AspectJよりHyper/Jに近いのかも？！＜間違ってるかも

（＾＾）

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

hostile

hoseiyosan

♥

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

OO 最強

OOあってこそのAOP

一応貼っとく

アスペクト指向プログラミングの成熟
http://japan.linux.com/enterprise/03/06/12/036214.shtml?topic=1

>>272
オラjava始めたばっかで、よぐわがんねだけんども、
ラーメンを作ったら、ラーメン用ドンブリと箸とレンゲを用意してくれたり、
カレーを作ったら、カレー皿とあつあつのご飯と福神漬を用意してくれる、
ってことなんだべか

OOPのときは、ラメーン自身がドンブリと箸とレンゲを準備するんだけんども、
AOPの場合は、用意する神様がおって、ラーメンが出てくるかカレーが出てくるか、
ずっと見張っとって、勝手に出してくれるんだべか。

共通な機能をくくるのに継承は使わね、ってことだべか。

例え話はよぐわがんね
とにかく今からAspectJのソース見るだ。

>>358
ラーメンを出そうがカレーを出そうが、
アスペクト店員が客席に案内して水を出し、食い終わったら
代金をとりたてる、あるいは食事途中にお冷を継ぎ足す、
のではないかな。少なくともAspectJの実装なんてそんなもん。

アスペクト指向の定義を書いた文章ってどっかにある？
アスペクト指向とそうじゃないものの境界線が知りたいんだけど。

>>358
何かに例えて理解しようとしてもダメ。
AspectJ使って、実際に何が起こるかを体感して、そこから結論を導け。

>>240の意見について、みなさんどう思われますか？

>>362
↑↑↑アスペクト指向とは何か↓↓↓
http://pc2.2ch.net/test/read.cgi/tech/1031056945/43-47
　　47 ：デフォルトの名無しさん ：02/10/23 00:40
　　AspectJの親玉も、aspectの例としてアクセス・コントロールを上げてたよん

>>363
ありがとう。

ListやStackへの操作を捉えて、その時の状態を描画していけば、
構造の視覚化ができて、学生に教えるのに役立つかなとか考えてみた。
でも、ListやStackがわかってない学生にアスペクトなんて使っても、
返ってややこしいだけだなこりゃ。

>>365
結構いいんじゃない？
あと、デバッグするのにも使えそう。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

（＾＾）

C言語のプリプロセッサってAOP？

ソースごとに記述が分散するので、SemiAOPだと思われ。
C#のAttributeみたいに。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

http://oo2003.it.nanzan-u.ac.jp/program_euc.txt

8月21日(木)
○ポストオブジェクト技術(1)：チュートリアル1
「アスペクト指向ソフトウェア開発」
講師：野田夏子、岸知二(NEC)

Visitorパターンはアスペクト指向？

>>369
LispのマクロってAOP？

そうだそうだー。

どれか買いたいんだが、お勧めとかある？

『Aspect-Oriented Programming With Aspectj』
http://www.amazon.co.jp/exec/obidos/ASIN/0672324105/ref=pd_sims_dp__2/250-6971824-9058617

『Mastering Aspectj: Aspect-Oriented Programming in Java 』
http://www.amazon.co.jp/exec/obidos/ASIN/0471431044/250-6971824-9058617

『Aspectj in Action: Practical Aspect-Oriented Programming 』
http://www.amazon.co.jp/exec/obidos/ASIN/1930110936/ref=pd_sims_dp__1/250-6971824-9058617

ちなみに上が古く下が新しい。

ウープの次はェアプだそうですね？

490 ：476 ：04/02/29 16:39
件の発言に関し、気に食わない点は、
オブジェクト指向から派生した新技術を、全てオブジェクト指向のバリエーションである
言い切ってしまうような傲慢さ、である。
宗教信仰者の単純な「信仰告白」、例えば
「オブジェクト指向は情報技術進化の最終形である」とか
「どのような新しい概念も、全てオブジェクト指向の理想の、実現形態である」とか
を聞いてるみたいで、ちゃんちゃらおかしいのである。

オブジェクト指向技術が世の主流になった今日、
新技術や技術シーズの多くは、
確かにオブジェクト指向となんらかの接点を持っている。
しかし、それら新技術の目的は、必ずしも
現在のオブジェクト指向を補完したり、
かつてのオブジェクト指向の理想を実現すること、
とは限らない。オブジェクト指向とは直交した概念を扱いながら、
それをオブジェクト・モデルにマッピングしている事もある。

例えば、
デザインパターン、リファクタリング、アスペクト指向は、
ソースコードのモジュール間に働く相互作用を、
うまく検出し、設計〜実装にダイレクトにフィードバックするための試みである。
それは、確かにオブジェクト指向の概念の上に構築されてはいるが、
業務システム開発で有効なビジネス・モデリングやユースケース駆動開発に代表されるような
いわゆる「オブジェクト指向開発方法論」とは、全く無関係に存在し得る体系である。

それらの、新しい技術的萌芽を、妙なイデオロギーで歪めて、
オブジェクト指向開発方法論の下位概念である、と貶める意図が、
私には全くもって理解できない。

ageてみる

495 ：デフォルトの名無しさん ：sage ：04/02/29 17:04
元々オブジェクト指向って
オブジェクト間のメッセージ通信の意味しかないだろ。

classとかinheritanceとかあんま関係ない。
Smalltalkとかの古代のＯＯ言語の実装から
おまけ的にくっついてきただけ。

genericとかtemplateは畑も違うし。

なんでもかんでも「オブジェクト指向」って言うやめろ。
こんなとこで叫んでも無意味なのはわかってるが

498 ：490 ：04/02/29 17:23
>>495
それは、単なるメッセージ・パッシングでしょ。オブジェクトと無関係 (ﾌﾟ
ﾌﾟラズマ って言いたいだけじゃないかと、小一 (ﾌﾟﾌﾟﾌﾟ

491:デフォルトの名無しさん 04/02/29 16:51
被害妄想も甚だしい。大袈裟すぎる。
つうかそもそもユースケースって別にOOと関係ないじゃん。自分で自分の言ってる事に反してるよ。

494:デフォルトの名無しさん 04/02/29 16:57
>>491

いや、オブジェクト指向開発方法論の構成要素を上げただけなんだけど、何か？

491:デフォルトの名無しさん 04/02/29 16:51
被害妄想も甚だしい。大袈裟すぎる。
つうかそもそもユースケースって別にOOと関係ないじゃん。自分で自分の言ってる事に反してるよ。

494:デフォルトの名無しさん 04/02/29 16:57
>>491

いや、オブジェクト指向開発方法論の構成要素を上げただけなんだけど、何か？

ありがとう。
でもここでは暴れないでね。

>>384
　http://pc2.2ch.net/test/read.cgi/tech/1031056945/13-15　を参照のこと。

>>478の引用元書いた本人だが。
勝手に俺の意見コピペするのは、
あまりうれしくないんだが。
君はどのような意図でコピペしたのか、
きちんと説明して欲しい。
あと、もし>>478の内容について議論するのであれば、
元レスでやるようにお願いする。

君の行為は、荒らしだ。

↑ >>478じゃなくて、>>378の間違いですた。

aspectjの実装ってもしかしてaspectの内容にしたがって
その部分にメソッド呼び出しを書き込むだけなんてことはないよね？

なんで？

>>378の引用意図を明確に汁！

> オブジェクト指向開発方法論の下位概念である
こんなこというやつがいるんだろうか。
もともと別物だろ？位置づけ的には総称的プログラミングみたいな感じ？

> 元々オブジェクト指向って
> オブジェクト間のメッセージ通信の意味しかないだろ。

OOはメッセージングメタファという人と、
抽象データ型の発展系だという人がいる、
と思う。

>>388
クラスファイルにWeaveできなかっったっけ？まだ？

>>393
できるよ。
jarに対してがつんと。

アオップ（最後のプは口をつぐむ感じで）

>>391
一応聞いとこう。
なんで総称プログラムんぐと一緒にする？

AspectJでweaveしたら、スタックトレースの行番号とかどうなんの？

> なんで総称プログラムんぐと一緒にする？
単に位置づけ的な見方でいうと、結構相似じゃないかなと。
OOとは別の概念だし、実装レベルのモデルの話で、
OOのような分析フェーズまで広がりはないし。

漏れの感覚だと、フレームワークやコンテナみたいのと相性がよさそう。
純化された実装を、それらに粗結合させる糊みたいな。
問題は、元実装から関心外の事柄をどこまで抽出して純化できるのか、かなと思う。

「フックポイントに対するルール適用」と考えてる。 ビジネスルールを監査する宣言的プログラミングが楽になるよ。

> ビジネスルールを監査する宣言的プログラミング
難しい事いうね。解説キボン。

デバック用のコードをaspectとして織り込むと便利なような気がしてきた

>>401
それは使い方としては普通すぎる。

> 問題は、元実装から関心外の事柄をどこまで抽出して純化できるのか、かなと思う。

AOPで純化なんてそんなのは妄想。アフォAOP信者に騙され杉。
純化ができるとしたら、AOPとは別の技術がもっと現実的にパターン的な解になる。
AOPでは、糊として取り出せる部分が分離されるだけ。

構造化やオブジェクト指向の概念は、それを直接学んでいなくても、
経験を積んだプログラマなら、ある程度は実践している事だった。

アスペクト指向はどうなのだろう？
今までそれと知らずにアスペクト指向っぽいプログラミングを
していた奴っている？

>>404
それっぽいものの必要性は強く感じてた。
でもC++やJava単独ではうまく実現出来なかった。

>>404
・整形済ソースをsedやemacs のマクロでパターン認識させて一括自動修正、とか、
・バイナリ・コード中の特定の命令やシステムコールを目印にパッチ当て、とか。

UNIX Cのプロファイラなんて、ソースコードにプロファイル測定アスペクトを埋め込む専用ツールもあったな

個人的に考える普及するかどうかのターニングポイント

Debugやpatch以外の効果的な利用法が今後出てくるのかどうか
ﾊﾞｲﾄｺｰﾄﾞにweaveする行為にｿﾌﾄﾊｳｽはどう対応するのか(どういうライセンスにするのか)
AOPに対応した良質なIDEが出てくるかどうか(今のところeclipseのAJDTだけ?)

> Debugやpatch以外の効果的な利用法が今後出てくるのかどうか
これがほぼすべてだろ。
利用法もないのにIDEがでてきてもな。ライセンスは壁になる可能性があるが。
というか、debugやパッチなんて使い方はあんま言われてないんだが。。
まず言われるのがログ。そしてログ。あと、ログ。って感じ。
おまけで認証やトランザクション。あとパターン。

一番言われてるログだって問題ありまくりだろ。
ログは、まさに出力する場所ごとに固有の情報を出力することが重要。
これは、外から後付けで十把一絡げにできるものじゃない。
SoCは、綺麗で気持ちいいし、再利用性も高まるけど、
あえてその反対をすることにメリットがある場合もある。JavaDocとかね。

>>410
そういう意味では、MixJuice最強。
AOPはウンコ。

みんな、Procedure Oriented Programming に戻って乞い。

相変わらず、話がループしてるねぇ。

AOPの特徴、それは型継承抜きの実装｢継承｣を可能にしたこと、これに尽きる。

継承で差分プログラミング、これは10年以上前は多数派だったけど、
今では実装継承目的で、無茶な型継承しちまうおサルさんの問題が指摘されて、
委譲で解決しる(型継承の必要なしに実装を使い回したい時は、型＆実装継承してるクラスに頼め)
、っつーのが世の流れになっている。

次、型継承。Javaで言うところのインターフェス。
だいたい、分析モデルに対応した型で、実装抜きだから、実装継承はもちろん要らない。
あと、Javaのインターフェースは多重継承／多重実装可能だから、まがりなりにも多重継承を扱える。
但し、実装多重継承は自動で解決してくんなくて、コードをしこしこ書く必要がある。

最後、アスペクト。
MixInとの関係からすると、CLOS流の実装多重継承の最新版、という感じなのかな。
アスペクトは、型的には関連の薄い、複数のクラスに横断的に存在するから、
型継承抜きの実装継承＝アスペクト、と言える。
アスペクトのコードは、複数の型に跨がったコードだから、ジェネリック・プログラミングとの関連も指摘できる。

で、次。アスペクトの有効な可能性が期待できる領域。

1.メモリーが非常に狭く、オブジェクト指向の実行時オーバーヘッドが問題になる分野
　例：携帯Javaアプリ　初代i-appliは、実用的に二つまでしかクラスを使用できない、
　　　　　　　　　　　つうトンデモない事実上の実装制限があったわけで、
　　　　　　　　　　　そこでオブジェクト指向と類似したモジュールプログラミングを目指すと、
　　　　　　　　　　　アスペクトという解が出てきた。

2.設計の悪い、一体型(スパゲティ)Javaアプリケーションのカスタマイズ。
　業務アプリをとりあえず、Javaで書いたものの、全然オブジェクト指向設計じゃない、
　オブジェクト指向の保守性に関するメリットを全然享受できないやん・・・
　つうレガシー予備軍アプリの再利用検討の案件を受けて、
　アスペクト指向の適用を思いついた。(3年前。但し、シャレのわからん上司はCATENAの某手法を進めたがったので没(爆笑)

3.IDEのwizard機能とか、手製でExcelとかで書かれてる、ソースコード・ジェネレータの、進化方向としての提案
　よく似た、類型コードを、ちょっとずつ変えて大量生産する、つう事が、世間ではよく行われています。
　んで、継承で済まないのか？とよく調べて見ると、実は、初期オプション変えて自動生成したコードを元に、
　プログラマに手書きでコードを追加してもらう、いわゆる俗世間で言う「てんぷれぇと」として使ってるらしいです。
　しかし、最新のUMLモデラーのリバース機能みたく、
　変更したソースを再度読み込んで、初期オプションを変更したり、コード変更に伴うオプション変更を検出することは、
　大抵できないみたいっすね。

　よく考えると、自動生成したコードは、アスペクト指向のクロスカッティング・コンサーンなのではないか、と。
　すると、アスペクトの方をいくらでも途中で変更できるから、上記リバース機能の代替案になるのではないか、と。
　かように思うわけですが、まぁ今やってる仕事で即試す訳にもいかないし、
　誰か研究してくんないかなぁー、と、かように私は思う訳です。

閑話休題
ところで雑誌ジャヴァワールド2004/4は、アスペクト指向特集らしいですが、
どんな事例が載るのでしょうね？とっても楽しみなのだぁー。(やっぱLogとJBOSSとEclipseかなぁ。はぁ〜あ)

いや、おれを含めてほとんどの人が AOP に触ったことも無く
書き込みをしているのでこうなっているのだと思われ。

>>414
IDE のコード生成については generation gap パターンという案もあるのだけど、
IDE 側でそこまで面倒みてくれないと使ってもらえないんだよね。

>>417
どんな話？教えてプリーズ。(ググれは極力避ける方法で。)

あと、IDEの話だと、J2EE対応とか、特定業務アプリ対応で、
手軽に簡単にソースコード生成ウィザードを作ったりカスタマイズする
フレームワークがないから、なんかExcelとか使うことが多いらしいです。
Eclipse関連で、なんかおもろいプラグインはないのかなぁ

↑たいぽ
×ググる　は極力避ける方法で。
○ググれ！は極力避ける方向で、おながいします。

generation gap パターン(スペリング間違ってるかも) はごくかいつまんでいうと、
コード生成したクラスは触らせずにそれを継承したクラスを使ってもらうという方法。
2way にはならないけれど、オプションを変更して生成しなおしたときに
最初から書き直す(またはコピペする)という手間はいらなくなる。

これっすか？

＞Generation Gapパターン(2003年2月号)
＞連載第3回は、 Generation Gapパターンを紹介します。
＞　プログラムを作るとき、 通常は、プログラマがエディタでソースコードを書きます。
＞しかし、場合によってはプログラマが手でソースを書くのではなく、
＞ツールを使ってソースを自動生成するということもあります。
＞よく見かけるのは、 GUIアプリケーションの画面をデザインするツールですね。
＞　ソースを自動的に生成するツールは、 プログラマが手で作業する量を減らしてくれますが、
＞自動生成したソースに人間が手を入れてしまうと、再度生成するのが困難になる
＞という欠点もアリアンス。
＞　Generation Gapパターンでは、 継承を使ってこの問題を解決します。
＞　Generation Gapパターンでは、 ツールが生成するソース（クラス）に対して
＞プログラマは直接手を入れず、 「ツールが生成したクラスのサブクラスだけをいじる」ようにします。
＞こうすると、ツールがソースを再度生成しても、 プログラマの修正が上書きされることはありません。
＞　Generation GapパターンはGoFの一人、ブリシデスによるパターンです。

これっすか。何年も前にそれは考えたけど、、、実際それやろうとすると、インスタンス生成コードに手を入れないと。
＃ついでながら、細々したＧＵＩ作成の度に、いちいちクラス定義するよな方法は、はたして現代的なんだろうか、
＃などと余計なことも気になってしまった。。。

それそれ。
漏れは Java で書くときは pane 単位で一々クラスにするので
割とありかなと思ってるけど。
# 目的に適した generator をつくらにゃいかんのが一番の難点だが。

まあ、今となっては GUI 定義とロジックを分離した方がいいやね。XAML みたいに。

で、話が脇道に逸れちまったので、元に戻すと。

コード生成ウィザードのためのフレームワークを作る話。
F系で、アーキタイプっつうフリーソフト(記述言語がVBS風)があったっけ。
あれ参考にして、生成コードはAspectJのアスペクト、とかしたら、面白くないかな・・・

Middlegen

脇道(閑話)から本題に戻すのが"閑話休題"だったりするが

クソレスは良くないと思いまーす

>>413
実装多重継承って、言うとおり
Javaでもインタフェース多重実装+委譲で
もとからできるわけでしょ？それならIDEのアシストで十分じゃない？
AOPの肝はそれではできない何かなんじゃないの？

>>427
青い鳥探してるチルチルミチルみたいなやっちゃな。
他に肝がある？今、目の前にある肝を片付けないことには、次はないと思うよ。

インターフェース多重実装できるっつっても、それは型継承だけの話でしょ。
実装を他に委譲するっつっても、その「他」自体や委譲のコードは手書きする必要がある。
そこをアスペクトで概念整理して、実装の手間を簡略化できたら、意味があると思うけど。

漏れ的には、昔っからプリプロセッサ(RATFOR,CPP,C++ﾌﾟﾘﾌﾟﾛｾｯｻ)とか、
マクロやスクリプトで自動コード生成(Lisp,BillJoy,Java＆JavaScript＆HTML,XML)とか、
Smalltalk＆Lisp風リフレクションタワーって、すごくお気に入りなんだけど、
土臭い実用的側面と、理屈による整理がうまくかみあっていないような気がして、気になる。
結局、アスペクト指向が、そのあたりの整理に役立ってくれることを期待してるんだ。。。

> 委譲のコードは手書きする必要がある。
は、AOPじゃなくても、IDEでちょちょいとやっちまうという解があるわけで、

> そこをアスペクトで概念整理して、
例えば、この「概念整理」が肝だと思う。
3段目はこれを言ってると思うが漏れにはよくわからん
普及するかどうかは、これでどこまで何ができるかと思う。

頭が固すぎて、話に発展性がなくてつまらん。
青い鳥を全部打ち殺してから、「ところで青い鳥はどこ？」って言ってるような感じ。
まぁてきとうに生きててくれ。

ポテンシャルについて幅の広い視点での話をしたいんだろうけど、
> 手書きする必要がある。
とか、ショボいプラグマティックなネタと一緒にするから、
興醒めの現実的なレスが返ると思われ。
両者を的確に区別して認識・議論すべきかと。

すでに業務でAspectJとか使ってる人いますか？

結論：
チャネラーはやっぱヴァカ

アスベストは我が国では使用禁止ですよ。

>>432
上の方でいたと思うけど、こういう処理系に絡むのは、
正直漏れはバグが怖くて相当使われてからじゃないと業務では使えないなぁ。
内輪のツールとかならいいけど。

確かに、漏れの見落としかも知れんが、
AspectJは処理系なのにテストケースの量が壊滅的。怖すぎ。

ロギングツールとしてならどうだろう？

>>429
寡聞にして、委譲コードを直接的にせよ間接的にせよ
自動生成できるツールの存在を、これまで知りませんでした。
よろしければ、詳細をお教え下ちい。

>>437
相変わらず、ループしてますなぁ〜。
上の方で、わざわざ「ソースコード変更式プロファイラ」の例をあげといたのにぃｗ

>>438
Eclipesでフィールド選択してる時のコンテキストメニューに、
generate delegation methodsとかあったし、JDEEでもあったな。
普段使う訳じゃないので詳しくないけど。

>>439
彼はループしてるんじゃない。釣りは鮒に始まり鮒に終わる。
AOPでできることを地に足をつけて模索した終着地点に立っているんだよ。
しらんけど。たぶん。

>>439
プロファイラってのもあれだよな。
プロダクションコードじゃないっつーか、ログと似てなくね？
やっぱAOPってそういう斜めな使い道の技術なんだろうか。

>>440
Eclipse の委譲コード生成は視覚的におもしろいな。
ニョキニョキ〜とコードが生成されていく。

>>440
なんか1年近く前に見覚えがあるけど、たしか、
ダイアログかウィザードで、対話的にインスタンス変数とメソッド選んで、delegate生成つう感じかなぁ。
対話的に各種操作 (refactoringとか)できるのが最近のIDEの特徴だけど、
そーゆーいちいち対話的に設定する機能のって、使うのうざくねぇ？特に、数が膨大にある場合。
>>431 ダイアログやウィザードで設定するなんて、ショボすぎｗ
委譲を可能なら宣言的に/すくなくともスクリプトで書けるようにしちくれって感じ。

結局どんな使い方がいいのさ

宣言的プログラミング＞手続き的プログラミング＞対話的プログラミング

IDEのウィザードはプログラミングなのだろうか。。。
まあ、プログラミングじゃないからいやだと言ってるんだと思うが。

>>442
やっと釣れた〜。
わざとそーゆー例出したんだよん。

冗談はともかく。
・８０年代はまだまだ一般的じゃなかった、動的/共有ライブラリ技術。
・異CPU間エミュレーション技術近辺から一般的になったJIT (Just In Time) Compiler技術。
・AOPやJakartaでおなじみになった、バイトコード編集技術。
・・・と、コンパイル後のバイナリコードを動的に変更して、
コンパイラー言語の速度で、インタープリター言語なみの動的自由度を実現する技術が、
着々と実用化されている、とも言える。
そして、その手の技術は即座に業務アプリｗで使われるものではなく、
システムプログラミングや、開発ツール/テスト/デバッグ周りでまず取り入れられて、
充分な成果を積んでから一般に広まっていくものなのだろうな〜、なんちて。

＃動的/共有ライブラリ技術が、「プラグイン」てな形で一般に使用されるまでには、結構年月がかかってるわけだし

>>447
　>>446

対話的プログラミングは、ともすると変更箇所の回数に比例 O(n) した回数、ﾏｳｽをｸﾘｯｸしなきゃならんから、いやん。
RegularExpressionで位置指定して操作、みたいな「知的梃子作用」がないから、なんか原始的なイメージがある。

＞447
　も、もしかするとIDEのウィザードは、プログラミングではなく、設定作業とか事務作業、、、でつか？

> ・異CPU間エミュレーション技術近辺から一般的になったJIT (Just In Time) Compiler技術。
> ・AOPやJakartaでおなじみになった、バイトコード編集技術。
> ・・・と、コンパイル後のバイナリコードを動的に変更して、
> コンパイラー言語の速度で、インタープリター言語なみの動的自由度を実現する技術

随分と食いでのあるルアーだな、おい。
ぱくっと逝ってやったからなんかネタ晒してくんろ。

>>449
ともしなきゃいいだけの話じゃん。

疑似餌とトピックの区別がつかないと(匿名掲示板を使いこなすのは)、難しい。

>>414
2/24発売済やん、本屋逝って鯉！つう突っ込みすらない（ｒｙ

空気ばっか読んでて、トピックについて来れない痛い常駐者の居るスレ。

JITはリフレクションなどの動的自由度を上げる技術になっているだろうか。
というより、AOPは動的自由度によるものだろうか。

>>454
あ、なるほどねー。確かに関係ねぇやー。じゃなくてｗ

＞JITはリフレクションなどの動的自由度を上げる技術になっているだろうか。

あんま関係ないっしょ。
JITは、異なるマシン・コード間での、忠実な変換処理を動的にやる技術だから、
「マシン・コード間の変換に関する動的な自由度」
　　　例：MIPS系CPUの特殊命令でCPUのエンディアンをひっくり返した後で、
　　　　　元のエンディアンのコードをJust In Timeに変換しながら実行する。
はあるけど、
「機能面の動的自由度を上げる」わけじゃないでしょ。

お尋ねの「リフレクションの動的自由度」って、
感性的になんとなく判るような判らないような？？？
論理的にはっきり言ってどういう意味？
なんかレス付けにくいで〜す♥♥♥

>>454
＞というより、AOPは動的自由度によるものだろうか。

こっちも意味不明で、レス付けにくいで〜す。
「動的自由度、動的自由度」って、いったい何の動的自由度？？？

以下、混乱した質問に対する、混乱したレス：
　　AOP処理系によるクラス定義の再編成(weaving)は、
　　従来はソースコード・レベルで実現されていたが、
　　最近は実務的ニーズ(ソースコードの無いコンパイル済ライブラリも手軽にAOPしたい)に応えて、
　　バイナリコード・レベルの再編成もサポートするようになった。

　　将来的には、JIT compilerもどきの、JIT weaverも出るかもね。そしたら、動的自由度あるだろーねｗ

　　っつか、何らかの動的自由度に基づいてAOPの考え方が実現されているわけじゃないっしょ。
　　現在AOPは、ソース・コンパイルよりも後の段階でweavingを実現できるという意味では、
　　多少の自由度を得つつある。
　　それは逆に、「何らか(いったい何だよ！)の動的自由度」にとっても意味ある進化をもたらすのかな、
　　例えば、アスペクトという観点でその「何らかの動的自由度」を制御できるとかｗ

　　お兄さん、「自己改変コード」とかキーワード言えば納得するの？

　　　　　２ちゃんねる掲示板は、ヒッキーなどの動的自由度を上げる技術となっているだろうか。
　　　　　というより、ひろゆきは動的自由度によるものだろうか。

豚丼は、丼飯系ファーストフードの動的自由度を上げるメニューとなっているだろうか。
というより、唐揚飯は動的自由度によるものだろうか。

>>454
>>448 は、AOPに関する話じゃなくて、AOPのバイトコード編集をとりまく技術に関する話です。誤解のないよう

クソレスは良くないと思いまーす

静的な宣言性がAOPの現在のところポイントだと思ってるけど、外してるだろうか。
本当の意味で動的な方法のメリットを追求する方向は、寡聞にして聞かないが。
まあ、思いつきレベルの研究ならでてるかもしれんし、そのうち良いのが出てくるかもしれんけどね。
とりあえず、JSPみたいに一発目でとか、JBossみたいな設定ファイルとかは動的とは違うと思ってる。

> 「動的自由度、動的自由度」って、いったい何の動的自由度？？？
これは、
> コンパイラー言語の速度で、インタープリター言語なみの動的自由度を実現する技術
とおっしゃった方がいるので、そちらに。
漏れは、起動中のプログラムの命令レベルの処理シーケンスが変えられることかなと思ってるけど。

> リフレクションのような動的自由度
言語上に記述された定義に対して、実際の振る舞いの方を変えてしまう、みたいな。
ん？これってAOP？あれれ？(^o^;;

> アスペクトという観点でその「何らかの動的自由度」を制御できるとか
アスペクトは、制御というか整理の方があってる感じかな。
しかし、アスペクトの動的な定義系での意味ってイメージつかないな。
「動的」自体がメタ化（んなのありえるのか？）された世界での話みたいな感じだろうか。

AspectJより、DynamicProxyAPIでメソッドコールに割り込みかけるようにしたり
しなかったりを切り替える方が実運用が楽じゃないかと思っていたのですが、どう
思いますか？

クラスファイルを再編集するって、要するにリコンパイルするようなものです
よね？起動しっぱなしのサーバなんかでそんなことをするのは難しいのでわ、
とちょと思ったもので。実行中に変更できるといろいろ便利じゃないかな、と。

話が地に付いたな。たしかにそういう限定的な動的weaveはありかな。
ただ、実際に止められないようなサーバで
運用中のアプリのクラスをいじるなんてありかなって気はするけど。

>>462
　　リフレクションときゐちゃぁー、黙っちゃおれねゑー！
つう人も多いんで、漏れに判る範囲だけ謙虚に書いとくと。

リフレクションって、
メタプログラミング、例えば、関数を生成する関数とか、その関数を生成する関数、に関する話で、
その関数生成関係を、階層化として定義して、最終的に「いかなる状況にも対応しうるプログラム」
を作ろうとする話でしょ。で、その議論に、はかなり初期段階から動的自由度の話が入っていて、
メタプログラミングを動的に実行可能にする事で動的自由度を実現するとか、
あるいは関数の振る舞いを制御する「制御点」を提供して、動的関数生成が困難な処理系(C++)でも
動的なメタプログラミングを可能にしようと、かなり前(10年,20年単位)からいろいろ試みがなされているでしょ。
例えば、RWC (Real World Computing)系とか。

で、そーゆー戦略が、今でも有効なのか、リフレクションに関する研究活動が、今でも有効に機能しているのか、
寡聞にして私は存じません。ただ、AOPの話には、リフレクションの話は最初から折込済みだったような気がする

>>465
Windozeにパッチかけた後で、とりあえず再起動かけなくてもパッチが有効になるとかｗｗｗ

非常に需要の高い用途だｗ

> 例えば、RWC (Real World Computing)系
ほんとだ渡部さんも居たんだね。なにやったんだろ。
つうか、RWC自体なにしたんだろ? SCore開発？

> Windozeにパッチかけた後で、とりあえず再起動かけなくてもパッチが有効になるとか
Windowsに限らんと思うけど、実行中プロセスのモジュール入れ替えは、
動的コード改変よりも、整合性保証の技術が望まれるね。適用範囲も限られるだろうし。

んで、いずれも激しくスレ違いsage。

リフレクション！　リフレクション！　リフレクション！
黙っちゃおれねゑ人、降臨きぼん！！

>>427
「今でもインターフェエースと委譲で多重継承できる」っつうても、
それは、型多重継承を実装単継承で実装するために、
過度にクラスを細切れにして配置してるだけの話でしょ。

実装多重継承のキモは、同じようなコードの再利用にある。
そして、その「同じようなコード」は、型階層とは無関係に、
プログラムの随所に現れる事がある。それがアスペクトだ。
「クラス＝型と実装を組にした継承」という縛りを離れて、
自由に実装コードを共有できるようにし、
更にそれを分析レベルの非機能的要求と結び付けたものが、
AOPのcrosscutting concernだ。
だから、AOPはOOを乗り越える新しいパラダイム足り得る、
と、漏れは３年前から認識して居る

Javaなら、Interfaceプログラミングの励行とDynamicProxyAPIで、
何も準備しなくても普通にAOPプログラミングできると思うんだけど。

あんた、ただ一種類の実装方法を、しつこく粘着カキコしても、
話は広がらないし、第一、誰もあんたを尊敬しないと思うよ。

DynamicProxyAPIみつけたのが、そんなに嬉しかったんか？不憫だね〜ｗ

>>472
話を広げようなんて思ってないよ。Javaでやるのに特別なライブラリだの
フレームワークだのなんかイランでしょっつってるだけ。

頭のおかしな人の判定基準：
12. 議論の中心の本筋と、ほんのちょっとしか関連のない狭い話を、
　　一般論だと主張し、他の人の議論を妨げ、自分を議論の中心に据えようとする。

＃なんか最近、煽りの人の最新レス見なくても、煽りをこき下ろす予知能力がついちまった・・・。

まぁ、あれっすね。
DynamicProxyって、Lispのevalみたいなもんか。
プログラムの実行をメタレベルでコントロールできりゃいいって考え方。
静的な型チェックと相性悪そう。>>ﾈｳﾞｧｰｳﾞｧｰﾄﾞ

>>470
それって、ほとんど>>427への反論になってないんでないの？
>>427ではだめで、AOPならOKであることを、
言明のファーストクラスに据えたレスをしてみ？
具体例があるとなおよし。

>>476
相性悪そうっつーか、無理だろ。
ファーストクラスに引きづり出されても型推論てちゃんとできるの？

委譲だと、やる場所にコードが散らばるが、
AOPならまとめられるってことでは？

誰か助けてくれ〜
頭悪そうなレス付きまくりで、あいてにしたくねぇよ

まあ、そういうな。むかしからルイトモというではないか。

>>477
行間が読み取れないみたいだね
>>478
むちゃくちゃ頭悪い。

>>479
同義反復、永遠に無限ループしててくらさい。

>>480
スルー。つか、あんた悲惨だな。誰もあんたがヴぁかだとは言っていなくて、
単に場違いな主張を延々続ける痛い人、って言ってるだけなのに。
もしかして、頭悪いって自覚症状あり？

ただいま、このスレには「ファーストクラス」厨房が降臨中です。
また〜りして、ファーストクラス厨房が消えるのをお待ち下さい。

482==483!=470？
なんかよれてるな。

おっと、スレ番間違えて自爆してるし。
>>830は>>831のまてぃがい

おっと、スレ番間違えて自爆してるし。
>>480は>>481のまてぃがい

ふぁーすとくらす厨、まだ居るの(ぷ

メタ・プログラミングは、なかなか楽しい。
しかるに、掲示板で議論の本筋そっちのけで、言った言わない、あんたがヴァカだおまいもなー、
みたいなメタ議論始める奴は、人生終わってる

484==470==455==486-488？
だとしたら、>>484はドンぴしゃの釣果だ。

煽るのは一向に構わないが、自分の不都合や弱点、無理解への言及がある度に
これをレッテル張りをして排除するのは、議論の質を下げるので止めていただきたい。

メタ議論はさておいて。

某スレで「メソッドコールをクロスカッティングコンサーンとやらと認識する」という珍説を発表した、
http://pc2.2ch.net/test/read.cgi/tech/1031056945/554 さん、さっそくその珍説を御解説してくらさい。
あと、類友でデムパを受信された
http://pc2.2ch.net/test/read.cgi/tech/1031056945/565 さんも、援護射撃をどうぞ〜

あっちのスレは、荒らさないでね

「メソッドコールを crosscutting concernsと認識する」？？？

誰か、>>492の引用文の中身を、翻訳してクレ〜
頭の皮が剥けそうな程、大笑いしちまったよ〜

春、ですなぁ〜。
JavaWorldはAOPで盛り上がりまくってるのに、
ここ２ちゃんは、デムパがアレまくっていますね。

http://pc2.2ch.net/test/read.cgi/tech/1031056945/565 もおもろいぞ。

「それで自由にcrosscuttingできていると言えるのかね」？？？

crosscutting＝横断　と訳すとして、
「それで自由に横断できていると言えるのかね」？？？^100
なんか、横断歩道の話題ですかｗ

何かと思ったらあっちのスレの話題か。あっちでやれよ。

居直るデムパ

>>497
デムパは相手にせず、スルー汁

あっちのスレもこっちのスレも、同じ人物がスレ立てしたって、気づいている人、何人居るんだろうねｗ

developerWorksの"AOP banishes the tight-coupling blues"
ttp://www-106.ibm.com/developerworks/java/library/j-aopsc/

にある "Static crosscutting" って、どんなツールを使ってるの？

public aspect FooBar {
　void Foo.bar() {
　　System.out.println("in Foo.bar()");
　}
}

とかコードが載ってるんだけど。

>>500
記事よく嫁

あぁ、AspectJと断りなくコード書いてるな。

とAspectJを知らないヤシが適当なこと逝ってみる。

デムパの強度が上がって参りました・・・・

>>491
俺は、その発言者じゃないけど。
多分、発言者は、「全てのメソッドコールを横断的関心事として切り出そう」と主張しているのでは？
すると、Lisp のevalと同系統のメタプログラミングだね。

元発言の言いたいことは、
メソッドコール時に関心事の処理を行うってことだと思うけど。
メソッドの追加はどうすんのってのと、
関心事の処理自体を整理するのがAOPじゃないの、
ってことでないかと。

メソッドコールがメッコールに見えた＿|￣|○

>>505
う〜ん、AOP以前に、
evalでメタプログラミング (インタープリター式メタプログラミング)って、
効率上の問題からとっくに終わっちまってると思ってたんだけど、
JavaSoft〜JBoss方面には未だに残党が生息しているのか。

そんなにevalしたければ、VMカスタマイズすればええやん→バイナリコード小細工すれば、目的果たせるやん→method call全部hookしれば小細工必要ない
って、話がどうどう巡りだね。で、そのmethod callレベルのフックを、Java自身で行なうようじゃ、効率の問題は残ったままなんだろうね。はぁ〜ぁ

あ、evalでメタプログラミングじゃねぇーや、
リフレクションAPIのMethod Invocationを毎回呼び出してメタプログラミング、か。
VM byteコードで、インタープリタを記述してるようなもんで、オーバーヘッドがキツそうだね

一応、>>505が「また」キレないように、前発言をフォローしとくと。

メソッドコール時に関心事の処理をする、、、って、一体どうやると思う？

リフレクションAPIのMethod Invocation使って、
全てのメソッドコールをフックする(>>504)とオーバーヘッド大きいよ(>>507-508)。

どっかのスレにあったみたく、debugger APIの ブレークと同じ仕組み使っても、
実行効率は多少落ちるし、JITとの相性問題もあるし、第一、デバッグしにくくなるよ。

元発言者じゃないしあんま考えてないっす。
リフレクション系の動的でいくか、折り込みの静的で逝くか、
の話なんだろうね。Javaのリフレクションてそんなにヤバ遅なの？

というか、動的という方向はAOP以前から
既存クラスの処理をいじるっつうのは如何様にもできるわけで、
AOPってのは静的な方向が味噌なんじゃないかな？
型チェックみたいな静的な整合性の宣言の保証とかそっち方面の話の気がする。

ふ〜ん、その、アスペクトに型を付ける、という聞き馴れない新概念について、
ぜひ説明をおながいします。いや、必要だと思うよ、そーゆーのも。

ん？アスペクトに型を付けるって話じゃないでそ。

単に、静的なAOPと、動的なAOPがあって、
現在は前者が主流だし、そっちの方が魅力的だ、
と言ってるのでは？

昨日のDynamicProxyAPI厨房、まだ居るのかな？
あーゆー、他人の議論無視でつたない自己主張をする既知外の人は、
今後一切カキコしないでほしいな。

DynamicProxyAPI厨房って、
多分他の人からDynamicProxyAPIの事聞いて、
その人の評判を貶めようと、荒らし行為をやってるような気がする。
言ってること支離滅裂だし、論点不明で主張が不明。傍から見て、可哀想な人。

まったく、２ちゃんて、そーゆー人格破綻者のカキコが多すぎるよね、
多分ほとんど同じ人だと思うけどｗ

>>510も、かなりキテルけど、刺激するとヤバイから、穏便に処理、と。
はっきり言って、何を主張されておられるのか、さっぱりですな。
JBoss AOPの解説記事や開発状況読んで、
なんか自分がすごい技術を知っていると勘違いしている厨房、痛過ぎ。
自分でなんかやってから、その仕事を自慢してみろよｗ

このスレでは思ったことを自由にレスして欲しいな。
ただし、AOP自体に関した内容限定ね。

ひたすら一人の人が両方のスレで煽ってますな。
暇人。

DynamicProxyAPI厨房、まだこの板で粘着してるよ。
どうせ、自称脳科学者の既知外の人でしょ。さっさと寝ればｗ

>>517
煽り御苦労。さっさと寝れ。

だって、ここ40レスのほとんどが君一人の書き込みじゃん。
何がそこまで君を駆り立てるのか興味があるね。

しかし。久しぶりにこのスレ継続的にヲチしてみたら。
何時にレス付けても即レス返って来るしｗ
暇人の人は時間が無限にあって、いいなｗ
春厨って奴ですか。春、だなぁ〜

>>520
中学生はオヤスミ。
君は、もうちょっと一般常識とか、社会常識を勉強してから、ここに来てクレ。
もう君の相手はこりごりだｗ

ん？必死な人の相手をするボランティアですよ？

市ね

ういっす。回線切って首釣ります(･∀･)ｼﾞｬｱﾈｰ

あ、それから、「メソッドコールをクロスカッティングコンサーンと認識」つう珍説の解説もよろしくね。

やっと荒らしが逝ったか。
しかしスレを荒らして、皆の気分を悪くして、一体何が面白いんだろうね。
きっと陰惨な実生活を送ってるんだろうな(((；ﾟДﾟ))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>525
もう二度と来るなよ。

>>526
荒らしを煽ってどうする・・・放置しろよ！

>>427,>>477
反論してるのは、>>427の方でしょ。
なんで>>477は第三者的立場で人様に回答要求しているのか、よく知りませんがｗ

>>464-465
うーん、この議論の流れが尻すぼみに終わったから、
昨日は暴れる人が出たのね。傍迷惑な話だ。

JBossに関係ある話題なら、そっちのスレでやればいいのにね。
で、どうですか？という問いかけに対する回答は、上の方でいろいろ既出、と。

OOPを逆さまから読むとPOO プー

AOPを（ｒｙ

JavaからOLEやExcelを扱うAPIの名前は、

POI (Portable Object Interface) ﾎﾟｨｯ

>>533
寒いうえにスレ違い。

>>534 素人ﾊｹｰｿ

>>535
（　´,_ゝ`）ﾌﾟｯ

>>1
>OOPも、満足にやってないうちに、その次が出てきてしまいました。

さしあたり、OOPの拡張と認識しておいて良いと思います。
そもそもOOPを駆逐するような性質のものでは全くないので、
やはり過渡期においては「いいとこ取り」が健全かと思われ。

通常のOOPLでは難しいリファクタリングの延長として
捉えてみるのも良いと思います。
とりあえず、メソッドの本質と関係の薄いコードを
コピペする様な状況を回避するには便利です。

あと、デザパタの実装としてAOPを採用するのは、個人的には
時期尚早と思います。(非常に小規模のチームであれば別ですが。)
AOPの利点としてDPが挙げられていますが、
当分は別々に考えて良いと思います。

# お節介ですが、AOPよりデザパタの方が業界的にも重要かと思われ、
# そちらを優先されてはいかがかと。。。

ＡＯＰでデザパタ云々つうのは、研究者のネタに多いね。
現場にどっぷり浸かってる人間が手を出すべき対象ではない、と思われ。

あ、そいえば、ちゃねらーの「ＡＯＰでＪ２ＥＥ！」プラン否定して
「ＡＯＰでﾃﾞｻﾞﾊﾟﾀ分析こそ重要」って見解示していた
titsのｾﾝｾｪ〜も、さいきんはJBoss状況把握目的で海外出張してるそうだ。

研究者よりも、ちゃねらーの方が感覚が鋭いなんて、お笑いだな

「J2EE！」って範囲広すぎで意味不明なんだが

いみふめ

リアルのほうのちゃねら〜は、
短いレス読んだだけで、全て判ったつもりになって煽るから、
おもしぇ〜なぁ〜(ﾌﾟﾌﾟﾌﾟ

>>532
それヤバすぎ

捕手。

hage

良さそうだけど今はいいや

あおぷ〜

sage

､

エージェント指向？

アプリケーション指向に決まってる。

アゼルバイジャン指向ってなんかかっこよくない？

アルバート・オデッセイ・プログラミングも中々良いよ

Arab Opinion Performer
「アラブ、意見の表現者」というテロ組織です。そんなもん広めちゃいけません。

ＡＯＰって何？

Accumulator OPeration codeのこと。
アセンブリのアキュムレーターレジスタを操作する命令。

ＡＯＰって何？

「あんた、おとななんだから、ピシッとしなさい」の略。

いや、あんまおもしろくない
「あん、おにんにんから、ピッとでた」
のほうが数倍ォもろい

AOPというのを先輩が社内に持ち込んだ。
「コンポーネントどうしの協調をAOPでコーディングすれば
コンポーネントがビジネスロジックに依存することがなくなり、
再利用性が増します！！」
と、上司に力説していた（ﾎﾝﾄかどうかは知らん）。
すると上司が、
「じゃあAOPを作れ！！」
と逝っていた（ﾜｰｲ社内onlyのAOP言語が作れるぞ〜〜）。

ｳﾞｧｶな上司はおいといて、
先輩の言うコンポーネントとそれを業務に特化させるコードをAOPで書けば、
コンポーネントの使いまわしって出来るんだろうか？

余程上手く書かないとﾐﾘ

どこでなにが起きるかわからないコードになるのがオチ。
うまく動いてるのなら問題ないが、うまく動かなかったときにはげしく追いづらい。
というか、意図したとおりに動いているのか確認する必要がある。
へんなところにアスペクトがひっかかってたり、ひっかかってなかったり。
ちょっと一部の動き変えようと思ったら、全体に影響あたえてしまったり。
メンテナンスできなくなるよ。
業務ロジックとは関係ないログ・トランザクション程度にとどめておけ。

コンポーネントの使いまわししたいなら、DIコンテナ使うことを考えた方がいいよ。

インスタンスレベルアスペクトについて語って下さい。

ふつうだね。

どっかのHPに書いてあったが、JAVAならVMをカスタマイズできるように
さえなってればAOPってやりやすいんだろうなぁ。と思う今日この頃。

>>と、上司に力説していた（ﾎﾝﾄかどうかは知らん）。
>>すると上司が、
>>「じゃあAOPを作れ！！」
>>と逝っていた（ﾜｰｲ社内onlyのAOP言語が作れるぞ〜〜）。
お前はアホか。
そんなネタの会社があるものか

>>565
大手SIerの重役にだって、
それくらい(良い意味でも悪い意味でも)カッ飛んだ事言いだす人が居るもなー。

現実できるかどうかはおいといて、理想論ではメモ帳なり何なりのプログラムを組み
アスペクトとしてUNIXやWindows,携帯電話,ポケコンなんかのプラットフォーム固有の機能を取り出し、
目的のプラットフォームごとにアスペクトをウィーブしてコンパイルなんて事が出来るようになんのかね？

メモを取るという一つの機能に関して、
プラットフォームによって実装を切り替える話なので、
それはアスペクト云々とは違うんじゃないでしょうか。

実装をコンパイル時に決定せず、
設定によって切り替える手法として
DIが盛り上がってるとか盛り上がってないとか
当たり前だからスレは閑古鳥だとか。まぁそんな感じです。
ttp://pc8.2ch.net/test/read.cgi/tech/1099827125/

スレが閑古鳥って？
おまえなんか勘違いしてるな。

２ちゃんじゃAOP/AOSDネタをはじめ、
まともなネタに変な粘着する人物(約一名)が居るから、
もうまともなネタなど振る人が居なくなったっつうことでしょ。

>>569
自己紹介ですか？

↑誰にも相手にされていない可哀想な人

↓千葉せんせーがすかさずふぉろお

＞コンポーネントがビジネスロジックに依存することがなくなり
ちょっとちがうだろ
コンポーネント同士の依存性が少なくなるの間違いだろ
それに、その意味であればDIと混同している

ええと、
ビジネスロジックが、実装依存（というか横断的関心事）
のコードに汚染されるのを防ぐのがDIの目的、
という理解じゃダメ？

>>573
防げないからダメ

＞実装依存（というか横断的関心事）
この部分が変。
横断的関心事の意味を間違えて理解してそう。

ええと、横断的関心事って、
任意の処理に着目したときに、その処理固有の目的以外の、
複数の処理に共通して課されるような目的・・・じゃダメ？

ＡＯＰなんてご大層な事いっても、
結局ＤＩに全部持ってかれちゃったね。詐欺師共ざまぁｗ

DIはAOPができるから便利なわけで。

むしろ、AOPを積極的に使えるようになったわけで。

関心事の観点で書くってのがAOPであって、
それはDI自体ではサポートされてないにも関わらず、
DI＞＞＞＞＞＞＞AOPな現状。
つまりAOPはゴミ。

>>573
それはまたアスペクトと混同している・・・
お前知ってる単語並べてるだけでない？

>>543の認識も無理はない。

○関心事・アスペクトについて、まともな定義も合意もない。
→ＯＯは、少なくとも、スロットに変数や手続きを持ち、is-a関係…、云々の合意がある。

あと、

○関心事・アスペクトでモデリングしたとして、まともな記述力がない
→ＯＯで、メッセージによって起動される実体は手続きであり、
　スロットにアクセスすることで、構造化プログラミングと同等の
　十分な処理記述能力がある。

同じ「指向」を名乗るＯＯと比較すると、AOPが如何に駄目であるかが明白になる。

間違った。

×>>543の認識も無理はない
○>>573の認識も無理はない

恥ずかしい奴

>>580
キミの意見はゴミだね。
現状認識からしてまったく違う

OOと比較してAOPがダメって・・・
同時に組み合わせて使うものを比較してどうするんだろう

>>586
構造化とOOは組み合わせて使いますが？
比較したら排他になるんですか？
やっぱ、AOP儲ってこの程度の知能なの？

>>585
君の観察眼はゴミだね。
AOPは、ネーミングやPARC発って事で、
バカな技術系マスコミがとりあげて名前が広まってるだけ、
あるいはそれを利用してマーケティングキーワードに使ってるだけ。

>>587
で、OOと比較してAOPがダメとわかる理由にはならんね。
そもそも「同じ指向とつく」っていうのが比較の理由だからね。

そろそろ当たり前に使われようかってときにダメとか言われても。

>>589
別に、わかりやすいように比較しただけで、
>>582から、OOの記述部分を取り去っても、
AOPが駄目であることを十分に説明しているわけだが。

大仰な名前と宣伝に対して、現実の適用可能範囲が狭すぎ。
DIの（曖昧な）おまけと見るのが正しい。

あれで十分説明できてるのか・・・
まともな記述力がないっていうのも。OOでは書けるのにAOPでは書けないっていうなら、OOで書ける部分はOOでやればいいだけって話で。
現実の適用可能範囲っていうのも、たとえばDBのトランザクション管理するのにAOPは必須になってるわけだし。

GUIプログラムするときの値変更通知とかね。
Webだと元々イベントが発生したところから処理が始まるから、Webだけ見てるとAOPはあまり必要なかったりするけど、GUIアプリとかだと結構いろいろ使える。

＞まともな記述力がないっていうのも。OOでは書けるのにAOPでは書けないっていうなら、OOで書ける部分はOOでやればいいだけって話で。
＞現実の適用可能範囲っていうのも、たとえばDBのトランザクション管理するのにAOPは必須になってるわけだし。

これって、まんま
＞大仰な名前と宣伝に対して、現実の適用可能範囲が狭すぎ。
を肯定しているだけなんですが。
ログ・トランザクション・セキュリティはもう聞き飽きた。

>>592はObserverに比べてなにがよいんだ？

>> 大仰な名前と宣伝に対して、現実の適用可能範囲が狭すぎ。
> を肯定しているだけなんですが。

DB使うアプリで間違いなく使われることになるわけだ。
「ダメ」の理由にはならない。


> Observerに比べてなにがよいんだ？

Observerと比べるもんじゃなくて、Observer使うときに状態が変わるメソッドすべてに通知処理書く必要がなくなるっていうこと。

あ、もしかして、AOPは何にでも使えて世界が変わりますよ、みたいな過剰な期待をいまだにしてて、それを否定してるの？

何にでも使えると考えるほどの人は流石に居ないかと

スレタイ嫁。
詐欺師とバカマスコミと信者を叩いてるんだよ。
正しい現状認識があれば、DI＞＞＞＞＞＞＞＞AOPは自明。

あぁ、つまりいまだに4年前の認識してたってことだね。
で、DIとAOPは組み合わせて使うのに比較して意味があるのかと。

まぁ、ここで相変わらず基地外染みた叩きをやってる知恵遅れ君は、
情報処理学会パターンワーキンググループ発行のパターン入門本のAOPの章でも読んだ方がいい。

しかし、２年以上前にIBMが全力で取り組むつってるのに、まだ「バブルだハイプだ」と言い張るとは本当に馬鹿だな（ぷげら

「AOPがダメだと主張する」
　　↓
「主張している本人がダメ人間である事を隠せる」
　　↓
「いつも馬鹿にされているけど、ちょっとだけ優越感」

てな構図だろ、ここに粘着してる例のキチガイ(約一名)の行動パターンは。
いい加減この馬鹿アク禁にしちゃえばいいのにねぇ、あちこちの板でトラブル起こして、IPアドレスもバレバレな訳だし

逆から読んだら、ポーとポア

なんでそんなに必死にレスするの？
もしかして人間の友達が居ないから切なくて、
２ちゃんで誰かに相手してもらいたくてたまらなくて、
誰彼構わず喧嘩ふっかけまくっているとか。

人間として最低の行為、つうより家畜なみの行動パターンだな。

>>598
そんな認識ではないから、
AOPなんてバズワードのスレを叩いてる訳だが、大丈夫か？
で、比較したら、それが排他を意味するのか？大丈夫か？

絡む前に人のレス嫁よな。

>>603
　>>602 ぷげら。ゴミ虫はさっさと巣に帰ってプルプル震えてな

>>600は、全部同一人物に見える変な被害妄想どうにかしたほうがいいよ。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
NGワード「妄想」を使うキチガイが降臨中。
よい子のみんなは、目を合わせないように（笑
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>599-600　← これって、例の妄想基地外？どっか逝け。

>>603
排他を意味するとか言ってるか？
DIとAOPは相乗効果あるのに、どっちがよくてどっちがダメと比較することに意味があるのかといってんの。

>>602
とにかくキチガイを刺激すんな。
誰も相手にしなければ、そのうちこの世から消滅してくれるハズだ

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
NGワード「例の妄想基地外」を使う精神異常者降臨中(爆笑
とにかくよい子のみんなは、目を合わせないように（笑
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>600
正解。２ちゃんの構って君は、プロの開発者同士の会話にも
いちいちGoogleとAmazonで調べた付け刃のレスを付けてくるから
ほんともう死んでほしい。

こいつ本当はプログラムのひとつもできずにトグロ巻いている馬鹿だから。
もしつべこべ言うようなら、プログラムをアップロードするように仕向けろ。
すると自然消滅するから（爆笑

　　　〃∩ ∧＿∧
　　　⊂⌒（ 　・ω・）　　はいはいわろすわろす
　　　　 ｀ヽ_っ⌒/⌒ｃ
　　　　　　　 ⌒ ⌒

>>603
キチガイが現れたので、議論おしまいで。
反論逃げになるけど、まともにスレ続かないから。

このスレ、>>567以降全削除でも全然問題ないな。
頭おかしいのが定期レス付けてるだけだし。

>>613
了解。別に大した対立点も無い様だし。

>>608
そもそも議論などと呼ぶのもおこがましい妄想レスしか付いてないんじゃねぇの？>>567以降。
DIとAOPを同列に語るとは、本当にレベルが低すぎるな。OOスレ荒しまくってた例の低脳と同じ意見なのが、
すげぇ〜笑えた

>>613,>>615
痛い自作自演乙。
ほんとゴミ虫は二度とこのスレを荒らさないで欲しいね。
千葉先生 (灯台匿名教授)も嘆いている事と思うよ。

>>612
なんだ、やっぱニュース速報板に居るニートか。
君は大学に入ってから、このスレに来なさい。
とにかくろくな努力もせずに、他の分野を斜め上から批評するのは、
人間として恥ずかしい行為だ、という事を自覚する必要がある。

>>615
認識同じで表現違うだけだからな。
ほんとはそこの表現の違いで続けたかったわけだけど、キチガイをかいくぐってまで続ける意味はなく。

キチガイ(約一名)現在目を真っ赤にして、ニュー速板にでたらめなスレを立てている模様

>>619
　>>618をよく認識しろ。
　お前のレスなど、ミジンコほどの価値もないという事を自覚しろ

>>600
同意

　　　〃∩ ∧＿∧
　　　⊂⌒（ 　・ω・）　　はいはいわろすわろす
　　　　 ｀ヽ_っ⌒/⌒ｃ
　　　　　　　 ⌒ ⌒

>>621-622
前もそうやって自演してたね。

当然のことだが>>602は、>>577-598および>>601に対するレスね：-p

どうしてまともな教育も受けていない、自力で勉強する能力もない人間 >>577-598みたいなのが、
いっぱしのクチを利くのか。ほんと親の躾がなってないな。中学校からやり直せ。

はいはいテラ同意テラ同意

------------------------------------------------------------------------
以降、知ったか素人は書き込み禁止の方向で。

ペペロンチーノうまうま

ペロペロチンコうまうま

つーか、AOPとDIを比較するのって味噌と味噌ラーメンの
どちらが美味いかを比較してるようなものなんじゃないの？

------------------------------------------------------------------------
以降、荒しは書き込み禁止の方向で。

>>631
むしろ、味噌と麺の比較。
で、麺は必ず食べるけどスープは飲まないやつがいるから麺の勝ち。

APO、非常に興味深いし面白い。
かなり便利そうだが、現状だと逆にプロジェクトのオーバヘッドが増す気がする。
鋭利な万能ナイフ、というよりは鋭利な錐って感じ？

>>633
どっちがどっちﾃﾞｨｽｶ？

>>633
おまえすっごく馬鹿だな。
馬鹿にレスする俺も馬鹿だけど。
スープがあるから麺が食えるんだろ？
麺を食うと共にスープも口に入ってるの気付いてないの？
こんな奴らばかりだからＤＩとＡＯＰの本質も理解できずに
スレが荒れる訳だわな。

>>635
DI>>>>AOPってことだったから、DIが麺かな。

>>636
だから、DIとAOPを比較することがそういうもんだって例えでしょ？

　　　　　　_,,..:--─‐-=,,._
　　　 .／;;,ｨ''"´￣｀ﾞﾞヾ;ミミﾐ;;､
　　 ./ﾐﾐ/ﾞ　　　　　　 ﾞ:::ﾞiミミミ:l
　　 ｉミﾐ′: 　　 　: 　..::::_;ミﾐ;ﾐ;ﾘ
　 　 ヽ,! ﾞ .,;;;..''　 ''ﾞﾞ;;_ ﾞ:::ヾ;;;;;;/
.　　　 ｝ :'ﾞ::“:ﾞ:.　l::'ﾞ.”:ﾞ;.::'':;;ﾞirく ＜ちょwwwそりゃねえよwww
.　　　 |　ヽ .,r　..:::、 　 ..::::;;;ﾄl;|
　　　　|.. 　:' ''ｰ;^''::ヽ. :':::::;;;i::ｿ
.　　　　l、　←‐'‐→､! ..::::;;;lﾞ´
　　　　 ヽ..　`ﾞﾞﾞ.,ﾞ´　'":::';;;ﾊ､
　　　　_,,/`i､ -:: -:::'::ﾞ:::;;ﾂ'::::`;､_
_,...-‐''" |　ﾞ;、 i":;;:::::;,／':::::::::;!::::｀::-､.._
　　　　 .lﾞ　　ﾞヽ:;,ン'":::::::::::::/::::::::: : -ｰ ｀
　　　　　l　　 .,/;l　　　　 ,r"
　　　　　.ヽ　/r;:ﾍ、　,,／;''
　　　　　　ﾞ ''::'`'´ ヽｨ::'

------------------------------------------------------------------------
以降、ＡＡ荒し、池沼レスの書き込みは禁止の方向で。

まわりがみんな同一人物に見えちゃうキチガイ君にめぇつけられたら、もうあきらめた方がいいよ。

------------------------------------------------------------------------
以降、ＡＡ荒し、池沼の書き込みは禁止の方向で。

------------------------------------------------------------------------
以降、まわりがみんな同一人物に見えちゃう自演キチガイ君は禁止の方向で。

妄想激しいなこの粘着（ぷ