【GoF】デザインパターン5

形を真似て形に入り
形を極めて形から自由になる

関連情報は >>2-10

過去スレ
デザインパターンの単純そうな質問 - (1)
http://pc5.2ch.net/test/read.cgi/tech/994836140/
【GOF】デザインパターン - (2)
http://pc5.2ch.net/test/read.cgi/tech/1087050664/
【GoF】デザインパターン 3
http://pc8.2ch.net/test/read.cgi/tech/1095388499/
【GoF】デザインパターン 4
http://pc8.2ch.net/test/read.cgi/tech/1116122102/
関連スレ
デザインパターン
http://piza.2ch.net/tech/kako/976/976074878.html
リファクタリング、させてくれ
http://pc5.2ch.net/test/read.cgi/tech/1081863662/l50
【XP】Agile Process 第2イテレーション【UP】
http://pc5.2ch.net/test/read.cgi/tech/1091773629/l50
【綺麗】デザインパターンは美しい！【究極の美】＠プログラマー板
http://pc5.2ch.net/test/read.cgi/prog/1089077456/l50

Web Page [ja]
Javaプログラマのためのデザインパターン入門
http://objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.html
C++で読むデザインパターン
http://www.01-tec.com/document/cpp_design_pattern.html
Javaなページ
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaMain.html
デザインパターン入門 (ちとわかりずらい…)
http://www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html
Inversion of Control コンテナと Dependency Injection パターン
http://www.kakutani.com/trans/fowler/injection.html
Inversion of Control
http://wiki.bmedianode.com/Spring/?Inversion+of+Control
デザインパターンF.A.Q.
http://www.hyuki.com/dp/dpfaq.html
デザインパターンを読み解く
http://hp.vector.co.jp/authors/VA020635/system/dpattern.html
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
http://www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm

Web Page [en]
Patterns Home Page
http://hillside.net/patterns/
Design pattern (computer science) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
C#によるデザインパターン
http://www.dofactory.com/Patterns/Patterns.aspx

書籍
オブジェクト指向における再利用のためのデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/
増補改訂版Java言語で学ぶデザインパターン入門
http://www.hyuki.com/dp/index.html
Java言語で学ぶデザインパターン入門 マルチスレッド編
http://www.hyuki.com/dp/dp2.html
独習デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4798104450/
Javaデザインパターン徹底攻略 標準プログラマーズライブラリ
http://www.amazon.co.jp/exec/obidos/ASIN/4774115797/
デザインパターンによるJava実践プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756141552/
Java実践プログラムによるデザインパターン入門講座
- Swingプログラムで体得する23のパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4894712563/
J2EEデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4873111781/
C#デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4822281698/

終了。後は焼くなり煮るなり好きにしてくれ。

[録画開始済]

デザパタ厨のこれまであった特徴
・自分の言葉で語れない　（技術者としてはずかしくないの？マジで）
・オブジェクト指向が理解できない　（おそらく　設計→ソース　にする段階で駄目なんだろうな）
・理論より実績にばかりコダワル　（とても技術者とは思えない）
・紹介する書籍はすべて読んで無い　（読んで無いもの人に奨めるな）
・デザパタを知らない人＝馬鹿　（そんなマイナーなもの常識にされてもね）
・設計の話をしているのにソースコードの提出を執拗に求める　（真性？）
・事実を捻じ曲げて正当化しようとする　（オブジェクト指向にはもう１つの意味が・・・って、ねぇよ）
・わかりやすく人に伝えようとする技術が欠落している　（オブジェクト指向が理解できない要因でもある）
・たまにデザパタ厨同士でデザパタについて話をしているが噛み合ってない場合が多い　（役に立ってねーじゃんｗ）

6 名前： デフォルトの名無しさん 投稿日： 2005/05/15(日) 13:45:28
議論の際にあんまり他人を馬鹿にする人が多いので
以下をテンプレに追加。

981 名前： デフォルトの名無しさん 投稿日： 2005/05/15(日) 12:52:35
>>978
またでたよー。
「２ちゃんだから〜」発言。
あのさあ、君が人を馬鹿にする発言しなきゃそれで解決する問題なんじゃないの？
結局、自分が答えられなくなると他のサイトへのリンク貼ったり、
「本紹介しますから、読んで勉強してくださいね？ｗ
このままじゃあなたみたいな馬鹿と話なんてできないですよｗ」
的な発言するから荒れちゃうんだろ。

自分の言葉をもってないのがディスプレイ越しにわかるんだよ。
どう頑張ってもこういうの誤魔化すの無理だから。
同じような職場で似たような仕事してんじゃん。俺等。
思考回路も似たようなもんなのわかるんだよ。

頭の狂ったOcaml厨ﾏ━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━ﾀﾞ????

>9の通り、荒し（自演含む）が常駐しているので放置するべし。
特に“オブジェクト指向使えりゃデザインパターン不要”を唱えているやつ
……やっぱりID必要だわな。

上記の話題については
　　>前スレ6
　　デザインパターンというと、かつては
　　　　・コンポーネント設計のための指針
　　　　・設計へのデザパタ・テンプレートの導入
　　　　・クラス間の相互作用に基づく自己組織化(w
　　などという工学的な視点から語られる事もあったが、
　　最近は
　　　　・教育カリキュラムとしてのデザパタ
　　　　・企業アプリ構築ノウハウとしてのパターン
　　に力点が移動してきている。

　　>前々スレ802-803(前スレ846)
　　>802
　　前スレどうだったっけ？と思って読み返してみたら、デザパタは
　　囲碁の定石みたいなものだってところで切れてた。
　　みたいじゃねぇよ！なんて終わり方だ⊂⌒~⊃｡Д｡）⊃
　　>803
　　「囲碁の定石」か。
　　囲碁は、ゲーム展開の状態数が極めて多いんで、
　　チェスのように機械で力づくで先読みをして、
　　人間のチャンピオンと対等に戦うようには、当分ならないそうだ。
　　(今後DNAコンピュータや量子コンピュータが実用になったら、ワカランけどｗ)
　　で、人間がそのような状態数の多いゲームをうまく扱うのは、
　　ヒューリスティックにパターン化をして、扱う状態数を圧縮してるのではないか、と。

あたりに最終的には落ち着いとります。

定石よりは手筋のほうがしっくりくるよ。

WebPagesへ追加きぼんぬ

PatternShare by マイクロソフト・パターングループ
　http://patternshare.org/
　コメント：企業ソフトウェア開発のためのパターン・カタログを体系化したもの。マーチン・ファウラー推薦

エンタープライズアプリケーション開発のパターン　by マーチン・ファウラー
　原文：　http://martinfowler.com/articles/enterprisePatterns.html
　邦訳：　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=DevelopingPatternsOfEnterpriseSoftware
　コメント：マーチン・ファウラー氏による企業ソフトウェア開発に役立つパターン・カタログ本の分類と紹介。

マーチン・ファウラー's bliki (blog)
　原文：　http://martinfowler.com/bliki
　邦訳：　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?c=recent
　コメント：「アナリシスパターン」や「リファクタリング」、そして「エンタープライズ・アプリケーション・
　　　　　　アーキテクチャ・パターン(PoEAA)」の著作で有名な、マーチン・ファウラー氏のbliki (blog)

WebPagesへ追加きぼんぬ^2

【アスペクト指向によるデザインパターンの改善】
　Aspect-Oriented Design Pattern Implementations
　http://www.cs.ubc.ca/~jan/AODPs/

　MixJuiceによるデザインパターン改善カタログ
　http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/&e=10431

　AspectJ を使ったデザインパターンの改善と支援
　http://www.ncfreak.com/asato/doc/aspectj_dp.html

実装上のTIP程度のものをデザインパターンとか称して馬鹿じゃねーの？ｗ

なんでデザパタとMLってなかわるいの？　

>>16
なぜそれじゃいけないのか？
もっと高尚・高度なものであるべきなんて思ってた？

デザインパターンについて語る朝鮮人がいるスレはここですか？

>>18
こんなゴミパターンいちいち登録させてたら、１ヶ月で１０００超えるｗ
パターン作るのはいいけどいい加減に使う方のこと考えたほうがいいよ。
人間がパターンとして利用しやすいのってどれくらいなのかだいたいの最適値を理解しなよ。
精々１０個ぐらいだよ。

　　　　　　　　　−　注意と警告　−

このスレには、学習障害の荒しが常駐しています。
見かけても決して相手にせず、スルーして下さい。
荒しをスルーできず、荒らしを相手にする事は、
スレの善良な住人にとって迷惑行為以外の何者
でもありません。

【学習障害の特徴】

・気に入らないことがあると我慢できず、乱暴な行動をとる

・一つの話題にこだわり、同じ質問、同じ話題を繰り返す

・聞きもらしが多く、会話も一方的で話題がとびやすい

・文字や文章を正確に（意味をとらえて）読むことが困難

・（因果関係など）複雑な会話は理解困難

・問題を理解して論理的に解決する力が乏しい

・相手の思いや感情を考えて、行動することが困難
　状況判断が苦手
　（人の嫌がることを言ったり、わがままを言う)

>>20
おまえ、アフォか？

この後、>>22がデザインパターンの未来を力説！

もうさぁ、
「GoFデザインパターンは、ソフトウェア・パターンのプリミティブだから
パターン一つ一つは非常に単純だが、
より上位のパターンを記述する上で重要な基盤である」
つうことを理解できない構ってクンは放置して、
より高度なパターンについて語ろうよ。例えばPoEAAとか。

>>24
設計にソースコードが出てくるデザパタにそんなもんは無いｗ

あ、俺これからディナーに出かけるから。
話題は後で振るね。じゃ

>>25
> 設計にソースコードが出てくるデザパタにそんなもんは無いｗ

↑この人変な妄想垂れ流してるな。日曜の晩にカワイソウな人だ

>>24
夕飯はもう済んだのか？ｗ

可哀想だからほっといてやれよｗ

NGワード推奨：W
　　　　　　　　　　↑全角文字

つか、オブジェクト指向を理解しなよ。
理解できないの？

結局デザパタしかりかいできないからだろW

オブジェクト指向を理解しないでデザパタしか理解していない？！
そんなことってあるのか？

>>33
お前みたいなの。

ゴミ以上のものではないね

オブジェクト指向が理解できたら、デザパタをおかしいと思うだろ。普通。

なんで？
おれは、あーなるほどと思ったけど

>>37
>なんで？
嘘吐くな。
オブジェクト指向の場合、対象物をそのままクラスに写し取るだけだ。
デザパタなんてでる幕は無い。

ゴキブリホイホイスレ！！！！！！！！！！！！！！

そんなに違うパラダイムを受け入れるのが困難なのか？
柔軟性の無い奴らだなぁ。

>>38
業務で大規模J2EEアプリケーションを組んだことあるか？
いちいちモデル抽出するよりもパターンに当てはめた方が圧倒的に効率的なんだよ。
業務では、効率的で誰にでもわかりやすい設計が一番正しいんだよ。
大規模プロジェクトで、メンバー全員に毎回毎回他人流モデルを理解させる労力なんて考えたくもない。

>>41
>効率的で誰にでもわかりやすい設計が一番正しいんだよ。
デザパタの普及率について

>>41
じゃあ、オブジェクト指向言語なんて使わなきゃいいじゃん。
何を基準にしてクラスを作ってて、どういう基準でメソッドを作ってるのかてんでバラバラなんでしょ？
最悪。絶対参加したくないプロジェクトだな。

J2EEパターンなんてOOとは関係なし。
J2EEの構造上の欠陥・罠を避けるためのただのノウハウ集じゃん。正攻法とか以前の問題。

どこがどうおかしいのか　俺にはわからない
たとえばなんだ？お前らの言うおかしいものとは

＞ デザパタの普及率について
会社でも協力会社でも普通に使ってるよ

＞ じゃあ、オブジェクト指向言語なんて使わなきゃいいじゃん。
＞ 何を基準にしてクラスを作ってて、どういう基準でメソッドを作ってるのかてんでバラバラなんでしょ？
Javaを使うからJ2EEパターンがあり得るのだが。
J2EEパターン知ってて言ってるの？

で、大規模J2EEアプリ組んだことあるの？

>>45
誰に何の問題についてきいてんだよ。
アンカーもつけられないようじゃ話にならないよ。

>>46
オブジェクト指向と関係無いことで騒がれてもねｗ

J2EEに問題があるとすれば、どこ？
具体的に説明してほしい。

なにも、問題は無い
デザパタ否定する者たちが、引くに引けなくなってどうしようもないのさ

>>49
まず、J2EEがどうしてオブジェクト指向の話ででてくるのか説明してくれない？

J2EEなどのデザインパターンというかフレームワークみたいなものを否定するなら、
その代替案はあるのか？

否定するものが出したからだろ？
J2EEパターン

>>52
そもそも触ったこと無いから、まずいもなにも知らないんだけど。

言って置くが、
デザインパターンのなかにJ2EEパターンといわれるものは当然含まれていることは分かっているよな
もしこのスレタイ通りGoFのみならばそれで語るのもいいが
内容は変わらない

>>55
それも知らない。J2EE触ったこと無いし。

J2EEパターンがOOの正攻法とでも？ｗ

ていうか>>41がJ2EEをなんのつもりで出したのか正直わからないな。

ここのアンチは、何のフレームワークにも頼らずに、
案件ごとにフルスクラッチでプログラミングしてるのだろうか？

>>59
てゆうかJ2EE知らない時点でその扱い？ｗ
Javaの仕事に当たったことが無い時点で知らないでしょうよ。

>>58
OO原理主義者は、GoFや、それをJ2EE向けにアレンジした
デザパタなどを使わないで
毎回、すべてのクラスをモデリングするんだろ？
２億超規模の案件で毎回そんなことするのかと思うと気が狂いそうになる。

Javaやってない奴はOOやってない扱いなんだ？ｗ
デザパタ信者はSmalltalkはやってるの？ｗ

じゃあ、何について知っているんだい？C++？

>>62
その理論だとsimulaからやってもらわないと納得いかない。

フレームワークとデザインパターンはちょっと違うような

面と向かってこんな子供の口喧嘩見たいなことはやらないだろ？おまえら？
いい年して恥ずかしいと思え
まともに議論できないのか？
チョコチョコ書くから誤解を招くんだ
最低意味のある400文字ぐらい書け
小出しにするからﾂﾏﾗﾝこと食いつかれる
小出しにするから誰が誰かわからなくなる

>>63
オブジェクト指向だよ。

コミュニケーションが下手なんです。

>>67
オブジェクト指向っていっても脳内だけの話だと何の役にも立たないのでは？
オブジェクト指向プログラミングをサポートする言語を使用してそれを実現しないと...

で、どんなオブジェクト指向言語を使用してるんだい？

ダメだこりゃ・・・
どっちも口喧嘩に勝つ方法しか考えていない

>>69
主にC++を使っておりますよ。

いや、マジでアンチが使用しているオブジェクト指向言語には興味があるよ。
なに使ってるんだろう？

OCamlです。

アンチはどの程度の規模でどんなアプリを組んでいるのか？
規模はプロジェクト予算でも、人月でもいいよ。

>>72
だからC++だって。

>>74
３年かけてゲーム作ったことありまする。
転職して、３ヶ月でウィンドウズアプリ作ったこともありまする。

>>75 スマン、タイミングがずれちまった。

C++はオブジェクト指向もサポートしてるけど、そのほかの便利な機能があるよね。
例えばtemplateとか。けどC++のtemplateはオブジェクト指向的には面白いところは無い。
テンプレートパラメータごとに関係の無いクラスが量産されるからね。

でも便利だし個人的にはよく使用している。いやtemplateだけでなく、
templateが絡んだデザインパターンも利用している。

これって問題あると思う？

>>76
とても仕事でプログラミングしてる奴の発言とは思えない。
規模を言えといってるのに。

＞３年かけてゲーム作った
＞３ヶ月でウィンドウズアプリ作った

なんでJava（特にJ2EE）も知らないでパターン適用を全否定できるのか、アタマの構造を疑うな。
自分が今まで関わってきた分野に関してはOOでいけるってだけだろ？

>>77
デザパタとなんの関係が？

>>78
いちいち人を馬鹿にするのが好きだね。
人数はプログラマだけ？デザイナ、サウンド、その他含めた数をいうの？
全部合わせると１００人越えると思うんだけど。
予算なんて知るかよｗ

>>79
Javaを知らない奴は全員馬鹿ですか？そうですか（苦笑ｗ

＃単に自分のやってきた分野がJavaだけだっただけだろｗ

>>80
開き直るなよｗ

ＯＯで行ってるってことは知らず知らずデザパタになっているのでは？

>>80
えっ？？？なんでこんなレスが？

私は、C++でオブジェクト指向プログラミングの範疇から外れた、
templateを使用した「デザインパターン」を使ってプログラミングしているのですが、
このような開発スタイルについて、「具体的」な問題点があれば例示していただけないでしょうか？

>>83
大体その場合が多いと思うけどね。
本人が気づいてないだけで。

100人だって・・・もろ失敗プロジェクトジャン

お前らが普段利用しているJavaのAPIの中にもそんなのゴロゴロしているんだが
それを知っててooさえ知っていればっていうのはおかしいよなぁ
知らないのなら、まぁ勘で喋ってたんだなって納得できるんだけど

>>83
何度もいうけどオブジェクト指向とデザパタは水と油だ。

>>88
>>87
頭冷やして来い

>>88 その理由も前スレかどっかに書いてある？

>>84
要するに何がいいたいの？
デザパタを使ってることについてどう思うか聞きたいんでしょ？

テンプレートを使ったデザパタでも、テンプレートを使わないデザパタでもデザパタはデザパタだよね？
>>77ってテンプレートの話からしたからすげーわけわかんなかったじゃん。
なんか違うの？

>>90
ありまくり。

>>90
うざいぐらい書いた。
そのたびに荒らしだのなんだの言われまくった。

まぁ、勘違いしてたってことで勘弁してくれや

一番明確に書いている奴を教えてくれ>>93

>>81
Javaを知らないのが馬鹿だなんて言ってないだろ。
パターン適用が有効である分野があることを知らないで全否定するのは馬鹿だと思うがね。

＞パターン適用が有効である分野
分野ってなんの分野だ？J2EE、J2SDK？そんなの関係ないと思う

>>95
これ↓

ＯＯＰなんだけどもなにもアプローチが
基本から脱線しまくってるじゃねーか。
どんなに複雑だろうとなんだろうと、オブジェクト指向はオブジェクト指向だ。
基本理念は

現実にあるものの構造をそのままプログラムに反映することで
誰がみてもその構造を把握できやすいようにすること

だったはずだ。
要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
この基本は絶対に変わらない。
プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
無かったら真っ先に担当者を問い詰めることができる。
これがオブジェクト指向の単純な利点だ。

>>88
「水と油」だけでは分からないと思うぞ。
具体的なパターンと、それを利用するとどのような具体的な害があるのか説明してやらねば。

言語はC++でな。

>>96
何が言いたいの？この人？
わけわかんない。

俺はデザパタはオブジェクト指向にのっとってねーぞ。
C++使ってやんじゃねーよボケ。っていいたいだけなんだけど。

>>99
アプローチから間違ってるっていってるのがわからないのか？
何度言わせるんだ？
なんでソースが必要なんだ？

>>98
言っていることはよく分かった
しかし、DPとの水と油関係はその話からは見えないよ
あのさぁ
日本人がよくオブジェクト指向を初心者に分かりやすく解説するときに
オブジェクト＝物って言う教え方しているけどあれをそのまま飲み込んでいないか？

オブジェクト指向は「物」の考え方もあれば「機能」でわける方法もあるということをお忘れなく
J2EEパターンで利用されているのは機能に着目したOOPです

>>100
なぜC++限定？
Javaはオブジェクト指向言語ではないとでも？

>>102
だからー。
デザパタってのはあるパターンがあってそれに当てはめる過程を必ずたどるわけじゃない？
俺はそこがまずいっていってんの？わかる？

>>103
いや、オブジェクト指向言語って意味で書いた。（こういうのいちいち説明させるのか？ｗ）

>>100
デザインパターンを利用したプログラミングが、
由緒正しいオブジェクト指向に従っていないとするのはいい。
特にC++だとtemplateが絡むとデザインパターンは、
オブジェクト指向プログラミングとは別の次元になるし。

しかし、オブジェクト指向に則っていない＝「悪」ではない。

「悪」であるとするなら、その理由を述べよ。

>>104
そういうやり方はデザパタの本質ではない
それはここにいるデザパタを（立場的に）擁護している人たちは知っています

>>97
ここで話題になっているのはJ2EE SDKじゃなくて
J2EEテクノロジを利用したエンタープライズアプリケーションだ。
Servlet/JSP/EJB等のJ2EEに含まれる技術を利用したアプリで、
J2EEパターンなどを一切無視して全てのクラスを毎回抽出するのか？

>>98
つまり自然にオブジェクトにすることが可能な対象を、
パターンに当てはめるために歪めるのが悪いってことか？
歪めるプログラマが悪いんであって、
パターン自体が悪いとは思わないなぁ。

とかいう反応ぐらいあったと思うから、
その書き込みへのリンク貼って欲しいな。

>それに当てはめる過程を必ずたどるわけじゃない？
無理やりこんなことやる人はいないです

もし、あなたが
>それに当てはめる過程を必ずたどるわけじゃない？
と考えているのであれば
DPを無理やり使いたがる人と同じです
あなたが思うよりもDPを擁護する人たちは
きちんとその辺の距離を置いていますよ

>>106
オブジェクト指向言語でそれをやっちゃうのは駄目じゃない？
原点に戻るけどオブジェクト指向言語っつーのはオブジェクト指向を実現するために・・・以下略
もういいだろｗ

この理由が駄目な理由として受け入れられないとなると
そもそも言語の設計理念を無視して進んじゃってるわけだからもうなにもいうことはないな。

>>104
つうかそれって結局使い手に依存する話なんだよね

つーか、「設計が下手糞」って言えばいいのか。
開き直って「それがどうかしましたか？」っていわれりゃそれまでだなｗ確かにｗ

DPの本とかにも結局、あなたの言うように何でもかんでもDPに当てはめてつくるという事はしないように注意書きがある
読んでいる人であればそれを理解しているはず

（例えば大規模J2EEアプリの開発の現場など、）
本来のオブジェクト指向に則った設計だけでは
立ち行かなくなってる現実があるからこそ、
パターンが生まれたのでは？
実際、毎回OOに則って全てをオブジェクトモデリングしていたら
気が狂うと思うけどね。

J2EEパターンの場合、規約的な意味合いもあるかも知れない

>>116
>本来のオブジェクト指向に則った設計だけでは 立ち行かなくなってる現実があるからこそ
いや、このスレの奴等は必ず、デザパタがオブジェクト指向にのっとっているものだと
信じている奴等ばっかりだった。>>83,85等←こんなこと言ってる奴のが多い現実。
オブジェクト指向を理解できない奴がデザパタへ逃げるんだよ。
俺はこれが残念でならなくてね。

>>118
デザパタはオブジェクト指向言語の機能を利用した物ではあるからな。
勘違いとか、オブジェクト指向という言葉の定義が曖昧なままスレが進んでいるようにも思えてきた。

>>112
プログラミング言語というものはオブジェクト指向を実現するためだけに
あるのではないでしょ。C++なんか特にそう。

オブジェクト指向だろうがデザパタだろうが有効なものは使ってしまえという発想が
なぜいけない？

>>120
さすがに　はぁ？　って感じｗ

このスレで>>116、>>118が一番分かりやすかった。

>>112
C++はオブジェクト指向言語ではない。

＞ オブジェクト指向を理解できない奴がデザパタへ逃げるんだよ。
それはどうかな？
オブジェクト指向をわかってないとデザパタの存在意義や目的が理解できないと思うけど。

>>124
だね。実際にプログラミングして設計に失敗した経験がないと、
パターンのありがたみは分かり難いと思う。

>>124-125
じゃあ、>>83,85みたいな奴はなんなのかと。
こいつらはデザパタ破門ってことでいいですか？

>>126
デザパタ破門ってよくわからんが・・・
>>119 のようなことなのじゃないのか？
そいつらの頭の中では
オブジェクト指向言語の機能を利用していることと本来の意味でのオブジェクト指向設計が同義に
なってるのだと思う。

>>127
なにがいいたいのか全くわかんねー

>>127
書き込んだ後一瞬で理解したｗすまんこｗ

OCamlが悪いとは言わないが、使っている人間が糞では、
どうしようもありませんねｗｗ

デザパタが駄目、
オブジェクト指向か駄目、

というより、

日曜の晩にこんな所で不毛な議論してる奴の
人間性が駄目

>>131
オマエガナ

たかが道具ごときに信者とかアンチとか騒いでる俺らもバカ

おれならMLでスマートに書くんだけどねｗ

ここ読んでたら、実務経験のみを参考に雇用許否を決定する現在の
システムは、問題も持ってるけど理には適ってるなと思った。

>>135
確かに。机上の空論程度にしか理解してない癖に、偉そうに語るアホが
一人いるね。

お前ら名無し止めろ。誰がどの立場で話しているのかわからん。
ML／OCalm推薦しているやつとオブジェクト万能論のやつは
別人ということでいいのか？

> 135
業務に近い内容の課題を出してサンプルプログラムを作らせるべきでしょう。
立派な実務経験でも、業務と能力がミスマッチしているケースはたくさんあるからね。

>>137
お前どうして、設計の話してんのにソースコードばっかり欲しがるんだ？ｗ

あぁぁらら・・・。
屑が粘着してるからやめとけっつってるのに、
いつの間にやら某自称コンサルの人まで参戦してる・・・

・・・所詮この程度の人だったのか。残念なことだ

いや〜C++でやるデザパタは最高やねｗｗ

自分の意見に自信がないからコテにできないんだよｗ

つーか、設計の話してるのにソースコード欲しがる消防レベルのＰＧは
この先どうするんだ？そんなに馬鹿で。マジで心配になるよ。

>>142に心配されたら本気で終わりだな。

>>141
俺は一貫してデザパタがオブジェクト指向から
外れていることを唱えているからコテにしなくても一目瞭然だな。

>138
設計をやらせるためにアーキテクトを雇うのならソースコードはいらんでしょうな。
そんときゃUML書かせるのかね？

……だから誰が何の話しているのか良くわからんつうとるだろうに。
実装レベルの設計とシステムレベルの設計がごっちゃになって疑似問題起こしてるよ。

まぁデザパタは実装をターゲットにした詳細設計レベルのパターンである
という点については、誰も反論がないだろう。

このレベルで反論してくるヤシは、プログラムなどやった事もないど素人の煽り。

>>146
つーか、オブジェクト指向に基づいてもいないから使う意味もないね。

↑とりあえずGoFのデザパタの件ね。>>実装前提のパターン

分析レベルのパターンなら、アナパタやドメイン駆動設計のパターン、そしてPeter Coadのビジネス・コンポーネント
データ設計レベルのパターンなら、Hayのデータ・モデリング・パターン
GoFより大粒度かつ具体的アーキテクチャを前提とした設計レベルのパターンなら、
J2EEパターン、M$のESパターン、EAAパターン

あたりを押さえとくべきだね。

ま、プログラムも設計もした事ないのに煽ってる素人の人には、
まるっきり関係ないけどな

>>147
お前はさぁ、キチガイ病院に早く入院したほうがいいと思うよ。
そのうちどうせ、通りに出て無差別殺人とかやるんだろ

>>148
そういうのおぼえんの面倒臭ぇじゃん。
オブジェクト指向１つで解決するならその方がいいと思わない？
ま、そのオブジェクト指向が理解できないのが問題なんだろうけどさｗ

>144
>デザパタがオブジェクト指向から外れていることを唱えているから
それではわからんて。いろんなヤツが「オブジェクト指向とデザパタは別物」と
発言しているからな。
それに>147 >150 みたいなバカな発言もお前のということでいいの？

>142
ソース書けないPG雇ってどうするよ。アーキテクトならＯＫだけどね。
雇い主はソースコード／プログラムがが欲しくてPGを雇うんじゃないの？

>147
良くいった。オブジェクト指向に基づいていない手法（構造化とか総称性など）
は使わないつうことだな。ガンがれ。

>>151
設計の話でソース欲しがるおめーはアホだからもう寝ていいぞｗ

>>152
　>>146
　バカはお前

詳細設計とかしたこと無いんでしょ。
許してあげな。

>>137
実務経験ない奴はそのトライアルへの参加資格すらない。
そもそも、実際に人を動かす型の雇用試験はコストが掛かりすぎる。
実務経歴を用いた机上トライアルで篩い、残りを仮実務によるトライ
アルに掛けるというのが現実解だろう。

馬鹿ばっかり。。。

プログラム技術板に強制ID制を導入すべきか否か
http://etc4.2ch.net/test/read.cgi/vote/1118144381/

ID ついても馬鹿は馬鹿でしょ。

今北産業。
なにこのスレの成長具合？ｗｗｗｗｗｗ
プログラム板でまれに見る良スレじゃねｗｗｗｗｗｗｗｗ

>155
まあ、そのための試用期間だしね。
ただ、一度現場に引き入れた人間にダメ出しするのは色んな意味で難しそう
……てかよほどダメじゃないと普通無理だよ。

>137 >142 >152
だからお前誰だよ。
ちなみに>145で
　プログラマ募集時：ソースコードで判断
　アーキテクト募集：UMLなど設計の成果物で判断
のようなこと言ってるんだけどな。

>158
いいんだよ。バカのIDが識別できれば。自作自演もわかるしね。

発言に継続性が生まれれば、発言者の中身が見えてくるし
誰がどの立場で話してるかも分かる。

困るのはあのコピペ野郎と人をキチガイ扱いする・・・やっぱりコピペ野郎かｗ
俺は一貫してデザパタはオブジェクト指向では無いと・・・略ｗ

キチガイはキチガイじゃん。誰が見てもわかるよ。
気がつかないのは本人だけ。ﾜﾛｽｗ

>>163 頼むからコテハン付けて

ＩＤはつけてほしいね。自作自演乙とか言われても困る。
俺、前スレで「自作自演乙」とか2回も言われた。してねぇちゅーの。

ところで、なんか最近このスレのレスがvip化してるような気が・・・ﾜﾛｽとかｶﾜｲｿｽとか。ﾃﾗﾜﾛｽｗｗｗｗ

>>166
その手の語尾はどういう意図で付けてるんだろう？
それだけで馬鹿っぽく見えてしまうから、発言の価値を
下げてしまって損だと思うんだけど？
文章を図的に見た場合に注意を引きやすいとかの効果
が期待されてるのかな？

マジレスで。
私も最初は>>167氏と同じ意見（馬鹿っぽく見える）でしたが
ニュー速vipという板を見に行くとみんな普通につけているので感覚が麻痺します。
スレ違いで申し訳ないですが一応レスを返しておきます。

。の変わりだと思うと気が楽だよｗ

みんなの語尾がおかしいわけではなく、
約一名変なのがしつこく粘着しているだけ。

ｗが3つ以上並んでいて、かつ読む価値のあるﾚｽというものを
見たことがない。

全角ダブリュー３つはNGワード推奨。
括弧開く全角ダブリューおよび全角ダブリューは、
多くの人々が使うが、この板では意味のない発言に付く事が極めて多い。

>>172
うっせハゲ

うは。URL間違えた・・・

>>15
WebPagesへの追加きぼんぬ　の二番目のリンクは、

　http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/

の間違いです。訂正してお詫びいたしますです。

>>147って冷静に考えたら凄い発言だ。
いったい>>147はふだんどんな言語を使っているんだろう？

脳内言語

>>175
OCaml。ﾃﾗﾜﾛｽｗｗｗ

以前この板で、
「アスペクト指向は、オブジェクト指向を前提とした技術ではないが、
　現在最も普及しているのがオブジェクト指向言語だから、
　オブジェクト指向言語の拡張としてアスペクト指向言語が実装されている」
という話をした事がある。
「オブジェクト指向を前提としてはいない」＝「ポスト・オブジェクト指向」というニュアンスなのだが。

ここに居る「デザパタはオブジェクト指向ではない論者」は、
上記の話のバリーエーションで、なんか変な妄想(プログラムできない素人の妄想)をして
変な煽りをやっているだけだろう。
キチガイじみた煽りっぷりを見れば、まともに相手にしてもしょうがない事がわかると思うが。

>>178
断片的に現れる電波じみた書き込みを見ると、どうも彼は

オブジェクト指向では、常に目的に最適化されたクラス構成にしなければならない。
↓
再利用など出来ないし、しようなどと考えてはいけない。
↓
デザインパターンはオブジェクト指向に反する。

という考えに囚われている気がする。

MVC with Objective Caml
http://www.lri.fr/~signoles/mvc.en.html

広義の設計パターンと関数型言語について、
こういう言い方をする人も居る。

http://books.slashdot.org/comments.pl?sid=97498&cid=8454307
Monadic programming is a fancy name for a pretty common sense design pattern used by functional programmers
far before the theory of Monads was created. Basically you want a function that executes a list of commands,
but the problem is that functions can only evaluate to pure values. So what you do is your function evaluates
to a value that represents the list of commands you wanted to execute.


So the design pattern consists of using functions that pass a state value in and out of each function,
in addition to possibly other values. The pattern enforces some restrictions, one of which is: each state value
can only be used once.

So executing one command and then another involves each command being defined as a function that takes the
world's state and returns the world's state after modification. Sequencing the two commands then consists of
composing the functions such that the state is passed from one function to the next.

There are additional properties required for something to be considered a Monad...
and it turns out that this "design pattern" is a mathematical construct known from a branch of mathematics
known as Category Theory, and that category theory construct is called a "Monad".

A side note: category theory is basically the study of mathematical design patterns. Its more than that,
but thats a good intuition for computer scientists to take when they study category theory.

>>181
読めないよ。
全部訳してそれに対する自分のコメントふれって言ってるだろ。
なんで人の言葉を借りなきゃしゃべれないんだ。お前は

>>179
そんなこといってないじゃん。
捏造までするのか？

>>182-183
英語読めない人間が偉そうな口聞くな。
逝ってよし

イマドキ、学部生どころか高校生だって英語読めるわよねぇ〜（ｷｬﾊ

>>181
こういうレスが一番むかつくんだ。
自分で読んですらいない文章だから、コメントも付けないで貼り付けるんだろ。
本当に読んでいるならそれに対する自分のコメントを添えろ。

いざとなったら、著者の実績を盾にして内容の正当化をしようとしてるのがみえみえなんだよ。
あいかわらず卑怯な発言ばっかりしやがって。
てめぇは自分の言葉ももってねぇくせに発言するんじゃねぇ糞が！
ホントクズにもほどがある。
死ね。もうてめぇは勉強なんてする必要ねぇだろ。

デザパタ信者でもこういう自分の言葉ももってねぇで
リンクばっかり貼り付けるクズ野郎の扱いってのはどうしたもんだろうね。

内容云々の前に技術者としてこんな卑怯な奴絶対に認めるわけにはいかないよ。

> 全部訳して

まぁこれは小学生レベルの戯言だからスルーするとして

> それに対する自分のコメントふれって言ってるだろ。
> なんで人の言葉を借りなきゃしゃべれないんだ。お前は

単に関数型言語(Ocaml, Haskell, etc.)における
・設計パターンという単語の用法や、
・関数型言語でデザインパターンそのもの、もしくは非常に類似した設計を行っている例
の事例に興味があったから、それをメモっただけだ。

あんたを説得するなんていう苦難苦行をやるつもりは一切ない。
あんたみたいなのを相手にするほど、こちらは暇ではない。

>>186-188
英語読めないって、もしかして中学も出てないのか？

月曜朝から気分の悪いコメントを書きまくる
お前の人間性は最悪だ

【NGワード推奨】
自分で読んですらいない
自分の言葉ももってねぇ
卑怯な

>>190
俺の文章読んで要点が英語だけだと思うほどお前は馬鹿なのか？

おまえの文章なんてNGワードだらけだから読むわきゃねーだろ

>>181
なんだろうね。こいつ。
もう性根から腐ってる。
一体、どんな教育受けてきたのかマジで不思議でしょうがないよ。
どうやったらここまでキタネェ奴を育てることができるんだ。
もう、根本から糞。人として駄目。マジで吐き気がするわ。

一時期荒らしが粘着していた某板の某スレは、
最近なかなか良い感じになってきて、
打てば響くようなレスがなかなか心地良いんだが、
こっちのスレはどうしようもねぇな。

荒らしが一晩荒らしまくった翌朝早朝なら、
絶対荒らしは出てこないと踏んだのだが、
相変わらず英語も読めず、相手の主旨も理解できず、
「俺様に理解できるようにしゃべらなきゃ偽者だ」とか言い出す。

世界はおめぇ中心に回ってるんじゃねぇんだよ
さっさと巣に帰ってブルブル震えてろって

朝鮮人か支那人かもしれんね。ここまで薄汚いと。

>>181
なんで他の人間の言葉を借りなきゃしゃべることができないんだ？
匿名掲示板ですら自分の意見を自分の言葉で言えないのか？

マジでこいつとは育った環境や文化からちがうんじゃないかと思うよ。

>>197
そうだねぇ、キミとは随分育ちが違うと思うよ。
普通に英語の読み書きできるし、普通に仕事してるし、
博士課程もでてるし、
匿名掲示板で無視されたからって朝から荒れたりしないし。

同じ内容のレスを繰り返すのはなぜですか？

たぶん頭が悪いから、相手を同じ言葉で罵詈雑言する事でエクスタシーを感じてるんじゃないかな。

普通に仕事してる人間は、月曜朝からこんなキチガイじみた書き込みをしないと思うけど

もしかしてここ荒らしてるのは、
「『今度は逃げない』と言って、また(業務コンサルの)会社を作った人」
だったりして

>>197
文章にオリジナリティを求めるなら、その内容でしょ。
文章の表現にオリジナリティを求めるなとは言わないけど。

しかし技術的なことが話題なのだから、内容が正確であることが最も重要。
だから、原文をそのまま載せることは良い悪いの評価対象ではない。

そりゃ、分かりやすいように表現してくれるほうがありがたいが、
間違ったことを（しかも主観まじりの）書かれるよりはよっぽどいい。

>>202
ほう、では>>181の英文の内容を、大まかでいいから、意訳してみろよ。
読めるという証拠に。自分は普通に読めるからする必要がない、という
方向はなしで。

そんな事もできないようだったら、お前の協調性はゼロだ。社会に出ても
だれもまともに相手もしてくれないだろう。

>>203
俺は202じゃないけど、
人に物を頼むときはそれなりの礼儀が必要なんじゃないかな。
ましてやアンタは札付きの荒らしなわけだし。善意を持って接する必然性がない。

>>204
言うと思ったよ。なんだかんだ理由つけて、結局英語読めないんじゃん。
だからここにいる皆に嫌われるんだよ。わかる？わからないだろうな。

>>203
やってもいいけど、タダではやれない。
あなたに技術的文書を理解させるのが私の仕事でない。

>>181で書いてあることがを理解したと思うのなら、あなたが読みなさい。
でも、翻訳した文書を貼り付ける必要はありません。

こ　こ　に　は　ま　と　も　な　人　は　一　人　も　い　な　い　ん　で　す　か？

>>206
お前が>>181か？
英文なんて貼ったら荒れるに決まってんだろ。
そんなことも分からないほどバカなのか？

>>206
＞あなたが読みなさい。

どうしてこう命令口調で高圧的なんかね。自分で「人に物を頼む時には
それなりの礼儀が必要なんじゃないかな」と言っておきながら、自分は
人を見下したような態度を取るのが当たり前だと思っている。

こんなの機械翻訳に掛ければ今時辞書など見ずともおおよその意味くら
い誰でもわかる。しかしお前はタダではできないとか、本質的な理由とは
おおよそ違った事を言いながら、結局は何もしようとしない。

>>206
君の底の浅さが知れたよ。アホだね。

アンチの特徴：具体例を求められると断固として拒否。
例：「ソース出せ」「設計出せ」「訳してみろ」「じゃあお前はどんな方法使ってるの？」などなど。

また穀潰しが仕事もしないで
昼間っから掲示板に粘着してんのか

>>209
英語読めないのからかうと面白すぎだな。
まず>>209が訳してみろ(ﾜﾗ

MonadicなアプローチなんてまともにサポートしてるのってHaskellぐらいなもんでしょ。
少なくともOCamlは違う。ｗ

相変わらず乞食みたいなのがしつこく荒らしてるな。

そろそろ語尾ｗくんと罵詈雑言くんはデフォでスルー、
何言っても相手しないって事でいいとおもう。

>>202
だよなぁ。
プログラミングにしたって、ユニークなアルゴリズムは歓迎されるけど
ユニークなコーディングスタイルはそうではないからなぁ（むしろ凡庸なほうがいい）。
# 表現自体のユニークさが求められる世界もあるとは思うが。

関数言語と広義の「設計パターン」の使用例２

http://www.masterliness.com/a/Lazy.evaluation.htm
MASTERLINE -- The World Knowlefge Library
Home > Lazy evaluation

3 Lazy evaluation as a design pattern
As well as the formal concept of lazy evaluation in programming languages,
*lazy evaluation* is a *design pattern* often seen in general computer programming.

For example, in modern computer window managers, the painting of information to the screen
is driven by "expose events" which drive the display code at the last possible moment.
By doing this, they avoid the over-eager computation of unnecessary display content.

Another example of laziness in modern computer systems is copy-on-write page allocation.

>>182
> >>181
> 読めないよ。
> 全部訳してそれに対する自分のコメントふれって言ってるだろ。

>>209
> どうしてこう命令口調で高圧的なんかね。自分で「人に物を頼む時には
> それなりの礼儀が必要なんじゃないかな」と言っておきながら、自分は
> 人を見下したような態度を取るのが当たり前だと思っている。
>
> こんなの機械翻訳に掛ければ今時辞書など見ずともおおよその意味くら
> い誰でもわかる。

> どうしてこう命令口調で高圧的なんかね。
> どうしてこう命令口調で高圧的なんかね。
> どうしてこう命令口調で高圧的なんかね。

> 誰でもわかる。
> 誰でもわかる。
> 誰でもわかる。

object-oriented ＝　オブジェクト指向（翻訳さいと）
Elements of Reusable Object-Oriented Software (BooksEnthsiast.com)　＝Gof本？

lazy evaluation is a design pattern.（なんか言い表現でも、へたすると問題の先送りになるかも）

Design patterns are standard solutions to common problems in object-oriented software design.
これが言いたかったのかな？

The phrase was introduced to computer science in 1995 by the text Design Patterns:
うっ、この後も続くのね。どこの年代で物言ってるかわからない。
The scope of often seen in general computer programming.
どこだよ。こうゆうの解らなくて英語は（もか？）かんべんです。

まるで私の無能をさらけ出してる様だ。

関数言語コミュニティと関数言語デザインパターン
　　　　CommonHaskellIdioms
　　　　　　There are a number of idioms, or design patterns, or styles of programming,
　　　　　　that are frequently used by experienced programmers.
　　　　　　http://www.haskell.org/hawiki/CommonHaskellIdioms
　　　　Design Patterns in Dynamic Programming
　　　　　　http://www.norvig.com/design-patterns/

OCaml and Design Patterns
　　　　2004-10 [Caml-list] OCaml and Design Patterns
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2004/10/a5a65e58429e3175fee88dfb7e06c135.en.html
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2004/10/503304c95e2ccd073b446a2d57d8e326.en.html
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2004/10/20a3988025ff8e418742124059d1a89a.en.html

>>219
　>>217は、あちこちの用語解説Wikiに載っている Lazy Evaluationの解説文。
あっちの国でも、他の辞書の解説をパクって使いまわすのね（笑

3.デザインパターンとしての遅延評価(Lazy evaluation)
　遅延評価は、プログラミング言語上のフォーマルな概念であるのみならず、
　コンピュータ・プログラミング全般でしばしば使われている「デザイン･パターン」である。

　例えば最近のコンピュータ上のウィンドウ管理システムは、なんらかの情報を描画する時、
　その情報を描画可能な最後のチャンスである"expose events"をトリガーに、
　描画コードの実行をする。
　この方法により、不必要なコンテンツ再表示による計算処理の増大を避ける事ができる。

　最近のコンピュータ上での遅延評価の別の例としては、メモリーアローケーションにおける
　Copy-on-writeが挙げられる。(訳注: Mach, WinNTをはじめとするマイクロカーネルOSの機能)

>>221
thx！

遅延評価≒関数型言語　の妄想から開放されたかも
遅延を仮想に置きかえれば、あのパターンは確かに関数型言語系をエミュレートしているのかな。
逆もしかりって事ですね〜。
（どこかでメモリが消費されてないとか言っていたのは、”メモリーアローケーション”か。へぇー調べる。）
（インスタンスの遅延はどこまで許されるのだろう？）
（私はオブジェクト指向を理解してない、用語は知ってるかも。デザパタはGofの派生本のみ）

うあ、内容なくてｽﾏｿ

やっぱりOCamlが最強なんだな。

OCmalは良いが、OCamlを使う人間が腐ってる。

Lazy evaluation って late binding とか lazy binding と同義？

Lazy evaluationは、ソバ屋の出前　(催促を受けてから提出物を作る)
Late bindingは、不動産屋の売り文句 (お客さんいい物件ありまっせ→客の好みを理解してから押し込める物件を探す)

結局オブジェクト指向よりも関数型の方がいいということか

>>227
なんでそうなる。
「ソバ屋の方が良心的」って話だ。

>>226
前にTIPSとしてLazy instantiationというのを習ったんだけど
その時の説明もソバ屋の出前だった。
Lazy instantiationとLazy evaluationは同じものと考えても
よいの？それとも違うものと考えるべき？

OCaml厨には、人格障害人間が多いという事だけは、はっきりとわかった。

俺ならデザパタなんかなくてもMLでスマートに書いちゃうけどねｗ

>>218
>>197は俺だけどそれ以降は俺じゃないんだが。

つか、結局デザパタ使ってる奴はこういうので満足なの？
俺はオブジェクト指向を理解できていない状態でデザパタに逃げちゃうのは本当にもったいないと思うよ。
デザパタとオブジェクト指向はアプローチから全然違うものだからね。
オブジェクト指向言語の機能を使ってもオブジェクト指向は理解できないよ。

俺はタレントプログラマなんかに騙されちゃう人が本当に残念でならないよ。
なぜ、デザパタに執着する人がいるのかというとね。
その勉強過程が学校のお勉強ににてるからなんだよ。
パターンを暗記するあの勉強の仕方がね。
それに対してオブジェクト指向は学校のお勉強の脳みそじゃ理解できない。
これまでと全く違う物の見方ができないと理解できない。
だからみんな挫折しちゃうのさ。
ホントちょっとしたきっかけだけなんだけどね。
「ボク博士課程卒業してるんだ。」←こういう奴ほど理解できない（だろうなぁｗ）

これができりゃどんなプログラムでも組めるって自信がつくぞ。
できるプログラマが人の１０倍〜２０倍の仕事ができるのはね。
俺はオブジェクト指向が理解できるかどうかといってもいいと思ってる。
デザパタじゃ所詮はパターンだ。

------ ここが我慢のしどころです ------

>>233
1億2億を超える大規模エンタープライズシステム開発で、スキルもまちまちな
有象無象のドカタ達を抱えるソフトハウス何社も使うプロジェクトを仕切ってから言ってみろよ。
オブジェクト指向だけじゃ限界があることを思い知るぞ。

>>234
ｽﾏｿ。我慢できなかった。

>>233 オブジェクト指向を理解してないとデザパタなんか理解できないぞ？

↓以下放置でおながいします

>>237
オブジェクト指向とデザパタはアプローチが全く異なる。
これは前から連呼している通りだ。
君はオブジェクト指向を理解できてはいない。

とりあえず、批判するのは最低以下の２冊を読んでからにしようぜ。
そしたら >>233　のような頓珍漢な的外れの罵倒はなくなるはずだ。
"Design Patterns" Gamma, Helm, Johnson, Vissides, Addison-Wesley
"Modern C++ Design: Generic Programming and Design Patterns Applied", Andrei Alexandrescu, Addison-Wesley

>>237
何度もいうがオブジェクト指向言語を使ってもオブジェクト指向は理解できない。

>>240
その知識を使って俺を論破してみなよ。
その２冊でできるんだろう？

アプローチが同じだったらデザパタが存在する意味がないじゃん。
オブジェクト指向を理解して、その限界もわかってるからデザパタがあるんだよ。

>>243
全然ベクトルが違うし、オブジェクト指向が理解できていればデザパタは必要無い。
苦し紛れにいうのはかまわないが、自分がオブジェクト指向を理解することは不可能だと決め付けるのはよくない。

簡単に説明するが、
オブジェクト指向は対象物をそのままクラスに映すだけだ。
パターンは必要ない。

オブジェクト指向は、いわゆるオブジェクトがファーストクラスオブジェクト
な計算のことだYO

そのままクラスに写すアプローチはひとつとは限らんぜ。
それを共有するのがパターンなわけだが。

>>242
じゃぁ論破するための論とやらを開陳しろよ。

>>247
なんだそれ

>>247
じゃあ、>>233で君が頓珍漢だといった内容で頼む。

オブジェクト指向と一言で言っても設計の話なのかコーディングの話なのかでずいぶん変わると思うんだがどっちなんだ？

おまえかあの書き込み？ >>233
それで言わせて貰うと、君は全くデザインパターンを知らないか、
まったく理解できていないかのどちらかだ。
議論以前の問題。上に挙げた２冊をよんだら >>233が恥ずかしくなるはず。
以上。

たまには建設的な話し合いをしようぜ

>>251
それじゃ話が違うじゃん。
ルール破ったのそっちだし、俺の不戦勝でいい？

はい>>253の勝ち、終了。

>>253
不戦勝でもなんでもいいから、もう来ないでよ。

>>255
つーか、いつまでデザパタなんかにすがってるつもり？
もう、いい加減オブジェクト指向と向き合う覚悟を決めなよ。

>233
だからお前は誰だと

>デザパタとオブジェクト指向はアプローチから全然違うものだからね。
みんなに突っ込み入れられているけど、デザパタ＝オブジェクト指向と
している人間は少ないと思うのだが……

　デザパタ≠オブジェクト指向
　-> デザパタは役に立たない

はウソだ、つうてるだけで。

ざっと眺めただけだが「オブジェクト指向が理解できればデザパタは不要」以上の具体的な内容が全く出てないような気がする

>>235
> 1億2億を超える大規模エンタープライズシステム開発

ぷっ。
￥１００，０００，０００　÷　￥１，０００，０００ [円/人月]　＝ １００人月　＝ ２０名×５ヶ月

アプローチが違うと具体的にどんな不具合があるのかと聞いてみたいなぁ．

>256 だからお前は誰だと

それを言う前に“定石としてのデザインパターン”という考え方を論破してみろ。

>>260 どうせ答えられないんだからきいても無駄だよ。

>>258
１０倍〜２０倍の仕事ができるようになりまつ。

20人を5カ月回して成果を出すの？デスマの予感……
5人x20カ月の方が良いなぁ

>>260
設計が汚くなります。

>>264
ここは業界常識が欠けたｲﾝﾀｰﾈｯﾄですね

>>263
うさんくさい広告以下だなｗ

>>265
実に主観的で解釈をめぐってもめる典型的な釣りじみた内容ですなぁ

>>267
それが事実になるから強烈なんだよｗ
言語の設計理念に革命をもたらしただけのパワーはあるよ。
それは保障する。

アプローチが異なると何で設計が汚くなるのかきいたらまずいだろうなぁ...

>>269を見て思わず詐欺とか宗教の勧誘とかを想像したのは漏れだけですか？

>>270
それはマズイかもね。逆切れされるかもよ。

>>271
詐欺や勧誘のほうがもっと巧妙だと思われ

それだ！なんか胡散臭いものを感じていたんだが、宗教臭いんだよ。
日本には信教の自由というものがあるから（藁）、気に入らなかったら
デザパタなんか信用しなくてもいいんだぜ。

ま、基地外の戯言など聞くだけ無駄だしね。

相変わらずアンチの論旨は具体性0だな

具体的な話に踏み込むレスをｽﾙｰして勧誘(>>233 >>256 >>269)とは恐れ入る

よっしゃ俺が具体的な話に踏み込んでやるぜ。お前らひれ伏せろ。

>>277
その参照はむしろ具体的な話から遠ざかる類のレスだろう。

>>270
複数の手法があったとして
たとえそれらが優れたものであったとしても
ベースとなる考え方が異なっていれば
同じ場所での共存は難しい。

1人で短期間のうちに開発する場合は、言うまでもなくベースが同じだから
問題は生じないのだろうが、
複数人または1人だとしても長期間かけて開発する場合は、
それぞれが持つベースの食い違いを埋めるためのオーバーヘッドが生じる。
そのオーバーヘッドが設計を汚くする要因になる。

たとえばリストの管理にキューを使うスタックを使う（※1）
親オブジェクトが子オブジェクトの破棄義務を持つ持たない
オブジェクトの取得では新しく生成するか既存のものを取得するか、等等。
開発の前に規則を掲げておくのもいいが、
開発の度に新たな規則を作り、その規則を読む、読ませる、の手間をかけるよりは
共通の知識としてパターンを覚えておき、パターン名により指針を伝えたほうが
簡潔だし誤解も生じにくいと思う。

※1 そんなものは STL 使えばいいじゃん、と言うかと思うが、
　STL もデザインパターンの1つだと思う。

上で述べたように共同開発を円滑にすることも重要だが
自分的には「言葉」と「知識」を繋げて定義してくれたことが
とてもとても大きな恩恵だと思う。

たとえばだ、
「マルチプラットフォームに対応したウィジットを作るとき便利な手法ってありませんかね？」
と聞かれたとき、たとえば
「AbstractFactoryでググれ」（この回答には突っ込むなよ）
の一言で済むこの恩恵！

デザインパターンが浸透する前なら、おそらくいろんなアイデアを出し合って
有意義にも見える議論が展開されたのだろうが、しかしおそらくその議論は
また別の場所でも起こっているに違いなく、それは知的財産の無駄遣いだと思うのだ。
一度優れた手法が考案されればそれを「言葉」として保存しておく。
そしてまた別の人あるいは同じ人が、その「知識」を再利用する。必要ならさらに練り上げて再保存する。

知識の再利用なんて昔からあったが、重要なのは「言葉」→「知識」の参照速度なんだよなぁ。
まさに情報社会の利点を存分に引き出すデザインパターンとその考案者に敬意を示すぜぇぇぇ！AGE!

>>278の(※1)はアレだ。リストの管理方法を示したかっただけだ。
キューとスタックじゃ機能的に意味が違ってくるが気にするな！晒しSAGE!

>>277への突っ込みは俺の勘違いですた。スマソ

あと「よっしゃ」まで読んだ、とかいうレスはやめてね。落ち込むから。

お兄ちゃん、今日は駄目

まで読んだ

「パターンはオブジェクト指向じゃないからダメ」ってなんだよその論理？
オブジェクト指向でやった結果、ある程度Genericに纏められる部品がでてくるってだけの話じゃん。
どうオブジェクト指向じゃないのか根拠もなしにダメってそりゃダメダメだな。
STLだってパターンの部分集合。Genericな構造でしかもオーバーヘッドがないなら使わない理由がない。
あんたの作る独りよがりな汚いtemplate classを読まされるくらいなら、Genericな物を使ってくれた方が同僚はありがたい。
いいから"Modern C++ Design"を読んで理解してから落ち着いて書き込め。

パターンを否定する人はたぶん職人気質なんだろうなぁ。
何もかも自分で考え自分で作り出さなきゃ気がすまない、という具合の。
意気込みを否定する気はないが、
その限界を知っておかないと周りに迷惑をかけることになるぜ。

一昔前はそれでも十分通用しただろうし、今でも通用する人はいるかもしれないけど、
所詮、人一人の力じゃ追いつけない程の規模にまでソフト業界は発展してしまったから。
進んで他人の技術を吸収してかないと時代に取り残される、と思う。

>>282
ﾊｧﾊｧ

>>284
そういう人は、例えばデータ圧縮ならハフマン符号化からJPEGまで楽勝で発明できるんだろうか？
他人の技術を使わないでランレングスしか思いつかなかったら、その人の圧縮率の限界はランレングスなわけだなｗ
確かに独自に発明しようというクラフツマンシップは大切だけれども、先人が既に解法を見つけているものを再発明しても、
それは個人の自己満足レベルの話でしかないわな。大学の研究者なら有り得ない愚かさだ。
先人の知恵を一生懸命学んで模倣して、こっから先は人跡未踏という位置で戦うのが普通。

>>233は、ヘボライターということで終了ですか。

>>285
それって設計の話か？

バカが自分でも理解できるからもてはやしているだけのインチキ技術が
デザパタｗ

>>287
285ではないが、ものを学ぶ姿勢のあるべき姿の話だろう。
これは精神論ではなく実益を生むぜー。

優れた技術を先人から学ぶように
設計手法においても先人が生み出した優れたものがあるなら、
それを学んだほうが良いに違いない、

とまとめてみるテスト。

>>289
何寝ぼけたこといってんの？
>>285の内容は全然設計と関係ない話じゃない。
どうしてここで圧縮技術の話なんか出てくるのか馬鹿の考えることはさっぱり理解できない。

だいたい、先人の知恵をきちんといかすなら基本となるオブジェクト指向をもっとしっかり理解すべきだ。
それをやらずにデザパタに逃げてるだけの人間なんて誰も評価しない。

>>285
だいたい大学の研究者ってプログラム組むのうまいかのー。
極めてハイレベルなところが世の中にあるのかもわからんが、大抵は・・・なレベルだよｗ
そもそも数年前に研究内容があまりにも幼稚で企業に見切り付けられたところがほとんどなのになｗ
昔は企業と大学がそんなこんなでリンクしてた神話（笑）の時代があったかもしれんが、
実態が浮き彫りになってからはそれもないのーｗ
教授の顔パスで就職なんて景気のいい話は最近めっきり聞かないなｗ

デザインパターンを使う者がオブジェクト指向を理解していないと言い切るところがすごいな。
アンチはデザインパターンを否定しているがデザインパターン肯定派はオブジェクト指向を否定していないところに気づけ。
大規模プロジェクトではパターン化しないと立ち行かないことも知れ。

>>292
何言ってるのかわかんないけど、オブジェクト指向は覚えた方がいいよ。

>>292
俺も何言ってるのかわからないけど、こんな実装よりのパターンが
大規模プロジェクトなんかで役に立つわけが無い。

まあ、結城先生の「ギコ猫とデザインパターン」を読んで
笑える様になる事を目指すのが最初かな。
あれは、デザパタを知ってる人じゃないと、その面白さに
気付かないシロモノだからね。

>>295
アンチにはとうてい理解できないだろうね

>>295
てか、デザインパターンって日本語で言えば定石でしょ。
カタカナ語が多いから少し高尚な感じがするけど、
それに惑されて勘違いしてる人多いんだよね。
言ってる事は常識的な話で、とりたてて騒ぐもんじゃない。

>>297
それがわかってないから、
騒ぐ奴がいるんだ

>>293-294 脳内で実装不可能な設計でもやってなさい

レベル低いのが毎日粘着してるな。
２ちゃんだからしょうがないけど、本当にくだらねぇ

>>293-294
脳内なら、好きなように設計できるぞ。デザインパターンなんてものはない。
あるのはオマエの敬愛してやまないオブジェクト指向のみだ。やったな！

あのさ、本当にバカ過ぎて判ってないみたいだからはっきり言うけど、
ろくすっぽ勉強もせず書籍も読まず人の意見にも従わず、
ただ思いつくままの妄想をたらたらたら書き連ねて、
十年一日のごとく同じ低レベルな議論を延々やっても、
まるっきり無意味だぞ、おまえの人生。

普通「意見を言う」とは、己で己を磨き、己を律し、周囲と協調する努力をした上で、
集団に対して貢献をするためにやる行為だ。
周囲も見えず言葉と概念の結びつきもいい加減なのが脳内妄想をタラタラ垂れ流すのは
「キチガイ」と呼ぶんだぞ。

おまえに「キチガイ」の語源が判るか？
一般常識や確立した概念、周囲の意見とすり合わせる努力をしない＝考え(気)がまるっきりズレズレ＝気違い


これを読み終えたら、もう二度とスレを荒らすのをやめろ。

2ちゃんで人生とは・・。

腐った魂の臭いがする

>>302
誰に言ってるんだ？

おまえ

アンチってゲームプログラマーに多いかもしれない。
ゲームはモデリングに関しては、あんまり悩む余地はないからね。
#表面的にはね。本当は工夫のしようはいくらでもあるんだけど...

昔、不本意ながらゲーム開発のプロジェクトに参加させられたことがあって
そのときは苦労した。

私：「なんでclassのメンバーを何でもかんでもpublicにしちゃうわけ？」
Ａ：「だってpublicじゃないとアクセスできないじゃん。」
私：「．．．」

私：「なんでこんなにグローバル変数があるのさ？ちゃんと考えた？」
Ｂ：「だめ？どっからでも参照できて楽じゃん。」
私：「．．．」

こんなのは可愛いほうで、ここには書けないようなヒドイこともたくさんあった。
彼らのプロジェクトにデザインパターンなんか導入したら、発狂もんだろうな...
「構造体に関数がくっついたのがオブジェクト指向。それ以上でもそれ以下でもない。」
みたいなことを涼しい顔してのたまうオジサンもいたし。orz

デフォルトNGワード：ア　ン　チ

こんな下らない話タラタラ書くのは、どっかの同人作家崩れのデブヲタなんだろうな

>>307
学習の敷居に発狂、成果の大きさに発狂、どっちだｗ

＞それ以上でもそれ以下でもない
この表現好んで使う奴いるよな。かっこいいこと言った気分になるらしい。

しかしム板にはID表示されないんだな。
お笑い板とかならむしろ表示しないほうが逆におもろいけど
議論が必要なこういう場ではID必要だろう。いろんな意味で。

>>181の訳

Monadicプログラミング・パターン

「Monadicプログラミング」とは、(関数言語の文脈で)Monadが理論化されるずぅっと前から(訳注1:未確認…)、関数言語プログラマが使っていた半ば常識的な「デザインパターン」の、
新しい高級な名前に過ぎません。

(状況を説明するために)
とりあえず複数のコマンド列を実行する関数が欲しいと仮定します。
しかし困った事に(副作用のない純関数言語の)関数では、単に(何らかの式を)評価(evaluate)して純粋な値(pure value)を返す事しかできません。
あなたがすべきなのは、評価結果として実行したい複数のコマンド列に相当する「単一の値(a value)」を返すような関数を得る事です。

そんなわけで(純関数言語におけるMonadicプログラミングの)デザインパターンは、
　　各関数は通常の引数/戻り値の他に状態値(state value)を受け渡す、
という内容になります。
ただしこのパターンにはいくつかの制約が課せられており、例えばその一つはこうです：各状態値は、ただ一度だけしか使ってはならない

コマンド列を順次実行するには、各コマンドを関数化して、引数として現在のWorld's stateを受け取り、戻り値としてコマンド実行後のWorld's stateを返すようにする必要があります。
例えば２つのコマンドの順次実行は、最初の関数から次の関数への状態受け渡しとなります。

Monadについて考える場合には、他にもいろいろ追加すべき要素があります。。。

そしてこの「デザインパターン」は、圏論(Category Theory)として知られる数学の一分野に由来する数学概念であり、この概念は圏論で「Monad」と呼ばれている事が判明します。

原文脚注：圏論とは、言わば数学的なデザインパターンの研究です。
実際はそれ以上のものなんだけど、とりあえずコンピュータ・サイエンティストが圏論を研究する時に、このような考え方が良い直観を与えます。

(訳注2: 本文後半、数学概念の説明に関して、後続レスで議論あり)

再利用技術を否定するアンチ君はきっと、
受注したシステムの著作権ごと売り渡してしまい
毎回1から作り直してる零細ソフトハウスにお勤めなんだろう。

OCaml and Design Patterns
　　　　[Caml-list] OCaml and Design Patterns , 2004-10
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2004/10/a5a65e58429e3175fee88dfb7e06c135.en.html
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2004/10/503304c95e2ccd073b446a2d57d8e326.en.html
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2004/10/20a3988025ff8e418742124059d1a89a.en.html

[生成に関するパターン]
Abstract Factory
　　　　[comp.lang.ml] Abstract Factory in OCaml (was Re: record vs. class?) , 2004-10
　　　　　　http://groups.google.co.jp/group/comp.lang.ml/browse_thread/thread/37033101d734c2cc/5055cddf67f8f817#5055cddf67f8f817
Builder
　　　　([Haskell] how to write a list builder? fixpoint? , 2004-06)
　　　　　　http://www.haskell.org/pipermail/haskell/2004-June.txt
Factory Method
　　　　[ocaml_beginners] Re: Matching on objects , 2002-02
　　　　　　http://caml.inria.fr/pub/ml-archives/ocaml-beginners/2002/02/61cda1dab8aeda9996b97cd479ebcea9.en.html
Prototype
　　　　未
Singleton
　　　　[Caml-list] How to implement "Singleton" design pattern? , 2002-08
　　　　　　http://caml.inria.fr/pub/ml-archives/caml-list/2002/08/cc5cc0c6d5c3d741fda2283751f89dfd.en.html

[振る舞いに関するパターン]
Observer
　　　　OCamlマニュアル 5.3章に、Observerパターンの説明がある。
　　　　　　http://caml.inria.fr/pub/docs/manual-ocaml/manual007.html#htoc49

以下、未

[構造に関するパターン]
　　　　未

結論1： オブジェクト指向拡張のなされた関数言語 (OCaml)とデザインパターンは両立しうる　(>>314)
結論2： 関数言語の世界でも、熟練したプログラマーが使うノウハウは
　　　　　イディオム、デザインパターン、プログラミングスタイルなどと呼ばれる形で蓄積されている。
　　　　　例えば純関数型言語Haskellを特徴づける Monadicプログラミングも、その一例である。
結論3： デザイン・パターンを「設計上よくあらわれるパターン」という一般概念として考える場合、
　　　　　それは全てのプログラム開発で発生する事象である。
　　　　　デザイン・パターンなど必要ないという人物は、単にプログラミングをした事がないだけである。

>>310 成果の大きさに発狂だといいんだけどね...

あと、一応フォロー入れておくと、プロジェクトに一人だけＣプログラマーとしては
優秀な人がひとりだけいた。彼にはほんと助けられた。
でもせっかく役割分担しても、役割の難しい部分は巡りめぐって彼の元に到達して
いて、
はたで見ていてかわいそうだった。

プロジェクトが終わり、彼が充実感を得たのは理解できたんだけど、
その他の烏合の衆までが充実感を（錯覚して）感じているのに正直ムカついた。

アンチはサーバサイドアプリケーションを作ったこと無いに一票。

>>312補足

Monadicプログラミングの片鱗らしきものは、
例えばFortranで大域変数の使用を避けて関数プログラミングに徹する事で、得る事ができる。
そう、Fortranの作者Backusは、関数プログラミング言語FPの作者でもあるんだ。

また、中島秀之先生(現在はこだて未来大学長)のProlog/KR本に載っている「多重世界機構」
(アイデアの源泉はたぶんミンスキーの「フレーム理論」)も、
Monadicプログラミング・パターンの実例なんだ。

あのさ、俺今気づいたんだけどさ、っていうか今更気づく俺が馬鹿なんだけどさ、
みんな分かってると思うんだけどさ、

このスレってデザインパターンが必要か否かの議論じゃなくて、
必要だと感じる人達が集まって、よりよいデザインパターンの使い方とか
新しいパターンとかについて議論する場所じゃないの？？

別スレとして
「デザインパターンは本当に必要か？」
「プログラミングスタイルを語るスレ」
みたいなの立てたほうがいいんでない？

今の現状じゃぁデザインパターンの議論にすらたどり着いてないじゃん。
こんな低クオリティ見てらんない。
Ｃ言語のスレで「本当にＣ言語は必要か」なんて議論、普通しないだろ？

>>307,>>310,>>316
デザパタ関係ねぇじゃん。スレ違いうざい。
愚痴はプログラマー板に書け

NGワード：発狂

>>316
彼が感じたのは充実感でなく開放感である気がします。気がするだけです。

ド素人でもゴリ押しで動くものが作れてしまうところがプログラムの怖いところ。
それで妙な自信を持たれても困るんだよぅ。
彼らの自信を打ち砕くには、涙が出るほどに素晴らしいソースコードを見せる以外にない
と思うが、たぶん見てくれないだろうなぁ。必要ない、って言って。

>>319
粘着してるアンチに言ってくれ

>>320
スマソ。

確立したベースがないが故に混沌が生まれる現実
↓
デザインパターンで解決

というまとめで許してくらさい。短絡的とか言わないで。

>>322 ああ...そうかもしれない。orz
私自身も達成感より開放感のほうが勝っていたなぁ。

スレ違い。さっさと出て毛

>>326
君は肯定派？否定派？

>>307,>>310,>>313,>>316-317,>>322-325

スレ違いの話題でスレを荒らすな。
さっさと出てけ

否定派が図星を指されて荒れているような。

>>323
おまい煽るのやめれ。

あと>>230みたいな子供っぽいレスもやめてくれ。
いつまでもくだらない議論が続くから。

>>319の言うとおり、デザパタ否定してる奴は専用スレでも建ててやってくれ。
このスレでデザパタは必要かどうか言及するのはスレ違い。

>>330
> >>319の言うとおり、デザパタ否定してる奴は専用スレでも建ててやってくれ。
> このスレでデザパタは必要かどうか言及するのはスレ違い。

デザインパターンが、所謂定石だとしたら、使われている用語が不味いと
思うぞ。なぜにあないな、カタカナ語なんだろう？もっと普通に書ける
と思う。

>>319
なんかもう音楽理論とかデッサンとかと全く同じ流れやね...
理論なんて必要ねえよセンスさえあれば。
ってそういう議論は別スレに隔離ってのが定説。

>>331
そんなにカタカナ語ばかりか？

まぁ下手に和訳されると
海外の人とデザインパターンを共有したいときに、
元の英語を覚え直さなきゃならん手間が出るから
むしろカタカナのままのほうがいいとも思うが。用語とか固有名詞とかはね。

>>331
日本で作られたモノではないのだから仕方ないだろう。

和訳は紛糾するだろなぁ

というかプログラムを書くのにサポートされている文字が
アルファベットのみであることが多いから、
海外の人と〜とか言う以前に、やっぱり用語はカタカナ（英語）のほうが
プログラムに書きやすいと思う。

336は333の続きね。

イディオムとかアルゴリズムとかだってカタカナ語だが、そんなにカタカナって不味いのかね？
わけわからん

デザインやパターンやオブジェクトやパラダイムやメソッドやクラスや・・・

カタカナがどうこう以前に、
外国人と一緒に仕事するときは英語を使わざるをえない。
# 英語苦手なのに・・・大変だよぉ

(´･ω･｀)話がそれとるがな

訳といえば、PoEAA日本語訳の変なのをどなたか何とかして下さい。
データ”変換”オブジェクトとか”軽（重）”オフラインロックとか…

ゆるロック

ヒドいよね…。パターンの恩恵を半分失ってるに等しいと思う。
名前を訳してしまうこと自体犯罪に等しいのに、ましてやあのセンスはなんだよ。無期懲役モノだよ。
レビュー見ただけで買う気が萎えたんで読んでないけど。

がんばって英語版読むさ…。

日本語文献では一般的になっている言葉だが、
悲観的ロック・楽観的ロックという用語にも違和感を感じる。

Sunのドキュメントの
配備（デプロイ）
配備解除（アンデプロイ）
配備記述子（デプロイメントディスクリプタ）
要求（リクエスト）
応答（レスポンス）
本体（ボディ）
持続性（Persistence）
にも違和感を感じるよ。
「要求の本体」って何かと思ったら「(HTTP)リクエストのボディ」だもんな。

>>334
そは訳したとはいえない。カタカナ語も一緒。
デザインパターンやってる人から、こんなに
ベタな反発くらうとは思わなかった。

>>345
別に「うまく訳す」ことはないんでない？
カタカナ文字で大げさと感じたならそれはしょうがないけど。
まあ、とにかくデザパタ本の日本語訳が良いか悪いかはスレ違いかと。

というか、最終的に日本語に置き換えてもあまり使われない希ガス。
特にオブジェクト指向用語など。たとえば「多態性」とか。
解説サイトではみんなポリモーフィズムだかポリモルフィズムだかで呼ぶし。

すっごい亀なんだけど、意見させてくれ

＞500 ：デフォルトの名無しさん ：2005/06/12(日) 02:45:47 
＞ ツリー状のデータ構造を実現するにはどうすればいいか？
＞
＞・OOデザパタ馬鹿
＞それはねえ、典型的なCompositeパターンでねえ、
＞抽象クラスを1つ定義して、それを派生して2つの具象クラスを定義して、、、(以下延々能書き続く)
＞
＞・簡単なものは簡単に実現する普通のプログラマ

例 1: 「俺は Adapter パターンを使ったわけじゃない。アダプタを作ったら、たまたまソックリになっただけだ」
例 2: 「俺は Mediator パターンを使ったわけじゃない。統括管理するクラスを作ったら、たまたまソックリになっただけだ」
例 3: 「俺は Composite パターンを使ったわけじゃない。木構造を表現したら、たまたまソックリになっただけだ」

重要なのは、『Composite パターンを使わなければ木構造が表現できない』 のではなく、
『木構造を表現しようとすると、Composite (or Decorator) に自然と近くなる場合がある (ならない場合もある)』 ということ。

俺は 『パターンからコードを作る』 のではなく 『コードがあると、そこにパターンが見えることもある』 のだと思っている。
デザパタはリファクタリング時に使う物かもしんない。


おまけ: 「俺は Tree パターンを使ったわけじゃない。木構造を表現したら、たまたまソックリになっただけだ」

デザインパターンはプログラミングテクニックの様に自己内で完結するものじゃなくて
不特定多数の人間の間で「特定の手法」(設計)を明示化する事によって
設計全体を理解しやすくする為のものじゃないの？

>>348 の言うように、ある実装の形が
偶然「特定の手法」と一致したとしても、
明示化しなければデザインパターンの理想には叶っていないのでは？

「C++プログラミングの筋と定石」と「GoF本」を読み比べてみることをお勧めする。

分かりました。読み比べてみます。

>>349
＞不特定多数の人間の間で「特定の手法」(設計)を明示化する事によって

「対面している問題と、その解決案の１例との繋がりを不特定多数の間で共有」 なら納得。
っていうか元々こう考えてた。


＞偶然「特定の手法」と一致したとしても、明示化しなければデザインパターンの理想には叶っていないのでは？

もちろん。だから 「あ、ココは前に使った ○○ を使おう」 って発言が出せる筈。

新しいパターンやパターン言語の将来を語るのではなく、
デザインパターンの定義をぐちぐちやってるあたりが悲惨だな。
最近とんと名前聞かないけど、JPLoPもこんな感じなのかな。

http://pc8.2ch.net/test/read.cgi/tech/1119348596/

隔離スレ作ったから、今後はスレ違いの荒らしはスルーしろよな。

>>354
ナイス
ようやく普通の話が出来るな

>>354
神。
冷静に考えると、何故今まで隔離スレがなかったのか謎。

>>354-356
ナイスつーか正直、対処がガキっぽい。
彼が本当にデザパタの存在意義を言及したいなら自分で作るっしょ。

>>350
分かりました。読み比べてみます。

あのさ、悪いんだけど「デザインパターン」とは「定石」か否か？
つう議論も引越してもらえないかな。
それ、デザインパターンがわかってない人が重箱の隅突っついてるだけの
肝っ玉ちっさい議論なんだけど

>>357
>ナイスつーか正直、対処がガキっぽい。

どうしろっていうんだよ・・・

私は２つに分かれて議論したほうが良いと思っていたので、今回の措置は歓迎です。
ってこの話題ももうやめましょうね。

>>359
すまん。うまく隔離できてるっぽいね。
ああいう奴だとスレ作っても移動してくれないかと思ったので言ってみた。
ってことで、この話題はもうやめよう

デザパタ否定厨にお願い。
クライアントアプリやスタンドアロンアプリじゃなくて
デザインパターンを使わないWebアプリケーションの設計の具体例希望。
悪いけど、超初心者が書いたスパゲッティコードのようなものしか想像できない。
あんたの言う、「オブジェクト指向で設計すればデザパタ不要」が全くイメージできない。
フォーマットはUMLでいいよ。

>>362
http://pc8.2ch.net/test/read.cgi/tech/1119348596/
こちらへどぞー

>>289
＞何寝ぼけたこといってんの？
＞>>285の内容は全然設計と関係ない話じゃない。

「先人が発明したパターンを学び、設計上で再発明をしない」っていう話のどこが設計と関係ないんだよ。
抽象レベルで話しても理解できないアンチパターンバカのために、圧縮技術を具体例に挙げたんだろうが。
メタファーとか比喩とか全く通じないやつってほんと知能が低いと思う。>>289
だから、抽象の抽象って理解できないんだろうなぁ。ある意味高度な知的活動だから。
たぶんポインタのポインタも理解できないから、アンチC/C++言語でもあるｗ

>>364
http://pc8.2ch.net/test/read.cgi/tech/1119348596/
こちらへどぞー

だから最初から分ければいいといっておいたのに。
お前らときたら。。。

だからそーゆー不毛な発言は慎めって。
あなたがそう思ったなら、あなたが実行してもよかったはずだ。

あーあ、隔離しちゃったらDAT落ちしちゃうのに。

>>368
http://pc8.2ch.net/test/read.cgi/tech/1119348596/
こちらへどぞー

・あるオブジェクトAから特定要素を取り出してオブジェクトを作成する
・上記の取り出した情報をオブジェクトBに適応する

みたいなパターンってありますか？

これから、命名するところです

俺ならMLでスマートに書くんだけどね。

>>372
　>>312-315

>>353
そうなっちゃう原因が、プログラミングを良く知らない人間が、
翻訳してるのか、日本語を知らない人間が翻訳してるのか？
どっちか分かりかねるが、言葉の問題だと思うんですよね。

デザインパターンの本読んでも良く分からないって人は、
言葉に困ってるだけか、
まだ新人か、
使いもしないパターンばかり説明されてるか？
ですよ。

例えば、Widgetって何だよ？
ってところで詰まってたりする。

>>375
そうですね、例えばCOBOLで業務系アプリ作ってる人にとっては、
Widgetと言われても困るわけです。

これは、デザインパターンが発想された大本、建設業界で考えても
一緒で、ビルの設計してる人に、土木のパターンを説明されても
困るわけですよ。

一番肝要な、パターンの使用場面の説明が無く、まるでアルゴリズム
集のように書かれてるのが問題ですよ。
そして訳が、主語が訳されてなかったり、訳せないなら説明くらい付けろ
って思うんですが、英語の説明を日本語に文字コード変換してる程度の
訳しかしてないんですよね。

だから、無理にパターンを使うなんて、本末転倒な話になってしまう。
一通り本読んでおいて、プログラミングでこれはどーしようなんて時に
パターンの本を開いて解決する。ってのがデザインパターンの本来で、
デザインパターンのエキスパートなんて存在する分けないのに、日本では
どうもそんなイメージで語られる人間が多くて困ります。

デザインパターンは新人ちょっと過ぎが、迷わないための仕組みなんですから。

>>376
すばらしい分析です。特に訳書批判部分。
で、Widgetって何？

>>377
揚げ足鳥パターンですね。

>>378
あ、ひょっとしてあなたもwidgetで困っている？

辞書に載ってないのでググッてみました。define:widgetで。
A standardized on-screen representation of a control that may be
manipulated by the user. Scroll bars, buttons, and text boxes
are all examples of widgets.
だそうです。

難しく考えないでも、Windowsで言うコモンコントロールをイメージすればいんでない

>>381
ぶっちゃけそれで良いとは思うけど、デザインパターンの本だとか
に出て来るWidgetsクラスてのは、Windowsで言うコントロール程
多機能化されてないので、このX11WidgetsをWindowsのコントロール
並にするてな話の中でデザインパターンを説明してたり。

この辺の説明がなぁ・・・

デザインパターンを混乱に陥れてると思う。

Widgets：（名前が分からない［思い出せない］）何とかいう部品

つまりな、「えーと、アレ、アレ」だよ。

>>370
A，B のモデルとして適切かどうかわからないが，
A の中の取り出したい特定要素を a というオブジェクトでもつ様にして，
a を prototype にして a' を作って B に渡したらいいんじゃない？

>>370
ObjectA a = new ObjectA();
ObjectB b = (ObjectB)Factory.newInstance(a);
オブジェクトＡからＢを生成しちゃってるけど、こういう事ではなくて？

>>370は、下記の定義をちゃんと説明しないと、他の人が回答しようがない。なんなら英語で書いてみて。

1.「オブジェクトＡから『特定要素を取り出し』て『オブジェクトを作成する』」
　(1)オブジェクトから特定要素取り出し　とは、
　　　オブジェクト中の特定のインスタンス変数の取り出しですか？
　　　それとも、コレクションから一つの要素を取り出す事ですか？
　　　それとも、Compositから一つの構成要素を取り出す事ですか？
　(2)オブジェクトを作成する、とは、上記で取り出した「特定要素」が、
　　　元々オブジェクトで、それをクローンして新しいオブジェクトを作るという事ですか？

2.「『上記の取り出した情報』をオブジェクトＢに『適応』する」
　(1)上記の取り出した情報　とは、
　　　1(1)で取り出した「特定要素」の事ですか？
　　　1(2)で作成した「オブジェクト」の事ですか？
　(2) オブジェクトＢに適応する、とは、
　　　新たにオブジェクトＢを作成するのですか？
　　　それとも既存のオブジェクトＢに、2(1)を追加/代入するのですか？

・・・まぁ俺もPrototypeかFactoryを連想するわけだが

>>358
掘り返してすまんのだけど、デザパタって定石みたいなものでない？
どうわかっていないのか聞きたい。

今後、新規に人が来て「デザパタは設計だろ？」とか聞いてきた時に、
また、「いや違う、定石だろ」だの、なんだのの話でループしてしまうと思うから、
その時にみんなが納得できるレスを返せるよう、この辺は明確にしておきたいんだけど。

その話は隔離スレでどぞー

>>388
隔離スレへ誘導するほど知識ない奴が書き込むんじゃない。

まぁまぁ...おちついて。

個人的には，デザインパターン＝「○○○」
みたいに置き換える必要はないと思ってます。

一方、例え話のようなものを他者に要求された場合は、
以下のようにしています。

「粘土で塑像するとき、粘土だけで積み重ねていくのもいいけど、
骨格があってそれにぺたぺた貼り付けていったほうが楽ですよね。
それに粘土だけだと作りたいと思っていた形にするのが難しい。」

「デザインパターンはその骨格に相当します。
あなたが作りたいと思っている造形（＝アプリケーション）に適した骨格選び、
その骨格に肉付け（＝実装）していくことで効率よく作業を行えます。」

「だたし、あなたが欲しているのは骨格ではなく、それを利用した完成形で
あることをお忘れなく。まるで粗探しをするように、
使えそうな骨格をかき集めることに夢中になる人もいますから...（以下続く）」

みたいな感じになってとても一言では終わりません。
で、やっぱりデザインパターンはデザインパターンでよいのではないかと...

#この話もこれで終わりにしましょう。

>>390
「デザインパターン」を「フレームワーク」に置き換えたほうがしっくりくるな。

>>391
あー...その...
1つのたとえ話としておいてください。
# 終われない。

>>391
禿同意。
この話もこれで終にしましょう、とか偉そうに言うくせに頓珍漢なんだよなー。

>>392
そんなレスつけるとこみると、本気で勘違いしてる。
とおもう。

デザインパターン≒骨格という例えは、よくありませんでしたね。
一つのアプリケーションに何個も骨格があることになってしまいますから...
視点が局所的になってました。

>>390
たとえ話はあんまり得意じゃないんだけど、あえて言うなら骨か？

骨を選んで骨格を作って（設計）、
その骨格に肉付けする（実装）って感じ？

デザインパターンをあえて言い換える必要はないとするのは同意。

>>395-396
デザインパターンそのものが、建築でいう江戸間関西間2X4を
ソフトの世界で使うように造語したもんだから、言い換え可能だよ。

高尚でも何でもないのに、高尚ぶりたがる奴が多くて、せっかくの
概念がだいなしだと思う。

>>397 それって言葉のせいかな？
例えば「定石」と言い換えたって高尚ぶりたい人は、そうするよ、きっと。
それに「デザインパターンを「○○みたいな物」って言い切っちゃうと、
その「○○みたいな物」から誤解が生じる可能性もあるしさ。

ってホントにやめないか？

>>398
はぁ(ため息)

やめるのは、君の方だってことが分らないのか？

俺ならMLで簡潔に書くんだけどね。

>>387-400
平日昼間から白熱した議論を展開している方が約一名居られるようですので、
新ｽﾚを立てました。
あちらで思う存分議論をして下さい。

〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119423033/l50

デザインパターン⊃フレームワーク
だと思うが。
いちいち噛み付くなよ。
話が逸れるにしても、もうちょっと紳士的な議論はできないのか。

>>401
ｺﾞﾒｿ

分離スレ

〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119423033/l50
こちらでどぞー

俺ならMLでスマートに書くからデザパタなんか必要ないんだけどね

>>405
　>>312-315

〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119423033/l50
続きはこちらでどぞー

どんどん増えてゆく隔離スレ

ひろゆきの２ちゃん支配は、分割統治が原則だからな

スレ立て厨は、この間からの議論厨よりタチが悪いな

まさにデザインパターンだな

>>409
ご謙遜ですか・・・

デザパタスレの中心で脱構築

>>386
>>370です。今帰宅しました。

1.(1) オブジェクトはメンバとしていくつかプロパティを持っていて
　　　その中からコピーするのに必要な情報（プロパティ）を取り出すという意味です。
1.(2) クローンではなくて上記ののようなコピーに必要な情報を保持しておくオブジェクト
　　　を生成するという意味です。
2.(1) 1.(2)で生成したオブジェクトのことです。
2.(2) 新規で作成することもあれば、既存のオブジェクトに対して保持しておいたものを
　　　設定します。

Prototype、Factoryについて調べてみます。
ありがとうございました。

>>412
よーし、パパ記念に隔離スレたてちゃうぞー
〔隔離〕デザパタスレの中心で脱構築〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1061947883/l50
続きはこちらでどぞー



つくってねーよｗｗｗｗｗ

>>413
乙かれちゃん。
1(2) ValueObjectとかDTO (DataTransferObject)じゃないかなぁ。

>>413
オブジェクトＡ→状態オブジェクト
この流れは生成に関するパターンから拾える可能性が高い。

状態オブジェクトをオブジェクトＢに適応する部分は両者の
関係がもう少し詳しく分からないと何とも言えない。
両者は＝なのか⊆なのか⊂なのか、そしてオブジェクトＢ
は固定なのか変動の余地があるのか？

「状態オブジェクト」というあまりポピュラーではない単語の定義はなんですか？

このスレの主旨でいけば、Stateパターンのはずなんだけど、
一連やり取りの文脈上は、オブジェクトの状態の一部のスナップショット、強いて挙げるとMementoパターン？

>>417
特に深い意味はない。
「コピーに必要な情報を保持しておくオブジェクト」という意味で使っただけ。

>>418
いや、そういう意図は全然なかった。
一応、パターンを表す時にはローマ字表記で統一してたんだけど
事前に説明がないと伝わらん罠orz

ぐぐってみると、
SunがJavaのjava.util.EventObjectをイベント状態オブジェクトと称していたり、
M$ ASPのHttpWebRequest/HttpWebResponse(wを「状態オブジェクト」と呼ぶ人が居たり、
M$ ASPのセッションオブジェクトを「セッション状態オブジェクト」と呼ぶ会社があったり（ｗ、
いろいろヤバイ表現が転がってるな。
・・・もしかしてMonadic プログラミングとか意識してる？（ｗ

>>421
そこに上がっている例のうち、EventObject, HttpWebRequest　は、
「要求のカプセル化」という観点に着目すると、一種のCommandパターンだな。
ただし後者は「要求」といっても「HTTPプロトコル」レベルで抽象度低いから、
Commandとは言いくいような気がするが。

>>418
オブジェクトを再現するのに必要なデータを保持ってことなら
Mementoだろうね。

俺ならデザパタもML風に定式化するんだけどね。

で、>>424以外誰も読まない

>>424
　>>312-315

プログラム板が荒れているため、IDを導入するか検討中です。
賛成の方も反対の方も、このスレで自分は賛成か反対かをお書きください。

プログラム技術板に強制ID制を導入すべきか否か
http://etc4.2ch.net/test/read.cgi/vote/1118144381/

理由などの記入は別に構いません。
<<賛成>>か<<反対>>かだけ御記入頂ければ結構です。
ちなみに、当たり前ですが運営の方にIPが見えているので、1日ごとにIDが変わるからといって多重投稿しないでください。

デザインパターンを参考に、ウィンドウシステムのフレームワークを作ってみました。

たとえば
Button の派生で WIN32_Button, X_Button を作り、
WindowFactory::createButton でこれらを生成します。

このウィンドウをそのまま使う分にはいいのですが、
アプリ内のコードで Button を継承したボタンを作りたいときに
WIN32_Button または X_Button のクラスを直接継承しなければならなく、
プラットフォームを意識したコードになってしまいます。
この問題を解決するためにはどうすればいいでしょうか。

一応、Strategy的にイベントをフックできるようにしてるので
継承しなくても多くのことはできるのですが、
メソッドのオーバーライドをしたいときは、やはり継承したほうがいいように感じます。

相変わらず意味不明なことを言ってるな。特にこのあたり。
　＞一応、Strategy的にイベントをフックできるようにしてるので
　＞継承しなくても多くのことはできるのですが、
　＞メソッドのオーバーライドをしたいときは、やはり継承したほうがいいように感じます

・「Strategy的にイベントをフックできる」って何それ？
　イベントハンドラーをStrategyパターンで与えるという意味か？

・「メソッドのオーバーライドをしたいときは、やはり継承したほうがいい」って何それ？
　継承していないクラスで「オーバーライド」できる言語を使ってるのか？
　プロトタイプ・ベース言語とか（笑

解答１
　もし、抽象クラスButtonのインタフェース(method)だけで
　Win32版、X版の機能拡張を実装できるのならば、
　(例: ボタン外観のカスタマイズという拡張を行うとして、
　　　　外観のカスタマイズに必要なインタフェース(method)が
　　　　全てButtonクラスに揃っている、等)
　単にWin32ButtonとXButtonを拡張し、
　その拡張したクラスをFactoryが生成してやれば良い(はず。Liskov置換則あたりかな)
　
　　　　　　　Button　　　　　　　　　　　　WindowFactory
　　　　　　　　 △　　　　　　　　　　　　　　　：createButton()　　
　　　　　　　　 │　　　　　　　　　　　　　　　：
　　　　　　　　 │　　　　　　　　　　　　　　　：　WindowFactoryExt
　　　　┌──┴──┐　　　　　　　　 　 .：　　　　　：createButton()
　　Win32Button　　XButton←…………･　　　　　：
　　　　△　　　↑　　 △　　　　　　create　：　　　　 .：
　　　　│　　　　……│ …………………･　　　　 .：
　　　　│　　　　　　　│　　　　　　　　　　　　　　　　 .：
　　　　│　　　　　　　│　　　　　　　　　　　　　　　　 .：
Win32ButtonExt　　XButtonExt ←………………･
　　　　　　　　 ↑　　　　　　　　　　　　　　　　　　　　　：
　　　　　　　　　 ……………………………………･

アプリ側では
Win32Button を継承したクラスと XButton を継承したクラスの両方を
作って、WindowFactory の子クラスで生成を振り分けるってことでしょうか。

目的のボタンの実装では Button のインターフェースしか使用せず、
Win32ButtonExt と XButtonExt の実装が、継承元以外はまったく同じに
なってしまい、無駄が出る気がするのですが、これは仕方ありませんか？

質問が更に空理空論っぽくなってきたな。>>431に解答する前に。
-----------------------------------------------------------------
解答1への注
　要するに解答１は、基底クラスButtonを拡張する事なしに、
　サブクラスの拡張が可能であれば良い。
　(例)では、基底クラスButtonのインタフェースを使って拡張を行うと仮定したが、
　基底クラスのインタフェースでは不可能な拡張を行うなら、
　各プラットフォーム用サブクラスを拡張するしか方法がない。

　Factoryパターンが提供するのは、生成時のサブクラス依存性の除去である。
　サブクラスの拡張に関するソリューションは提供していない。

別の問題として抽象クラスButtonの拡張(サブクラスButtonExt)が必要となる場合は、
・各プラットフォーム用サブクラスの親クラスを変更するか、あるいは、
・ButtonExtを多重継承した、各プラットフォーム用サブサブクラスを作る
必要がある。

-----------------------------------------------------------------
上の注がちょっと難しくなっちゃったんで、もっと具体的に整理して考えよう。
Buttonクラスのプラットフォーム別実装の拡張を、分類してみる。
ケース1. 外観のカスタマイズ
　　Win風ボタン、Motif風ボタン、Mac風ボタン等、
　　ソース上のインタフェースは変わらない。
　　しかし外観が異なるという重要な拡張が行われた、別クラスである。
　　より現実的には、スキン交換用のフレームワークを考えるべきである。
ケース2. 振る舞いのカスタマイズ
　　複数回クリックしないと、on/offが切り替わらないトグル・ボタン等 (RadioButton等)
　　これは、おそらく貴方が「Strategyによるイベントのフック」と言っている方法でできるでしょう。
ケース3. 状態の追加
　　on/partial on/offという三状態ボタンとか、enable/disable、show/hide、といった新たな状態の追加
　　どーだろね。基底Buttonクラスの拡張(サブクラス化)から始めないと難しいんじゃないかな。
　　もちろん、「状態の追加」を容易にするフレームワークを考案する事もできる。
ケース4. その他
　　・・・とりあえず思いつかない。文字入力できるボタンとか、飛び回るボタンとか・・・。

>>431
> アプリ側では
> Win32Button を継承したクラスと XButton を継承したクラスの両方を
> 作って、WindowFactory の子クラスで生成を振り分けるってことでしょうか。

それをアプリ側と呼びたい理由はしらないが、
よーするにそういうこと。

> 目的のボタンの実装では Button のインターフェースしか使用せず、
> Win32ButtonExt と XButtonExt の実装が、継承元以外はまったく同じに
> なってしまい、無駄が出る気がするのですが、これは仕方ありませんか？

はぁ？上のケース1, ケース2であれば、表示コードや振る舞いコードが異なるはずだよな。
あんた、単に多重継承とかダイヤモンド継承みたく、無意味に複雑なケースを妄想して
独りで落とし穴に落ちて喜んでるだけとちゃうかぁ〜アホらし。

お〜い>>428＝>>431、また死んだフリか？

これは単純な例ですが、たとえば

void ButtonExt::setText(str){ Button:setText("["+str+"]"); }

こういうことをしたいってことです。

>>436
　>>432
> 別の問題として抽象クラスButtonの拡張(サブクラスButtonExt)が必要となる場合は、
> ・各プラットフォーム用サブクラスの親クラスを変更するか、あるいは、
> ・ButtonExtを多重継承した、各プラットフォーム用サブサブクラスを作る
> 必要がある。

要するに>>428の質問は、
コアの単純な問題>>436に、
余分な笛や太鼓 (Factory, Strategy, プラットフォーム依存性の分離, 挙句に継承)を付けた、
典型的な混乱した質問ってこった。

いや、そもそも継承による差分プログラミングを理解していないのだと思う。

> 目的のボタンの実装では Button のインターフェースしか使用せず、
> Win32ButtonExt と XButtonExt の実装が、継承元以外はまったく同じに
> なってしまい、無駄が出る気がするのですが、これは仕方ありませんか？

もし実装が丸きり同じサブクラス作るなら、
クラス定義の中身はコンストラクターだけだよな。
本当にプログラミングした事あるのかね。

アプリに依存した Button を作りたいという話なので、
アプリを作るごとに親クラスの変更をしていくのは無理です。

>>439
コンストラクタ以外に、>>436で挙げたようなアプリ依存の実装があります。

>>440-441
　>>437

もしかしたら「実装」の意味で誤解があるのかもしれませんが、
Win32ButtonExt と XButtonExt の実装が同じ、というのは、
これらのクラスで定義されるメンバ関数のコードが同じ、という意味で、
継承元の実装が同じ、という意味ではありません。

>>442
>>440は>>437に宛てたレスのようなものです。
プラットフォームに依存せずに Button の機能を引き継ぎたい、ってことなのですが。

貴方は随分コマメにレスを下さるが、
議論の進め方、単語と意味の結びつきが、
撚れている感がある。

あえて正解を無視し、俺様用語定義で話を進めるのなら、
もっといい板があるのでそこで議論してはどうか？

　　http://etc3.2ch.net/denpa/

唯一、正解に見えたのはこれだけですが。
＞Factoryパターンが提供するのは、生成時のサブクラス依存性の除去である。
＞　サブクラスの拡張に関するソリューションは提供していない。

>>436
　>>432
> 別の問題として抽象クラスButtonの拡張(サブクラスButtonExt)が必要となる場合は、
　(略)
> ・ButtonExtを多重継承した、各プラットフォーム用サブサブクラスを作る
> 必要がある。

>>444
どうせ毎日暇で暇で困っている構ってちゃんだろ。
もう相手にする必要ねぇよ。

>>446
そうだな。
プログラミング用語の認識すら曖昧な厨房相手に
マジレスし過ぎた。

もう寝るわ

>>446
ButtonExtを作るためにButtonExtを多重継承するってのは意味が通らない気がしたので
その文の理解は飛ばしたのですが、どういう意味でしょうか。

>>447
この板は強制fushianasan導入して、荒らしを徹底排除しないとダメだな。
オヤスミ

多重継承嫌なら委譲すりゃえぇーやん。
まったくスレ汚しもいいとこだな

>>450
さすがに全部のメソッドを委譲可能にするのは骨が折れます。
できればオーバーライドできたらいいな、って話で、
その方法があれば教えていただきたいと思い、書き込んだ次第ですが。

質問の内容がくるくる変わる、ズブの素人議論は
下記の隔離スレでどうぞ。

　〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
　http://pc8.2ch.net/test/read.cgi/tech/1119423033/

>>428
Buttonから派生すればいいだけじゃないのか？

class ButtonExt {
　ButtonExt(Button *base_button) : m_base_button(base_button) {}
　Button *m_base_button;
　void Draw() { m_base_button->Draw(); }
　void SetText(string str) { m_button_base->SetText("["+str+"]");
　//などなど。全部の関数を委譲しなきゃいけないのが面倒ではあるが……
}

あ、もう一段追加すればいいだけか。

class ButtonExtBase : ButtonBase {
　ButtonExtBase(Button *base_button) : m_base_button(base_button) {}
　Button *m_base_button;
　void Draw() { m_base_button->Draw(); }
　void SetText(string str) { m_base_button->SetText(str); }
　//などなど
}

class 俺拡張Button : ButtonExtBase {
　俺拡張Button(Button *base_button) : ButtonExtBase(base_button) {}
　void SetText(string str) { ButtonExtBase::SetText("["+str+"]"); }
}

main() {
　Button *base=XButtonFactory::CreateBaseButton();
　俺拡張Button *my_button=new 俺拡張Button(base);
　my_button->SetText("hoge");
}

スレ違い。
議論の続きは下記でどうぞ

　〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
　http://pc8.2ch.net/test/read.cgi/tech/1119423033/

>>453-454
うむむ、やっぱり委譲ですか。
こういうケースにぴったりハマるパターンがあったらな、と思ってましたが。
アプリ側のコードはすっきりするようになったので、これでいいかな、と。
ありがとうございました。
隔離スレで誰かが書いていた、「全ての問題は間接参照をはさめば解決する」という言葉の意味を実感。


//拡張用基底クラス（フレームワークとして用意）
class UserButton : public Button{
public:
　UserButton(parent){ imp=factory->createButton(); }
　virtual void setText(str){ imp->setText(str); }
　//(その他すべてのｲﾝﾀｰﾌｪｰｽを委譲により実装)
private:
　Button* imp;
};


//アプリでの使用例
class 俺Button : public UserButton{
public:
　俺Button(parent) : UserButton(parent){ }
　//たとえばsetTextのみｵｰﾊﾞｰﾗｲﾄﾞ
　virtual void setText(str){ UserButton::setText("["+str+"]"); }
};

main(){
　Button* button=new 俺Button();
　button->setText("hoge");
}

C++で多重継承も書けねぇのか。
悲惨。ついでにスレ違い。
議論の続きは下記でどうぞ

　〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
　http://pc8.2ch.net/test/read.cgi/tech/1119423033/

いつのまにやら、プラットフォーム毎の実装サブクラスの話が消し飛んでるのがご愛嬌だな。
こーゆー展開を「グダグダな似非議論パターン」と呼ぶ。

ようやくパターンスレらしいオチが付いた

UserButtonのコンストラクタ内でFactoryを用いることにより
プラットフォーム依存の実装を隠蔽してるわけですが。

デザインパターンを参考に、ウィンドウシステムのフレームワークを作ってみました。

たとえば
Button の派生で WIN32_Button, X_Button を作り、
WindowFactory::createButton でこれらを生成します。

このウィンドウをそのまま使う分にはいいのですが、
アプリ内のコードで Button を継承したボタンを作りたいときに
WIN32_Button または X_Button のクラスを直接継承しなければならなく、
プラットフォームを意識したコードになってしまいます。
この問題を解決するためにはどうすればいいでしょうか。

一応、Strategy的にイベントをフックできるようにしてるので
継承しなくても多くのことはできるのですが、
メソッドのオーバーライドをしたいときは、やはり継承したほうがいいように感じます。

アプリ側では
Win32Button を継承したクラスと XButton を継承したクラスの両方を
作って、WindowFactory の子クラスで生成を振り分けるってことでしょうか。

目的のボタンの実装では Button のインターフェースしか使用せず、
Win32ButtonExt と XButtonExt の実装が、継承元以外はまったく同じに
なってしまい、無駄が出る気がするのですが、これは仕方ありませんか？

もしかしたら「実装」の意味で誤解があるのかもしれませんが、
Win32ButtonExt と XButtonExt の実装が同じ、というのは、
これらのクラスで定義されるメンバ関数のコードが同じ、という意味で、
継承元の実装が同じ、という意味ではありません。

>>442
>>440は>>437に宛てたレスのようなものです。
プラットフォームに依存せずに Button の機能を引き継ぎたい、ってことなのですが。

ButtonExtを作るためにButtonExtを多重継承するってのは意味が通らない気がしたので
その文の理解は飛ばしたのですが、どういう意味でしょうか。

>>450
さすがに全部のメソッドを委譲可能にするのは骨が折れます。
できればオーバーライドできたらいいな、って話で、
その方法があれば教えていただきたいと思い、書き込んだ次第ですが。

>>453-454
うむむ、やっぱり委譲ですか。
こういうケースにぴったりハマるパターンがあったらな、と思ってましたが。
アプリ側のコードはすっきりするようになったので、これでいいかな、と。
ありがとうございました。
隔離スレで誰かが書いていた、「全ての問題は間接参照をはさめば解決する」という言葉の意味を実感。

パターン名：
　　　　グダグダ似非議論パターン

目的：
　　　　毎日暇で暇で困っている困ってチャンの時間つぶし

方法：
　　　　・良スレに混乱しまくった質問を書き込み、レス住人の反応を待つ。(>>428)
　　　　・質問の曖昧さを指摘されても、己の質問の曖昧さを決して取り除かない。(>>431)
　　　　・解答者が現実的な解答を出しても、それに当てはまらない例を探し、
　　　　　場合によっては妄想に基づく難癖を付けてでも、時間をつぶし続ける。(431, >>436. >>443)
　　　　・解答者が、全ての場合を網羅した解答を出しても、
　　　　　その中に解答がある事に気付かない振りをして、更に時間をつぶし続ける。(>>440-441, >>445, >>448)
　　　　・翌朝になって、自分勝手に設定した解答を自作自演で書き込んでくるが、
　　　　　その解答の恣意性を指摘されてもダンマリで、自分の正しさを主張し続ける (>>453-454, >>456, >>459)

実装例：
　　　　本スレのレス番号：428, 431, 436, 440-441, 443, 445. 448, 451, 453-454, 456, 459

コメント：
　　　　おまえのコミュニケーションは病んでいる。
　　　　その病んだコミュニケーション・スキルで、多くの人に迷惑をかけ続けている現状を恥じろ。
　　　　さっさと心理カウンセラーの所に行って、コミュニケーション障害を直す努力をしろ。

>>456
> こういうケースにぴったりハマるパターンがあったらな、と思ってましたが。
これってDecoratorっていわないかい。

……………　悪　霊　退　散　……………

>>467
平日昼間っから暇そうでいいな。
俺、午後からリサーチャ募集の面談だわ。
いい加減、ダメダメ議論を振るのは勘弁願いたい。

●●●●●●●●●●●●●●●●●●●●●
●　　　　　　　　　　　　 　●　　　　　　　　　　　　　 ●
●　　　　　　　　　　　　　 ●　　　　　　　　　　　　　 ●
●　　　　　　　　　　　　 　●　　　　　　　　　　　　　 ●
　　●　　　　　　　　　　 　●　　　　　　　　　　　 ●
　　　　●　　　　　　　　　●　　 　　　　　　　 ●　　
　　　　　　●　　　　　　 ●　 　　　　　　 ● 　　　　　　 　　　＿（ "''''''::::.
　　　　　 　　●　　　　● ●　　 　　 ●＿＿　____,,,... --‐'''^~ 　　ヽ 　　゛゛:ヽ
　　　　　　　　　●　 ●　　 　●　 ●:::::::::....:""""　　・　　　　・　　. ＼::.　　 丿
　　　　　　　　　　● ●　　　　● ●::::::::::::::::::: 　　　　　 ・　　....:::::::彡''ﾍ::::／
　　　　　　　　　　　●　　　　　　 ●:::::::::::::::::::::::::::::;;;;;,, ---‐'' "^~
　　　　　　　　　　　　●●●●●-‐‐ ''^~

>>469
>>467はニート。

>>466もかなりの暇人だと思うがどうか。

>>470のほうがもっと暇人だろ
ご飯食った後ﾃｨﾝﾎﾟはみでているんだぜ？

>>428の話は、質問の最中に、勝手に元の質問を変えていき、自己矛盾を起こす厨房議論だ
って先生がゆってた

まだこのスレ続いてんのか
いいかげんキエロや

>>456
UserButtonというよりは、それがButtonでいいんじゃないか？
Buttonというインタフェースまで作る必要は・・・あるか。うーんむずいね。

>>476
うわ、勝手に解決してる。('A`)

自分も最初そう思いましたが、
factory->createButton() の返すインスタンスが WIN32_Button または X_Button で、
これらは UserButton の継承としては実装できないのですよ。

UserButton : public Button は処理を Button のインスタンスに委譲しますが、
WIN32_Button : public Button は処理を WIN32_WindowImp (HWNDを保持したモノ) のインスタンスに委譲してます。

ここではボタンを例に出しましたが、実際のところはボタンを
継承でカスタマイズすることはほとんど無いです。

Button* button=getFactory()->createButton(parent,rc);
button->addListener(listener);

実際のところは主にオーバーラップウィンドウをカスタマイズするのに使ってます。

class MyWindow : public UserSimpleWindow, public CommandListener{
　Button* button;
public:
　MyWindow(parent,rc) : UserSimpleWindow(parent,rc){
　　button=getFactory()->createButton(parent,rc);
　　button->addListener(this);
　}
　virtual bool onCommand(wnd){ //CommandListenerのｲﾝﾀｰﾌｪｰｽ
　　messageBox("pushed"); return true;
　}
};

この例ではメソッドのオーバーライドしてないけど、
イベントハンドラを継承したウィンドウを作りたいときに便利っす。ぶっちゃけJavaのパクリですが。

要するに、あんたの>>428の質問はためにする質問で、
継承じゃなくて委譲って言って欲しかっただけなのね。

Pearオブジェクトはどうするつもり？
なんていちいち確認しなきゃならないような
不適切な例を出す貴方のセンスを疑う。
(確かに最初から気にはなってたよ、でもアンタ説明してないし)

うんざり

自分は賢いと勘違いしてる初心者がやらかしがちな、
「問題設定が不適切かつ、問題設定の説明が不充分な質問」
って奴だな。

自演乙

相変わらず>>480はバカだな。

>>477
ボタンのインスタンスをFactoryで公開するのっていうのがちょっと違和感ある。
そのFactoryは、実装がXかWindowsかを隠蔽するためのものであって、
インスタンス生成の理想のインターフェースとしては
Button* button = new Button(); っていう感じのものだと思う。

内部的に使うだけのものであればFactoryが生成のインタフェースになってもいいけど、
外部の人間に使ってもらうような汎用的なライブラリであれば、Factoryから生成させるってのは、
そのライブラリを使う人間側からすればちょっとなぁってだけなんだけどね。
まあ、今作られてるライブラリを外部に公開するのかどうかは知らんのだけど。


＞factory->createButton() の返すインスタンスが WIN32_Button または X_Button で、
＞これらは UserButton の継承としては実装できないのですよ。
Bridgeパターンつかって、ButtonImplみたいなのをButtonに持たせてみては？
WIN32ButtonImplとXButtonImplをつくって、ButtonからはButtonImplへ委譲するだけとか。
実装用のインターフェース(ButtonImpl)と、外部公開用のインタフェース(Button)をわければできないかな？
外部公開用と実装用をいっしょにしてしまっているからできないのだとおもう。

>477
＞UserButton : public Button は処理を Button のインスタンスに委譲しますが、
＞WIN32_Button : public Button は処理を WIN32_WindowImp (HWNDを保持したモノ) のインスタンスに委譲してます。
とおもったらそういう仕組みにしてるのかな？('A`)
実装できないといっている理由がよくわからん。

トップレベルのウィンドウをそのまま AbstractFactory にしてみるとか

Window *w = new W32Window();
Button *b = w->CreateButton();

アンチが失言待ちか

>>485
失言待ちアンチを無視してアンカーつけつつ話し合い、
失言待ちアンチが必死になる様を楽しもうではないか

>>484
あまり、W32Window()と実装が具体的すぎるのもどうかと。
Xだと、その部分がXWindow()になるのかな？
ＯＳが変わっても互換性が保てるソースコードでないとライブラリとしては厳しいｷｶﾞｽ。

トップレベルがAbstractFactoryってのは、なかなかおもしろいアイデアですな。

>>482
できれば new や delete は隠蔽して、ファクトリーのメソッドに統一したいです。
場合によって new であるか static instance() であるか等の判断を
ライブラリのユーザにさせるのは混乱の元になるので。

createButton が返すインスタンスは WIN32_Button ですが、
型は Button* なので、プラットフォームは隠蔽されます。
WIN32_Button が定義されたヘッダをインクルードする必要もないです。

＞とおもったらそういう仕組みにしてるのかな？('A`)
＞実装できないといっている理由がよくわからん。

Button はボタンのインターフェースを定めるもの、
UserButton が Button をラッパーするもの、
(ﾌﾟﾗｯﾄﾌｫｰﾑ)_Button は WindowImp をラッパーするもの、
という明確な役割があるので、
この関係は壊したくない、ってのがあります。

UserButton の継承で WIN32_Button を作ってしまったら
UserButton の仕様もそれに合わせて変えなければなりませんから。

と、書いてるうちに気づきましたが
factory->createButton が UserButton* を返すようにすれば
プラットフォーム固有のインスタンスは完全に隠蔽できるかも。
でも、自分的には定義と実装さえ隠蔽されていれば十分な気もします。


>>484
それ面白そうですね。思いつきませんでした。
ウィンドウの親子管理が簡潔になるかも。

new や delete を隠蔽したいもうひとつの理由として、
コンストラクタ、デストラクタの前後に初期化や終了の処理を入れたい場合があるからです。
初期化はすべてコンストラクタで行えばいいと思うかもしれませんが、
クラス設計がポリモーフィズムのオンパレードなので、コンストラクタ、デストラクタ中で
目的のメソッドを正常に動かすことは難しいです。
（最新の注意を払えばそれも可能ですが、その注意の手間はけっこうな損失になると思います）

なので、逃げにも近い手段かもしれませんが、クラスによっては

Class* Factory::createClass(){
　Class* ret=new Class();
　ret->init();
　return ret;
}

のような処理をしているケースがあります。（同様に終了処理も）

>>488-489
C++だとインスタンスの生成と解放の部分が悩みの種だよね('A`)
やっぱ最近の言語はＧＣとか付いてるし、言語仕様も高度だから便利だわ。
C++だとコンストラクタでvirtualメソッドが呼べないとか、そういう細かいところで使いづらいことがある。

うーん、あとプラットフォームの隠蔽、インクルードする必要もないっていう話はわかる。
漏れが言いたかったクラス設計の話は↓みたいなかんじかな。
Button = new Button()
　　　　　　 ┗委譲→ ButtonImpl
　　　　　　　　　　　　　　　┗ ButtonFactory
　　　　　　　　　　　　　　　　　　　┣ Win32ButtonImpl
　　　　　　　　　　　　　　　　　　　┣ XButtonImpl
　　　　　　　　　　　　　　　　　　　┗ OsaskButtonImpl

違ったらすまんのだけど、>>428の設計だと↓のような設計だと思う。
Button = ButtonFactory->createButton()
　　　　　　 　┣ WIN32_Button
　　　　　　 　┃　　 ┗ WIN32_WindowImp
　　　　　　 　┣ X_Button
　　　　　　 　┃　　 ┗ X_WindowImp
　　　　　　 　┗ Osask_Button
　　　　　　　　　　　 ┗ Osask_WindowImp
これだと、ひとつのプラットフォームを対応するのに２つづつクラスが増えてしまうんじゃないかな。
上のクラス設計だとXxxxButtonImplをひとつ増やすだけになるし。
まあ、これは個人の好みの問題だと思うけど。

あとファクトリークラスで提供するのって、利用者がなんじゃこりゃとか思わないかな。
少なくとも俺はなんかなぁ。Button::newInstance()とかならいいんだけど。
まあ、これも個人の好みの問題だと思うけど。

２９行か、漏れよくがんばったなぁ('A`)

>>482
> 実装用のインターフェース(ButtonImpl)と、外部公開用のインタフェース(Button)をわければできないかな？
> 外部公開用と実装用をいっしょにしてしまっているからできないのだとおもう。

これは納得。つかJavaのpeerオブジェクトってこんな感じのクラス階層だったと記憶。

で、ちょっと話がよく見えないのは、
1. プラットフォーム共通の拡張コード (>>436) はどうするって話になったの？
　公開用インターフェース Buttonの下に実装クラス(またはサブクラス)作って、そこにメソッド書くのかな。
2. プラットフォーム非共通の拡張コード (>>432の最後の黒丸)はどうするつもりなの？
　結局 >>490上側のクラス関連図に載ってるクラスを全部拡張する必要があると思うけど。

一貫性のない議論を自作自演するような奴に、マジ質問して答えが返るわけがなかろう

>>490
＞違ったらすまんのだけど、>>428の設計だと↓のような設計だと思う。

そのとおりの感じですた。前者の設計のほうがよっぽど簡潔ですね。
っていうかなんで最初からそういう設計にしなかったんだろ…。orz
AbstractFactory とか Bridge とか、なんだか取り入れ方が間違ってた感じっす。
GoF本よく読み返してればよかった…。

今、設計を大幅に変更してます。


>>492
＞1. プラットフォーム共通の拡張コード (>>436) はどうするって話になったの？
＞　公開用インターフェース Buttonの下に実装クラス(またはサブクラス)作って、そこにメソッド書くのかな。

今のところは >>428に書いた UserButton を継承する形にしていました。
設計を変更により、Button の継承で拡張できるようになりそうです。

＞2. プラットフォーム非共通の拡張コード (>>432の最後の黒丸)はどうするつもりなの？
＞　結局 >>490上側のクラス関連図に載ってるクラスを全部拡張する必要があると思うけど。

これを書いてなかったのが混乱のもとになったと思うのですが
ここで言う拡張は、ライブラリユーザ側からの拡張の意味で使ってました。説明不足ですみません。
なので、ButtonExt の下に各プラットフォーム用クラスを作る、っていうことはできません。

拡張メソッドは基底クラスにある既存のメソッドにより実装しています。

>>494
結局あなたとは最後まで話が通じませんでしたね。
私は>>492の2.に関して、現在の議論の状態を聞いている。
あなたが答えているのは、最初の>>428レベルの話に逆戻りしている。
細部が矛盾もしくは不明確だらけで、よく議論が継続しているものだと感心する。

いや、>>492の2.の俺の聞き方や、>>432に関する説明が足りなかった。
>>432最後の黒丸で言っているのは、
プラットフォーム固有クラスの拡張を要する変更の場合には、
- 各プラットフォーム固有クラスの継承/拡張は当然の事として、
- 現在の議論でいうところのButtonImpl
　 もしくは、まだ議論に上っていない、全プラットフォーム固有クラスに共通の汎化インタフェース
　 の継承/拡張も必要だろう
という話だ。上記 2項目を指して、多重継承と言っている。
(Javaでは後者は、必ずインターフェース実装の形をとる)

・・・って、結局プラットフォーム共通の拡張しかできない仕様なのね。
うーむ、問題が発散しすぎていて、明確な解答を出しようが無い話だった。

おしまい

【>>492以前の結論】
　[公開ｲﾝﾀﾌｪｰｽ]　　[実装]

　 　　　　　　　　　 ──→ ButtonFactory->createButton().─────┐
　　　　　　　　　 ／　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .│
　Button class ───→ ButtonImpl abstract class　　　　　　　　　　　　│
　　　△　　　　　　　委譲　　　　△　　　　　　　　　　　　　　　　　　　　　　　　 │
　　　│ﾕｰｻﾞ拡張　　　　　　　　： 抽象ｸﾗｽ　　　　　　　　　　　　　　　　　　 │
　ButtonExt　　　　　　 ┌……┴…………┬………………┐　　　　　 .│
　　　　　　　　　　　　　　 ：　　　　　　　　　　　 .：　　　　　　　　　　：　　　　　. .│
　　　　　　　　　　　Win32ButtonImpl　XButtonImpl　OsakaButtonImpl ←┘
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　生成

注) ButtonImplをｲﾝﾀｰﾌｪｰｽか抽象ｸﾗｽか、はたまた実装ｸﾗｽとするべきかは、
　　 まだ正確な議論は行われていない。

なんだか話が複雑になってきてわかんなくなってきた（＾ω＾；）

>>492
1.について
えっと、>>490の上の設計だとButtonを拡張すればいいんじゃないかな。
そのことじゃない？なんかもうわかんね（＾ω＾；）

2.について
プラットフォーム固有で拡張していくコードは考えてないです。
ある程度、プラットフォーム固有のものは捨て去るしかないとおもいます。
って、そのことじゃない？なんかもうわかんね（＾ω＾；）

あっ、って>>496解決してた？らｽﾏｿ（＾ω＾；）

>497
UMLもどきをASCII図で書くとは・・・。しかし、なぜかとても懐かしい。

すごく低レベルな質問ですが、C++のシングルトンは
普通のグローバルインスタンスでは駄目なのでしょうか？
グローバルインスタンスの方がデバッグがしやすいのですが。
シングルトンの全ての利点よりデバッグのしやすさの利点の方が
でかいと思うのですが。

>>501
スレッドとか関係しなくて、メンテナンス性とか考えずに
それで済むならそれでもいいんでないか

>>501
どういうデバッグのしにくさがあるのか知らんが、
自分で使っていて使いづらいと思ったら、
無理してパターンにあてはめる必要はないかと思われ。

注意深く見たら OsakaButtonImpl じゃねーか。ｵｰｻｶﾃﾗﾜﾛｽ（＾ω＾ ）

>>504
死ね

べつに C でやってもいいじゃん＞＞デザパタ

>>506
それがさ、このスレには、頭の堅い粘着馬鹿がいるもんで、
なかなかそうも行かなくてねえ。

Cやアセンブラのマクロでやろうが問題ないがここで話題にする意味はないな

何を訳の分からんことを・・・
デザインパターンっていうのはオブジェクト指向言語を対象に
考えられたものだから非オブジェクト指向の言語じゃできないんだよ？
ＯＫ？

>>509
ライブラリじゃなくてパターンなんだから、言語に関係なく本質は流用できるだろ。

>>509
LispでOOPしちゃった俺が来ましたよ。

ほう。CLOSかFlaversかな、それともLOOPSかな。
その上でのパターンについて語ってもらいましょうか。

>>509
>デザインパターンっていうのはオブジェクト指向言語を対象に
>考えられたものだから
不合格。

GoFのデザパタは、OOPL限定のデザパタ　だが
デザパタという言葉はOOPLに限定された言葉では無い

お舞ら胴でもいい話でループしまくてますね。
自分はデザインパターン愛用してますが。考え方ね。それでいいや。

俺は、大した知識も経験もないくせに、他人を見下したように偉そうに
語る馬鹿が嫌いなだけ。

俺漏れも。
特に>>516見たいな奴。

俺も。
特に>>517みたいな奴。

俺は>>519が嫌いだよ。。。(;;)

俺は>>521が嫌い…

(T_T)

>>520はツンデレ

>>523は絶倫

いや、結局関数ポインタを構造体で包んで組み合わせればそれらしく出来るだろ？
どうしてもってところはvoid*が必要になるかも知れないけど
そこはassertを使うなりして積極的にデバッグでつぶすなりしてさ

ポリモーフィズムもデザインパターンの一種だからな。

Cだと
同じ型の関数ポインタの配列作ってコマンドパターン風とか
同様のやり方でステートパターン風とか（これは普通配列は使わない）
はわりとありがちだな。

Observer風にコールバック関数を使うのも普通だ。
だいたいは、オブジェクトの替わりに関数ポインタとMagic Cookieとしての
void*ポインタが使われるな。

>>526
フランスとかイタリアとかの料理みたいで素敵だな（○○風）

Cでやる場合はデザパタなんて大仰な言い方はしないし、
昔からのテクニックだからな。
だから〜風。

入社二年目のときにはじめてC++プログラムを書いたのだが、
オブジェクト指向が身についてなくて、クラスは一つも無く、
関数ポインタとコールバック、STL（これだけはなぜか知っていた）
が主な成分の、なんちゃってC++プログラムだった。無論デザパタ
なんて何のこっちゃだ。

しかしVC++5の、まだ出来たてほやほやのバグバグSTLを使うなんて、
今考えれば恐ろしいことをやったもんだ。

馬鹿かお前ら。屁理屈を言うな。
OOPL以外でやるデザパタなんざデザパタじゃねーんだよ。
もう一度出直してきな！

釣り？

釣りだろ。

GoFのデザパタと、GoF以外のデザパタ

ダイアモンド頭？

釣りじゃねーよ。
非OOPLでデザパタやれんのかよ？
やれねーだろ。馬鹿かお前ら？

Java厨というオチでしたか

トリッキー君だろ？尻尾でてるしｗ

>>537
自作自演で書いてるのか、仲間内で書いてるのか分からないけど、
発言ポインターを示さないからどっちがどっちに文句言ってるのか
全然分からない。

非OOPLでデザインパターン？
酔狂も甚だしいなｗ

>>538
535 = トリッキー君

GoF は Interpreter 以外は完全に OOPL 依存だいな

ttp://hyuki.com/dp/dpinfo.html
Balking
Immutable

ざっと眺めただけでも、とりあえず上の２つは、OOP+ 以外の言語でも何の問題も無く組める

======

>>539
「OOP = クラスベース」の意味なら言い直しを要求する

>>541
そうかそうか。お前の言いたいことはよくわかったぞ。

OOP+ ってなんやねん俺

つかさ、本ｽﾚに書くならもっとアップトゥデートな話題にしてくれ。
ここは20年前の話題をノスタるスレじゃねぇーぞ

>>542
逃げ腰発言ﾃﾗﾜﾛｽｗｗｗｗ

>>544
つかさ、ここは君のスレですか。君が気に入る話題じゃないと投稿しちゃいけないんですか。そうですか。

>>544
GoF本自体の更新がとまっちゃってるのにそれは無理な話だぜ兄弟ｗ

GoFのパターンは色々な意味で完成度が高いからな。
ＩＴ関係で5本の指に入る名著だ

ひょんな事から、自然言語の流行と進化について、最近強い関心を持っている。
とりあえずある仮定がテーマなんだが、
自然言語が時代と共に変化していくのと同様、
建築やソフトウェアのデザインパターンも変化が避けられないと考えている。

例えばGoF時代のOOは、Smalltalk〜Mac上のToolKit、そしてX window上のET++といった言語〜GUI系がテーマだった。
ところが90年代に入ると分散オブジェクト分野が急速な発展を遂げ、
ついで1993年Mosaicの登場以降、インターネット上のWebに関する話題が大きなウェイトを占めるようになった。
そして90年代後半〜2000年代に入ると、Javaや.NET上の企業システム応用という大きな分野が出現した。

このような流れでみると、レイヤーとか粒度は多少違うが、PoEAAみたいな企業システムのためのパターンこそが、
今のテーマであり、進化したパターンと言えるだろう。
そして、PoEAAみたいなのから帰納的に最小粒度のデザインパターンを抽出しなおす必要があるのではないか
と思う。しかし、その仕事をGoFのメンバーがやってくれるとは限らない。GammaはEclipseに専念しているようだ。
誰かGoFが示した最小粒度の基底パターンのアップデートに取り組んでみてはいかがだろう？
もし誰もやらないなら、俺がやろうかな（藁
まぁ、SmalltalkとかC++とかJavaとか、言語が変わる度に、実務的な基底は変化するから、アップデートが面倒ってば面倒なんだが

↑に書いたのは、あくまで言語やパターンをとりまく外部環境の変化が主題なんだが、
それだけではなく、パターンに内在しパターンを形成する力となっているものが、
実は多くの人の手を通り年月を経る事で、次第にプログラミング言語への改善フィードバックを起こし、
最終的にはパターン言語自体にも目に見える変化をもたらすと考えている。

上記の話は、それほど突飛ではなく、むしろ当たり前の話に見えるかもしれない。
むしろこれから扱うべき問題は、パターン内部に働き、プログラム言語やパターン言語に変化をもたらす
特性の体系的な把握、そしてコントロールだろう。
このテーマにおいて、自然言語と同様に確率・統計的手法を適用できればいいんだが。

×　変化をもたらす特性
○　変化をもたらす力

こうずらずら書き並べてもらっても何言ってるのかわからないんだよね。

Eclipseプラグイン開発を読んでて思いついたんだが、ホストプラグイン(エクステンション
プラグインに提供する拡張点を持ったプラグイン)を書くのは将来の拡張可能性を考慮し
て予め拡張点を仕込まなければならず、これは(設計が)相当難しい。
これはEclipseのホストプラグインに限らず、拡張可能なフレームワークを書く時に出てく
る一般的な悩みなんじゃないかな？

そこで、FlyweightパターンにAOPを組み合わせる。
これはSeasar2(S2Container＋JBossAOPの方が拡張する側は書き易い気が･･･)を使っ
て実現できる。
そうすると、意図して拡張点を設計するよりは遥かに容易く拡張できる(点として設計する
必要がないというだけで、クラスが強く閉じてると拡張できないし、開きすぎてると意図し
ない影響を受けて動作が阻害されるから、考慮は必要)。

問題は、どこからでもインスタンスを取得できる(複数のクラスで共有される)事でスコー
プの範囲が限定できなくなる(しかし、限定されると拡張できない)点。
今はただの思いつきだけど、掘ってみると何か出てきそうな予感なんだけど、どうよ？

あそ。読解力に問題ありだな。

例えば「ﾜﾛｽ変化」のAA。
あのような変化を思いつく背景には、ナニがあるのか考えてみたらどう？

言葉の変化は、外部の力だけで起こるのではなく、
言葉自身の内側の力、もっとハッキリ言うと「関連と差異の体系としての言葉の性質」が、
言葉の具体的な変形を決めるのではないか。

な〜んて事は、文系の人でも言いそうだが。
それを確率・統計的手法で明確に分析し、さらにパターン言語へと適用するのが、
しばらくの間の俺の目標。

>>552
そこでFlyweightが出てくる理由がまるで説明できていない。失格

>>554
荒らしに反応すんなって。

国家の定義にはいろいろありますが、そのうちの一説。
国家とは国民の安全と利益と財産を保証する最大級の安全保障機関である
という説を取ってみたいと思います。
自然界は弱肉強食、そしてこれは人間の世界でも同様です。
厳しい自然環境、他の部族とも縄張り争いから人は集団を作り、それは村から国へと昇華していきます。
つまり、国家とは自分たちの安全を確保するために作られたものなのです。
しかし、人間には様々な価値観を持っている人たちがいます。
会社や学校でも価値観の違うもの同士が一緒に何かをするのは難しいですよね？
お互いが主義主張をすればするほど集団とは内部分裂していくものです。
ではそれをずっと大きな集団で保つために必要なことは何か？
それは共通の目的をもつことです。　一つの目標に向かって全体が一つとなる。
敵国の悪口を言うことは愛国心を煽り、国が一つになることを可能にするのです。
国民が一つにまとまり、一つの目標に向かって突き進むことは軍の強さにも比例していきます。
歴史を学ぶことで国民の士気が上がるというわけですね」
「そーいうものなのかしら？」
　「ではあなたに質問です。親を馬鹿にされたら気分はいいですか？」
　「いいわけないじゃない。普通は怒るわよ」
　「そう、それですよ。つまりですね。自分たちの祖先はあいつらに酷い目に会わされたってことで、みんなが怒ります。つまりこの時点で共通の価値観を持つわけですね
あいつらは敵だ！
って。韓国や中国あたりは国策として物凄く日本の悪口言ってますが、あれはこれが目的なんですよ。もっともそれだけじゃないでしょうけど」
　「うーん、歪んでるわねぇ」
　「どこの国でもやってますよ
イギリスの歴史はフランスの悪口で半分埋まってますし、フランスの歴史はイギリスの悪口で半分埋まってます。
ドイツも同様です。ドイツの歴史はイギリス・フランスの悪口で半分以上は埋まっているのです。
ヨーロッパはどこも似たようなものですね。
北欧の場合、特にフィンランドやバルト三国の歴史は八割以上がロシアの悪口という凄まじいことになってます。

すまん。誤爆った。

ああ。そんなとこだと思うよ。

人が何か意見を言うと、それを理解しようともせず、
ただただ喧嘩をしたいから、専門家に通じない意味不明の言葉を書き連ねる
例の痛い人だな。昨日もマ板でやってたね。
　http://pc8.2ch.net/test/read.cgi/prog/1114768433/815
　http://pc8.2ch.net/test/read.cgi/prog/1114768433/830

もういい加減、無理に協調性を発揮して、痛い人の相手をしてあげるのはやめ、
今後一切スルーしようと思う。

うは。こりゃひでぇ議論妨害だな。
誤爆装って議論妨害しまくるとは、ゴミクズもいいとこだ。
人間、孤独が極まるとキチガイになるんだな。

>>548さん、議論の続きをどうぞ。

>>554
ありゃま、失礼。て言うか、最初の草稿時には書いてた気がするんだけど･･････
行が伸びたんで削った時に、その部分が含まれちゃったみたいorz

AOPを仕込むにはインスタンスが必要なんだよ。
例えば、あるクラス内でnewによって生成されたインスタンスがあるとする。
このインスタンスにAOPを仕込むには、なんとかして外部からそのインスタンス
を取得する必要がある。
生成をFlyweightパターンに一任すると、何処からでもインスタンスを取得でき
るから、自由にAOPを仕込める。

>>560
失敬な奴だな。
先に始められてる議論を無視して議論妨害か。
ろくな人生歩んでないなお前。

さっさと死ね

>>561
ええー。
興味あるレスにアンカーつけてレスすればいいじゃん。
掲示板だし話題にのりたくなければのらなくてもいいんじゃない？

>>556, >>560
こちらでどーぞ

　【GoF】生成パターンを語るスレ【ﾃﾞｻﾞﾊﾟﾀ】
　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
　

>>558
そのレスって俺宛？意味不明の言葉って＿|￣|○|||

規模の大小を問わずフレームワークを考える場合に、拡張性を考えれば
考えるほどゴールからは遠くなるという悩みどこに対する解法として一石
を投じたつもりだったんだけど･･････

>>561
投稿前にリロードしてみて良かった。なるほど、そういう前提なわけね。
板とスレという単位でしか枝を持てない２ちゃん型掲示板ではそういうルー
ルなの？
MLなんかだと複数スレッド同時進行は当たり前なんで、俺的にはそういう
ノリだったんだけど･･････そういうルールがあるなら暫く黙っとく事にするよ。

>>562 >>564
議論の続きは、ぜひあちらでどうぞ

　【GoF】生成パターンを語るスレ【ﾃﾞｻﾞﾊﾟﾀ】
　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
　

確率・統計的って言われてもイメージが湧かない
具体的にいうと？

情報通信学会〜情報処理学会の論文を検索してみたら？
ここ数年で、随分進歩した様子が伺える。
あと、それを扱った本も出ているが、どうせ立ち読みもしないだろうから割愛。

>>564
早速新スレの方にレスが付いてるよ。
新スレにちゃんと答えてあげたらどう？

>>567
>情報通信学会〜情報処理学会の論文を検索してみたら？
いい加減こういうレス止めてほしいんだけどいいかな？

いや、それならアンタには理解が無理だ。
残念だったね。

>>570
結局、そうやって馬鹿にするのが目的でそういうこというわけでしょ？
だからいらないっての。

この手の議論は、判る奴だけで進めれば充分。
素人に苦労して説明しても、説明範囲外でデタラメ解釈するのが関の山だし、
このスレには散々他人に苦労かけ、罵倒し倒して聞き出した情報を、
他のスレの荒らしに使うキチガイが居るからな。

素人の相手してもしようがない。つか、素人でも判る奴には判る。
結局、どれだけ新しい話題にアンテナ張って、貪欲に知識を吸収するか、
という生き方の問題なんだ。

>>571
荒らすなバカ

>>572
あるある（笑
「素人にでも判るアインシュタインの相対性理論」読んで、
次の瞬間に「アインシュタインは間違っている」とか言い出す素人（笑

>>572
その方針はこのスレみんなの決定事項なの？
だったら二度とこないけど。

来なくていいんじゃない？誰も困らないよ。

あと、ここをウダウダ荒らす暇があったら、
新スレ
　【GoF】生成パターンのスレ【ﾃﾞｻﾞﾊﾟﾀ】
　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
で議論した方がよっぽど有意義なんじゃない？

もし貴方が荒らしじゃないと仮定しての話だが。

>>572
誰がそんなこと勝手に決めたんだ。

>>574
こいつは
　http://pc8.2ch.net/test/read.cgi/prog/1114768433/815
　http://pc8.2ch.net/test/read.cgi/prog/1114768433/830
だから気にしなくていいよ。

===========================================
キチガイ警報発令！！！！！！！！！>>764
===========================================

===========================================
キチガイ警報発令！！！！！！！！！>>５６７
===========================================

>>577-578 おいおい誤爆しまくりだぞｗ

===========================================
キチガイ警報発令！！！！！！！！！>>５７６
===========================================

そして、ウダウダ言ってた荒らし >>556, >>560, >>562 >>564 は、
決して新スレ　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
にレスを付けない、と。

いつものお決まりのパターンだな。

>>548
決着が付いたところで、議論の続きをどうぞ

>>575
これで次に奴が来たら、奴は荒らし決定だな。
だって自分でもう来ないと宣言したのだから。

>>581
どうみても一連のレスが個人のものにしか見えないけど？
これが「某スレ３２」って奴？
やっぱりＩＤ必要だな。

荒らしが一人前の口利くんじゃねぇよ。
さっさと巣に戻って、プルプル震えてろよクズ。
おまえの巣はν速だろ。いつもヲチしてるよ。

相変わらずレベル低いのが粘着してるね。

レベル低いって言えば、こいつ。

> 569 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/18(月) 01:31:03
> >>567
> >情報通信学会〜情報処理学会の論文を検索してみたら？
> いい加減こういうレス止めてほしいんだけどいいかな？

こいつがレベル低いのは、別に
学会に入って居ないからとか、論文検索できないから、
なんていう意味じゃなくて、そもそも自主的な調査なり勉強を拒絶している所。
まあ荒らしだから、どれだけ自分がトンチンカンな発言してるか、理解してないんだろうけど。

>>585
そいつ、業界外の素人つうか、単なる引き篭もりだよ。
自称年収５千万のスーパープログラマとかほざいといて、
実際はプログラムもできない素人だとバレて、
PC板の厨房に叩かれてた。合掌

>>583-586
２〜３分刻みで必死だなｗ

>>587
OCNが規制されたらぴたりと止んだね。

＝＝＝＝＝＝＝＝＝＝＝＝
DQN>>588粘着中。スルー推奨
＝＝＝＝＝＝＝＝＝＝＝＝

>>588
今頃、キーボード掻き毟って悔しがってる姿が目に浮かぶなｗ
２〜３分ごとにリズミカルに投稿したら、誰だって同一人物だって気が付くよな普通。
自分がレス飛ばしたら、相手のレスを待てよな。
こういう会話のキャッチボールのできない奴が、どの口で設計を語ってるのかホントわからんね。

設計なんてどんなにすごい技術を使ってあろうが、最新だろうが流行りだろうが実績あろうがなかろうが、
根本に「人にわかりやすく物を伝えたい」って気持ちがなきゃすべてが無駄。

俺の言葉を理解したいなら、この本と、この本と、この本を読んで勉強してきてから〜略
まあ、それでも君がボクの言ってることを理解するには○○年は無理だね。
なんて基本的に人を見下してる奴が、設計なんてやって上手くいくはずが無い。

うっわ。すごいことになってるな。

このぶちきれて、いつも>>563みたいな行動にでる奴はなんなんだ？
自分が気に入らないレスがあると新スレ建設か？
別に何を話してもいいだろ。２ｃｈの掲示板なんだから。
このスレ自体たいした議題もないんだし。
別にお前のスレじゃないんだから。お前がスレの方向性きめるなつの。

>590 (= >587 = >589？)
＞ 設計なんてどんなにすごい技術を使ってあろうが、最新だろうが流行りだろうが実績あろうがなかろうが、
＞ 根本に「人にわかりやすく物を伝えたい」って気持ちがなきゃすべてが無駄。

考えてること、言ってることは非常にマトモなんだが、
どうして、そうヒネくれた小学生みたいなレスしか返せないんだ君は…。
端からみてると君の方が荒らしに見えるよ…。

IDｷﾎﾞﾝ

>>593
とりあえず、一時凌ぎで名前欄に最初に投稿したレス番つけるの推奨とか。
自作自演する奴は見抜けないけど。

最近ム板で大暴れの出張粘着氏についてまとめました。
事実誤認があれば指摘願います。

数年前から主に情報システム板で書込む出張32というコテハンと
自作PC板に書き込む録音というコテハンがいます。
トリップなどからこの２人は同一人物と判明しています。
私は自作PC板には行かないので録音氏の言動は良く知りませんが
情報システム板の出張32氏は有能なSEを演じています。
自分が全然知らないことでも良く知っているふりをし
自説を根拠の説明抜きで繰り返し主張する悪癖があり、
しばしば出張32嫌いな人達との煽り合いになります。

スクープ！録音さん
http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html
Lispを知らないのに知ったかぶりしていたことが判明
http://science3.2ch.net/test/read.cgi/infosys/1015424030/659
http://science3.2ch.net/test/read.cgi/infosys/1015424030/667

最近2chの現状に強く不満を持ち、自作自演を繰り返しながら
意見の違う相手を荒らしと決め付け罵倒しまくる人が現れました。
しばしば罵倒している相手を出張32だと決め付けます。
出張32氏を敵視しているので出張粘着氏と呼ぶことにします。
スレ乱立や自作自演しながらの罵倒レスを繰り返すため
結果的に本人が一番たちの悪い荒らしと化しています。

情報システム板のオブジェクト指向スレで煽りレスを罵倒
http://science3.2ch.net/test/read.cgi/infosys/981101071/460-471
削除整理板の情報システムレス削除スレで捨て台詞
http://qb5.2ch.net/test/read.cgi/saku/1031745992/192-195
理系全般板の過疎スレで自作自演しながら削除人をバカ呼ばわり
http://science3.2ch.net/test/read.cgi/rikei/1099820522/129-130

どっちが粘着だかわかんない

自分の気に入らないレスがあると新スレ立てて追い出そうとする手口とか
このスレでもあったね。そういえば。
んで、結局、こっちのスレって過疎スレになっちゃって誰も書きこまない毎日ｗ
新スレの方が盛り上がっちゃったんで出張３２おかんむりｗで新スレ荒らしにくるし
ほんとどうしようもない馬鹿だよなｗ
今思えば奴１人だったんだろうなｗ

その性格じゃ、どこいったってみんなから
排除される運命だってことがわかってないのがうざいな。

え〜っと、え〜っと …… ゴバク乙なのですよ〜

Sくん相変わらず大変だな。
こっちはとりあえず位相幾何学まで守備範囲を広げる事になりそうだ。

あと情報システム板に関して削除人が及び腰になってるのは、
なんかカラクリがあると睨んでる。

Googleで検索順位が恣意的に下がるなんて叩く連中は２ちゃんに多いけど、
情報システム板周りは真っ黒々なものが漂ってるな。

>>597に関して。
彼(>>597)はそもそも、自分が言い放ったことを、
責任持って実現する努力のできる人間なのだろうか？

彼の話は最初は威勢がいいのだけど、
細部が見えてくると精細を失い、
本当に責任を持って行動しなきゃいけない場面で
フェードアウトを繰り返していると聞く。
akon曰く「今度は逃げないといってまたなんか始めた」。

お前本当に信用あるのか？
酒飲んで仲良く馴れ合うこととが、本当に受け入れられたって事じゃないよ。

人を叩くのは結構だが、俺の場合は「受け入れられない」のではなく
「関わっても無駄な奴とは没交渉」になるだけだ。
結構大変だよ、人よりIQ高い人生は。多数派は頭の回転が普通の方ばっかだからね。
初対面に近い、常識的に見て非常に高い学歴を持った先生から
「おまえIQ幾つだ？」みたいな訳のわからん言われる。
やるべき事を普通にやってるだけで、何かと障害が多いし、
挙句に煽り半分で「○×分野で奇才と呼ばれる研究者(?!)」の仕事紹介されたり、
「○×分野で世界トップクラスの学者とのミーティング」をこっそり設定されたり、
はたまた、「△□分野の世界コンテストで優勝した変わり者の某大研究者」なんての紹介されかかったり。
なんでおまいらそんなムキになるの、っつうくらい。

あなたの肉棒を」まで読んだ

#　IQ　が頭の良さと相関関係が無いことが再確認出来て嬉しいな

>>603
乙かれちゃん！

けっきょく住んでる世界違うから、
貴方の世界の「頭いい」つうのとは価値観違うかもね。
貴方の世界の「頭いい」つうのは、あれっしょ、
しょぼいカードをいかに強いカードに見せるか？っつうポーカー技術

そしておいらの住んでる世界の「頭いい」は、
知的誠実さと呼ばれる素直な知的能力を指してる。
貴方の世界では「素直、率直」は、食い物にされる弱者の属性なのだろうけども。

IQ 無くたって頭良いか悪いか位の判別は付きますが

住んでる世界違うからねぇ。ごめん、これ以上会話しても有意義なものは得られないみたい。

私の発言は二回目だよ。
もとより会話する気なぞありません

出張３２がきてるの？
そのうちガイドラインができるんだろうなｗ

出張３２はアンタ>>609

>>603
ああ。そこまでムカついてるなら、
俺はバカって事でもいいよ。
そのかわりアンタはバカの発言すら充分に理解できない大バ(略

まぁとりあえずジャレ愛はこれくらいにして。

質問です。

オブジェクト指向〜計算モデル理論周りで、
型を位相幾何で扱う試みをしている方は居られますか？
OOに適用できるかどうか全く不明なのですが、
応用数学分野でそーゆーネタがあるのを今日知ったもので。

>>611
なんだそれ？
お前また騙されたのか？ｗ

>>612
煽り乙。これはネタじゃないんで、おまいさんはちょっと遠慮してもらえるかな？
S社のA導師が降臨してくれないかなぁ〜って雨乞いの儀式やってる所だから（爆

>>611
すまぬ。位相幾何学で型をどうしたいのか想像もできん

>>614
http://www.f.waseda.jp/murakami/jugyou/2003/kikagakuB1/print414.pdf
俺なんて、位相幾何学が何なのかすら分からんかったんでググってみた。
型キャストと継承に絡みそうな予感だけはした。けど、既存言語で表現可
能な世界なのか全く不明。
何より、デザパタとどう繋がるのか全く不明⊂⌒~⊃｡Д｡）⊃

て言うか、これこそスレ違いでしょ？

ええぇーっとね。ごそごそ。

オブジェクト指向が持ってる属性っつうのは、オブジェクトの型を識別ための情報と仮定しよう。
更に、属性をベクトルで表すと仮定しよう。
すると、型とは属性ベクトルの合成と考える事ができる。

オブジェクト指向の型でこんな事いうと奇妙な感じがするけど、
上記の考え方は、文書集合で文書の特性を示したりするのに使われてて、
実際学会のある分野や、Google近辺で、ここ数年注目を集めてる、ともっぱらの噂だ。

ところで、属性をベクトルとして表現するのは、どうも距離空間に基づく考え方らしい。
ユークリッド幾何学とか射影幾何学で「同じ形」というのは、全てこの距離空間に基づく考え方だ。

とりあえず幾何学分野で形を比較するには、もっと良い方法として「位相幾何学」のやり方があるらすぃ。

ここで疑問。
「オブジェクト指向や計算モデルで言っている『型』とは、どの幾何学に対応するのか？
　例えば『位相幾何学』の考え方を流用する事で、なんらかのブレークスルーが得られないか？」
とゆーのが、とりあえず質問の主旨。

まぁ否定していただいても結構だけど。
OO分析の品詞抽出法(名詞句、動詞句、etc)を進化させちまうのがこっちの狙いなんで。

>>615
たぶんこれ
http://nice-choice-peropero.web.infoseek.co.jp/mp3/ogino-rap.swf
http://nice-choice-peropero.web.infoseek.co.jp/flash/kamedat.swf

>>615
「型」って言ったのがちょっと不味かったな。
とりあえず「パターン言語」と呼ばれる(たぶんある種の)言語の解析に
自然言語解析の方法を適用し、さらに将来的に発展させるために、
良い方法はないのかちょろちょろ考え始めている。
「位相幾何学」というのは、その一つの道じゃないかなぁ〜、と。

>>616
>実際学会のある分野や、Google近辺で、ここ数年注目を集めてる、ともっぱらの噂だ。
噂かよｗ

やべっ、文字があちこち消えてるし・・・とりあえず訂正

3行目訂正
×　オブジェクト指向が持ってる属性っつうのは、オブジェクトの型を識別ための情報と仮定しよう。
○　オブジェクトの型の識別は、オブジェクト指向の属性(変数、メソッド)で行われると仮定しよう。

>>619
そこらへんは常識的にボカすしかねぇーだろ。

じゃとりあえずこのネタの議論は終了って事で。

はい！みなさん！注目！
>>616の文章で一番大事なところは原点になってる考え方がすごくあいまいなこと。
まったく信用できるもんじゃない。
前提から話にならないし、議論の際、相手が発言にどんな軌道修正をかけても
そもそもの前提があいまいなので、まずい発言を繰り返してものらりくらりと逃げ回ることが可能である
という危険性を各自認識した上で議論に望むこと。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上！

出張32はレスしなくてイイって言っただろ？
おまえは本当に空気読めない人間だな。

引き篭もってると、そこまでトンチンカンになれるのか。哀れだな

>>610
それさ、元ネタは30年前に一世を風靡したネタでしょ？
もちろん、OOの型、DPの言語への適用は、
前例があるのかないのか知らないし、
30年前のネタがようやく実用にされるってのもアリだけど。
(超伝導なんて100年近く前のビンテージネタだけど、
　実利用が始まったのは20世紀も末に入ってからだったし、
　挙句に原理はまだ確定してないし。)

そうすると、SRA先端研の青木さんが
「じゅん」で何故、位相幾何学に取り組んだのか？
というあたりが気になるな。

もちろんビットマップ〜ベクター表現のSmalltalkグラフィックスを進化させるという目的は明確だろうし、
具体的な応用事例として構造化学〜生体分子構造論があるだろう事は推測つくけど、
それではその先をどれくらいイメージされているのか？とても気になる

>>626
理由なんかないだろ。
単に人の注目集めて、上手く当たってくれりゃ一儲けぐらいにか思ってないって。
設計の分野ってこういう奴多いよ。

国立情報研や東大先端研の人達と、
分子構造のインタラクティブな可視化を研究したりされてるようですが。
いいやねいいやね、なんか楽しそうな研究テーマで。

おいらも数年前に、業務ちょっと離れた所で同じネタ振られたことあったんだけど、
生体分子のフォールディング構造予測＋構造活性相関みたいな話だと認識してそこに執着しちゃって
位相幾何なんつーテーマまでたどり着けませんでした（TT）

むずかしい言葉を使ってレベルの高そうな話をしているようにごまかしているが、
ココ↓注目

例えば『位相幾何学』の考え方を流用する事で、なんらかのブレークスルーが得られないか？」

要は自分の知ってる知識使ってなんか（なんでもいいから（笑））いいもの発見できないかな？
的なものでテーマすら決まってない程度の低い話であることを忘れてはいけない。

レベル高そうも何も

>とりあえず幾何学分野で形を比較するには、もっと良い方法として
>「位相幾何学」のやり方があるらすぃ。

これだけで素人丸出しなのが丸分かりなんだが（苦笑）
「形」も「良い」も数学的・論理的に未定義である以上、上の文章は何も
言っていることにはならない。

なおトポロジー（位相幾何）は数学科なら学部学生程度で学ぶ概念だが、
下積みとして必要とする知識は少ないから、その基礎概念を学ぶだけなら
そんなに難しいものではないよ。

カイスタマイズの為にインタープリターまで行くなら、
最初から言語で組んだ方が早いんだよなぁ。

標準言語＋自作テンプレートライブラリで。

頭悪いんだろ。とか思う。

>>601
よくわからんが神レベル

>>630
一応、今持ってるイメージはちゃんと書いたつもりのつもり。。。。。。
トポロジーが同じっつうのが、なんとなくデザパタでパターンが同じというのと似ていると、
直感的に思った。

つか、オブジェクト指向ってそれ自体、簡単に数学モデルに移せないよなぁ〜。
関数型言語のモデルすら圏論みたいなわけわからんもの使ってるし。
やっぱ位相幾何は、統計とって距離を云々する問題の延長線上でしか使えないかなぁ〜

>>633
でてくんなホラ吹き野郎。
ぶっころすぞ。

>>634
キミのレスを見れば、キミはまともな仕事をしていないクズである事がよくわかる。
つか、キミってこの板で浮いてる。なんつか渋谷の真ん中で見る、ボロボロのホームレスみたいな衝撃

>>635
知りもしない言葉なんか使うからそうやって恥をかくことになるんだよ。
だいたいお前、みんなが知らないような言葉使っただけで悦に浸ってる程度の低い学生だろ？
この業界はね。
頭のいい人ほどみんなにわかる言葉を選んで会話をするもんなんだよ。

相変わらず哀れな奴だな。
判る判らないって、お前自身を基準にしちまったら
実も蓋もねぇ〜だろが。

はっきり言うよ、おまえみたいに新しい事への意欲を失っている人間は、
技術系の板に似つかわしくない。さっさと巣に帰って、二度とここにくんな

>>635
あとさ、以前俺がお前に言ったこと、もう忘れてるだろ？

知らないという事を恥じるお前のセンスがバカだ。
知らなくてもそれなりに推測を重ね、傍証を重ね、
昨日判らなかったことを今日は判るように努力する、
これが頭がいいって事だって。前、説明しただろ？

あ、俺の文化圏の話だから、お前の文化圏とはまるっきり定義が違うのかもな。
結局お前にレス付けても、まるっきり無駄だと思ってる。おまえ進化しないもん。

>>637
論点が全然違うじゃん。
そうやって普段から話をはぐらかす方向にしか議論をしないから
難しい言葉を使って聞き手を煙にまこうとすることしかできなくなっちゃうんでしょ。
かっこ悪いと思わないのか？

>>638
サル相手にまともなレスつけてもまた暴れるだけだって。
バカはバカ、永遠に放置しとけばいぃ〜んじゃないの？

>>640
おっけ。こいつ(>>634)、精神病んでるみたいだしもう放置。
どうせリアルでも誰にも振り返られない可哀想な生活してるみたいだし。
ネット上だからって律儀に相手する筋合いはねぇよな

>>640
また、そこで自作自演？
あのさ、お前しかいないんだよ。
>>616←こんなはずかしい文章読んでうなずいてんのなんて。
はずかしくってレスつけられねぇんだよ普通は。

>>633
デザパタの分析に確率・統計適用ってできないもんかね（ﾌﾟｹﾞﾗ

>>640-641
いや、よっぽど、アレじゃない限りわかるよ（笑）

お、NGワード設定したら結構いけるなこのスレ。
バカの発言全部NG表示になった（藁

>>634
犯罪予告として通報しました。
警察がそちらに直行するそうです。
ばいばい

>>646
おいおい、しまいにゃ捨て台詞かよｗ
かっこわり〜ｗ

「我々の予想に反し、文明社会の住人よりも未開文化の住人方が、羞恥の意識が強かった。
　未開文化の住人は、恥を欠くことを恐れるあまり、社会の進化や他文化との交流を諦めた人達なのである」
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　文化人類学者

>>648
しつこいなｗ

哀れだな。
スレの主旨も判らず荒らしまくり、
ゴミ扱い、犯罪者扱いされても
まだしつこくまとわりつくとは。

よっぽど他人との交流に飢えてるんだな。

＝＝＝＝＝＝＝＝＝＝＝
ストーカー排除＆リセット
＝＝＝＝＝＝＝＝＝＝＝

>>650
もうすっかり負け犬根性だなｗ

>>651
このうざい枠付きのレスもお前か。
何人自演してたんだホント。病気だな。

この板ＩＤつけちまえよ。
こんな馬鹿までわくようになったのか。

位相幾何で「難しい言葉で煙に巻く」だって？ぷげら

>>654
ま、結局、本人も「位相幾何」なんてよくわかってないから
こんなこと言っちゃう↓

>なんらかのブレークスルーが得られないか？

はぁ？
相手にしてもらいたいなら、これはお前が見つけてこいよｗ

┌─────────────┐
│枠とは、こういう形のものです　│
└─────────────┘

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
　これは、枠ではありません。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>652-653
のようなレスを、スレ違いの荒らし野郎、と呼びます。

なにこのスレ？文末ダブリューの人がまた発狂してるのか

>>657
でしょ？本人は至って正常なつもりだからコワヒ

まぁあれだよね。
こんな荒れ果てたスレでも、
もしかしてマトモな人が居るかな？居ないかな？
とか思って、リアルの方の仕事をﾃｷﾄｰにぼやかしてマジネタ振ると、
食いつくのはキチガイだけ。

ここってホント終わってるスレだな。

マジネタ？(w

イメージ・雰囲気だけで「位相数学」とか言ってるだけじゃん
専門家からは相手にされんよ

仕事とは片腹痛い

位相数学以前に同値類とか見て「あ、これはis a 関係に似ているのかも」
とか、そういう素朴としか言いようの無い反応を示してるんだろうけど

数学的に言うなら、まだ代数のが関連深いと思うよ

「知らない」と認める事が恥だと思って、ひたすらハッタる池沼が粘着してるんだもんな。
そりゃ荒れるって。まともな人間と議論が噛みあうわけないだろ。

>>661
「俺の知らないことで盛り上がるな」厨も確かにいるけど、
自分も数学系学部学生程度のレベルの人間から見てさえ
厨レベルでしかないことは自覚しろ

複雑系を数学的に理解せずに「チョウチョが飛んだらアメリカが風邪をひく
ことの説明が出来るんです！」みたいなこと言ってる
トンデモ本とレベルは変わらん

>>660
マジレス？(藁

相変わらずつまんねぇレスだな。
名詞句抽出法周りでオモロイ見解が見つかったんで、
それをNDAに引っかからない範囲で紹介しようとしたんだけど、
相変わらずあいかわらずだな。
性格悪かろうと、あきんどだろうと、akonの方がよっぽど面白いや

>>662
お前も相変わらずバカだな。文面読めてないし。

もはや誰が誰だか分からんわけだが

おまいら少しはデザパタの話をしろ

>>663-664
忠告だけど。
ここホント箸にも棒にもかからない馬鹿しか居ないから、
もし有意義な議論をしたいのならここではなく他でやった方がいいと思うよ。

> 名詞句抽出法周りでオモロイ見解
で、それがどうデザパタと関係するのよ(w

自称日本一のコンサルさんなら、
それくらい理解できるでしょう。

なんちゃって。元々は全然別の話題なんだけど、
全然別の所から同じような話が聞こえてきたんで、
まぁとりあえず
とりあえずネタとしては面白いかなぁ、と。
(いまさらApplicationArchitecture-なんちゃらかんちゃらを気にしてる人も居ることだし)

1.品詞抽出法： 名詞ならオブジェクト、動詞なら(動作主体となるオブジェクトの)メソッドにする(詳細ばっさり略)
1.の拡張1：　　　それでは接続詞は？連体修飾語は？
　　　　　　　　　　動詞の解釈はホントそれでいいの？
　　　　　　　　　　だいたい仕様書の字面が、本当に意味する事を正確に表しているわけじゃないよね？
　　　　　　　　　　というネタ。NLP方面追っかけると、いろいろ・・・わかるよ。俺は結構勉強になった。
　　　　　　　　　　あとオマケで、SWEB周りの現状と課題もわかってきた。

2.デザパタに関する話
　　　　　　　　　　こっちが>>610。
　　　　　　　　　　こっちは要するに、NLPやGenom周りでいろいろ応用されて実績のある
　　　　　　　　　　確率・統計モデルに基づく数理的手法を、
　　　　　　　　　　デザインパターンの抽出や分類に使えないかなぁ、というのが第一段階。
　　　　　　　　　　第二段階として、>>610に書いたような話もあるな、と。

×　全然別の所から同じような話が聞こえてきたんで、 まぁとりあえず とりあえずネタとしては面白いかなぁ、と。
○　両方に引っかかるキーワードが全然別の所から出てきたんで、まあとりあえずこーゆーネタもあるよ、と紹介できれば良いと思った。

なんで情報提供する側が低姿勢で説明しなきゃならんのか？

ここは変な村だな

NLPっぽい夢見てるだけじゃん…。
ちょっとかじって面白そうだと思っただけですな。
スレ違いだから他でやってくれよ。ホント。

>>668
みたいな事は、7年くらい前に学生だった俺でも考えたよ。
さっさとデザパタの話に戻ろう。

ああ、それは良かったね。
なんでそんなに必死なの？

これが２ちゃんクオリティか。

>>672
> さっさとデザパタの話に戻ろう。

もういい加減、古臭いGoF２３パターンで何百スレも費やすのは勘弁な。
せめて世の中並みにPoEAAかAPの話題にしてくれよ。

さもなきゃNLPのためのパターンでも説明しようか（藁

で、やっぱり、>>616は出張３２なわけだ。
マジでウザイなコイツ。

674 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/20(水) 07:32:09
　↓
675 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/20(水) 07:32:40


・・・夜から朝まで粘着して大変だな、出張。
頭悪いんだからレスつけなくていいのに

>>675　お前専用のスレを立てといてやったから、
　　　　　粘着談義はそっちでやってくれ。迷惑だ


　例の頭おかしい粘着が孤独を癒すためのスレ
　http://pc8.2ch.net/test/read.cgi/tech/1121781119/

>>677
そうやって気に入らないことがあると
わざわざ新スレ立てて追い出そうとするのも出張３２の特徴らしいｗ
頭おかしいだろ？お前。

>>678＝出張、さっさと新スレ逝け。
おまえを必要とする人間は、このスレには居ないんだよ。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
頭が弱い可哀想な人(>>678)が朝から粘着中
生暖かい目で放置しようね
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>677,679-680
が出張３２ね。
特徴としてわざわざ新スレ立てて追い出そうと試みる。
ってのがヒットする。

おまい本当にバカですね。

デザパタスレで喧嘩しかしないし。

確かに全然デザパタの話が出てきてないよな〜と

>>631
EXCEL を思い浮かべれば分かりやすい
セルに関数を書いた後、さあどうやって計算するかって話で

悪い。自分でもよく分からなくなった


極端な話、LOGO インタプリタを C で作ろうとして
「んじゃ最初から C で書いたほうが早いよな」
って言ってるようなもんだと思う >>631 は

もちろん、限定的な用途ならば、わざわざインタプリタにする意味がないというのは同意
けど、そこにインタプリタにする何らかのメリットがあれば、(当然のことながら) インタプリタにする価値は出てくる

インタプリタと言うからには、単なる値設定だけではなく、
ある程度複雑なデータ構造を定義したり、制御構造を書いたり、手続きや関数を定義して、
要するに複雑な処理を抽象化して簡単に実行できる機能が欲しいところだな。

あと、アプリを後から拡張する手段として使ったり。

>>685
拡張する手段なら、DIコンテナ使って後付で刺せるようにしとけばいい。

方法は色々ある。好きなのを使えばよろし

まぁ>>686には、PlugIn + scriptとか、DLL + scriptというアーキテクチャの存在を示しておけば、
話は足りるだろう。
　・PlugIn手法＝DIパターン
　・script言語＝Interpriterパターン
という組み合わせのアプリは、世の中あちこちにある。

J2EE〜EJBでそのパターンを書かれると、センスの悪さに結構ムカつく。

サルでもわかる デザインパターン
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html

インタプリタパターン使うとScript言語とか
作れちゃったりするんですか？

>>691
そのまんまインタプリタ言語だな。

インタプリタパターンでまともにScript言語作ったら遅いだろうなぁ

おまぃ幼い煽りをしまつねえ。。
あれは再帰下降型パーサに適したパターンだから、ソレ実装するなら全然問題ナッシング。
むしろ、それ以上複雑な事をする場合にもあのパターンで公開インタフェース作れとか
訳判んない事逝ってるGoFを嘲笑うのが、小学生らしい振る舞いでつよ

実際にインタプリタパターンを使って作った
Script言語ってあるかな？

>>694
そんなこと言ってまた粘着刺激するから
議論レベルがどんどん小学生みたいになっていく・・・。

>>691-695
独自の Script 言語を作り、それを組み込む事が Interpreter パターンだ
ぶっちゃけ Script 言語を作ることそのものが Interpreter だ

速い遅いは関係無いですよ？

GoFにそう書いてあるの？

GoF を始めとしたデザパタ本に書いてあることが全てだと勘違いしてはいけない
アレはぶっちゃけ 『サンプルコード集』 つまりサンプルだ


……と言って見るﾃｽﾂ

　　　　 ///////
　　　　///////＿＿＿＿＿＿＿＿＿＿＿_
　　　 /////// ￣￣￣￣￣￣￣￣￣|￣￣
　　　///////　　　　　　　　　　　　　 (~)　ﾁﾘﾝﾁﾘﾝ
　　 ///////　　　　　　　　　　　　　　ﾉ,,
　　///////　　　　 ∧＿∧　　　　　　　　 ／￣￣￣￣￣￣
　 ///////　　　　 （　´∀｀）（ 厨 ） )）　＜　　夏だなあ〜
　/////// 　　　　 （つ　へへ つ　　　　　 ＼＿＿＿＿＿＿
///////　　　//△ ヽλ　 ）　）　旦
//////　　l￣￣￣￣￣￣￣￣￣￣￣l
/////　　　￣| .|￣￣￣￣￣￣￣| .|￣
////　　　　　^＾^　　　　　　　　　 ^＾^

　　　　　　　　　厨房の夏。2chの夏。

>>697
なるほどありがとうございます。
いや、デザインパターンってすごいっすね。

ttp://internet.watch.impress.co.jp/cda/news/2005/07/22/8522.html

>>703
ｸｯｸｯｸｗ
「Winnyを使ってる事が発覚したら懲戒免職」ぐらいに罰則を厳しくしないと
流出事故はなかなか減らないと思うぞ。

×>>703
○>>702
自分にレスしてどうする。

==============================
キチガイが狂った独り言を書き込み中
==============================

ＮＧワード：=============

J2EEパターンの話題は駄目ですか？

>>707
いいんじゃないですか？

パターン指向リファクタリング入門〜ソフトウエア設計を改善する27の作法
http://www.amazon.co.jp/exec/obidos/ASIN/4822282384/

　 ∧＿∧　　　　 ∧＿∧　
　（　´∀｀）　　 　（・∀・　）　
　（　　　　⊃□　（　　　　）　
　　　|＼
／￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| こんな感じで使ってちょ。
|
| Protuct p = factory.create( "HogeHogeClass" );
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　 ∧＿∧　　　　 ∧＿∧　
　（　´∀｀）　　 　（・∀・　）　
　（　　　　）　 □⊂　　　）　
　　　　　　　　　　　　|＼
　　　　　　／￣￣￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　| できたよ。
　　　　　　|
　　　　　　| static final String HOGEHOGECLASS = "HogeHogeClass";
　　　　　　| // これ以降 Factory に指定する全てのクラス名についての同様の記述
　　　　　　|
　　　　　　| Protuct p = factory.create(HOGEHOGECLASS);
　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　 ∧＿∧　　　　 ∧＿∧　
　（； ´∀｀）　　 　（・∀・　）　
　（　　　　）　　　 （　　　　）　
　　　|＼
／￣　　￣￣￣￣
|　・・・・・・・・・
＼＿＿＿＿＿＿

product

>>710がなぜいけないのか教えてください

>>660
えぇーと。
数学者ではない俺にも、
おおよその方向はつかめた。

・代数との関連については、おっしゃる通りらすぃ。
　（ってWikipediaに書いてあったw）
・バイオインフォマティックでは、そのものずばりの名前が付いた手法が広く知られている。
　(そういえばSRA青木導師の仕事もバイオインフォマティック絡みだったっけ)

> 専門家からは相手にされんよ
必死だな（藁

>712
Factoryの目的は、ソースコードの記述と生成するオブジェクトの
依存関係を切り離すことだから、（　´∀｀）の例とか（・∀・　）の
実装とかのように使うのはあまりメリットがない。

良く使われそうなのは
Protuct p = factory.create( f() );
// f()は設定ファイルとかからオブジェクト名を切り出す関数
とかかね？詳しくはModern C++ Design読んでくれ。

まあ、（・∀・　）のようにすると（（　´∀｀）の例とは違って）
実行時エラーをコンパイルエラーにすることができるメリットは
あるけどね。　

>>714
？↓これはコンパイルエラーにできるのか？

Protuct p = factory.create(HOGEHOGECLASS);

べつに>>710のコードでも生成しているオブジェクトは隠蔽されてるわけで、
どの辺りがダメなのかがよくわからん。

>715
>？↓これはコンパイルエラーにできるのか？
ああ、すまん。HOGEHOGECLASSをtypoしたときの話ね。

>べつに>>710のコードでも生成しているオブジェクトは隠蔽されてるわけで、

隠蔽じゃなくて分離な。
普通インスタンスを作成するときは
Protuct p = new HogeHogeClass;
とかすると思うけど、そうするとその部分では"HogeHogeClass"のインスタンス
しか作れない。つまり、そのソースコードの部分に
『インスタンスを生成する』
『生成するインスタンスを指定する』
という２つの情報が縛りつけられているわけ。
これだと不便なことが多いから、『生成するインスタンスを指定する』というのを
切り離して指定できるようにしたのが factoryなんだけど、
Protuct p = factory.create( "HogeHogeClass" );
とすると結局『インスタンスを生成する』『生成するインスタンスを指定する』の
両方を指定しているので、結局 new とやっていることが変わらなくなる、
つうこと。

＃factoryはFactoryMethodパターンじゃ無いよな？

>＃factoryはFactoryMethodパターンじゃ無いよな？
どっちかっつうと Service Locator Pattern かな。

質問です。
デザインパターンのInterpreterパターンはLL(1)文法しか
記述出来ないのでしょうか？
LALR(1)文法をInterpreterパターンで実装することは可能でしょうか？

>>672
ははは。７年前（ぷ
実は先週、18年前にソレやった研究者の方にお会いした。
彼は、8年前にオブジェクト指向の静的モデリングと動的モデリング(シーケンス図w)の件もやったそうだ。
で、もう過去の研究です、だって。Webでググるとちゃんとひっかかるはずだよん

今週はdevil様とお会いできる予定。。。

でぇ。
いちおうその方に、今その分野に興味を示している方が居る事は伝えておいた。
もしあなたが本当に関心あるのなら、この研究者を御自力で探して連絡とってはいかが？
先方もいろいろな分野のビジネスに強い興味をお持ちのようだ・・・

またこの流れかよ…

馬鹿ばっかり。。。

IPSJソフトウェア工学研究会の例の本紹介するヤシすら居ないのは、
変なのが継続的に粘着荒らししているからだってさっさと気付け。

2ちゃん発とか喜ぶガキが多い中で、
>>721は随分ひねくれたガキだな（藁

数レス読んだだけでキモイのが常駐してることはよくわかった。

はるか昔からこんな感じです。

>>725
どのレスがキモイ？
俺、>>719←こいつ生理的に受けつけない。

インテリジェンスのある語りの一つも受け入れられずに
デザパタスレに来るとは、悲惨極まりないな。

オマエはHSPスレとかCOBOLスレで不毛な叩き合いしてなさいってこったｗ

学部すら出てないようなの相手にムキになってもしょうがないだろう？

>>727
同感。

719が死ねばこのスレは平和になる気がする

相変わらず中身のないキチガイがのたくってるな。
どうせリアルでもネットでも誰にも相手にされていないんだろう？
悲惨極まりないな

>>719
てか、何をどうやったかなんて問題じゃない。
こんな金にならない分野の研究なんかに金だしてくれる奴がいることに驚きを隠せ無い。
研究成果とか金になってるの？
2005/09/08で先週とかいってるってことは一応日干しにはなってないんだよね？

マジでこんなくっだらねぇ研究に金出す奴の面が見て見たい。
本なんて半年に一度は信者に買ってもらわなきゃ食ってけ無いだろ。

何？つか、誰？その「devil様？」って知らないのはそいつが極レベルのマイナー研究者じゃなくて、俺が無知だから？

>>719
うっひー久々ｷﾓｽｗｗｗ
自ら聞いてもいない事ベラベラしゃべりまくるまさに典型的ヲタ
歯が黄色くて髪は油でベタベタ、シャツはヨレヨレ黒ずんで、パンツは
スラックスで寸足らず。
なのに靴は黒いハイテクスニーカーなんだ！間違いない！

>>734
いや、聞いてもいないことをしゃべりだすのはいいんだけど、
>>719は内容がキモ過ぎだよ。

人の手柄を自分のことのように語るのもまあよくいるクズだな。
まだ許せる。
でも、>>719の文章からはそれをも遥かに超越したキモさがあると考える。
なんだろう・・・このキモさは・・・。

もうホント、ガイドライン制作者並（専門家）の分析が必要なレベルだと思う。

>>719がｶﾜｲｿｽ・・・。
まあ、>>719の発言は、たしかに電波はいってて怖いのでそう言われてもしょうがないが。

おまいらもおまいらで「キモイキモイ」とかガキみたいに騒ぎすぎだろ。
正直、おまいらもキモイ。器が知れる。

>>733はまともそうだが。
ちなみに俺もdevil様なんて奴はしらない。相当マイナー研究者。

これは何というパターンですか？

http://pc8.2ch.net/test/read.cgi/tech/1126539231/
このスレから嗅ぎつけた俺がきましたyo！

>>719-720
きんもーっ☆

>719は『教えてあげよう』というアンチパターン
http://www.shos.info/develop/oo/dscsnptn.html#teach

そっから後は『マジギレ』かなあ……

おいらは『アンチパターンの指摘』

キチガイの一人芝居炸裂だな。誰にも相手にされていない壊れた人間の標本（ぷ

頭悪過ぎなキチガイ(約一名)に一応回答してあげよう。
俺ってなんて親切なんだろう（ぷげら

>>727　俺、>>719←こいつ生理的に受けつけない。

　君の粘着っぷりがキモ杉。とっとと精神病院逝け

>>733　こんな金にならない分野の研究なんかに金だしてくれる奴がいることに驚きを隠せ無い。

　それに莫大な投資してたのは、２０年前の通産省(爆笑.
　元ネタは有名な古い方法論者の提案した「名詞句抽出法」。
　現在も、ユースケース記述から人手でオブジェクトを抽出する時に使われてる。
　まあ今年になってから自動でそれやると言い出すのはどーかと思うが。

>>733　何？つか、誰？その「devil様？」って知らないのはそいつが極レベルのマイナー研究者じゃなくて、俺が無知だから？

　その先生は、東大出版会から本出してる人で、
　　　こ　の　ネ　タ　と　ま　る　き　り　無　関　係　 。
　ちなみにその本と、その次の著作は、その分野の開発やってる人ならたいてい知っている本だ（藁

>>734

　よくジャニーズ系と言われますが、何か。

>>737

　「キチガイが孤独を癒すために一人芝居する」パターン


頭悪過ぎ（ぷ

> 　まあ今年になってから自動でそれやると言い出すのはどーかと思うが。

これは当然の事ながら、全然別の人ね

本当にひどいな。
なんでこんなに嫌味ったらしくなれるのかね。
大体、2ちゃんねるでちょっと煽られたくらいでマジギレしてる時点でまともな人格の持ち主ではない。

719=741は
2chをガッコの中にある掲示板と勘違いしてるんじゃないかな
ガッコのお外での遊びかたとを覚えなさい

子供なんだろうね。いうに事欠いてジャニ系とは・・・。

プライド高い人っていじめると楽しいよね。

>>746
傍迷惑だから無闇に刺激するのは止めてくれ

あははは
すげー気持ち悪い

なんでこんなに2chに染まりきれるんだ

devil様
http://arn.kyosui.net/arc/devil/

>>741
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

>>719-720
おい！>>719でてこいよ！
お前、どうやったらそんなキモイ発言ができるんだ？
キモ過ぎんだよ。
>>741で一名だと思ってるみたいだけど全然そんなことねーぞｗ
だって>>719-720のレスってかなり稀にみるキモさだぜ。
正直いってすげーよ。
どこまでクズ晒せば気が済むんだとかそういうレベルとっくに超えてるしｗ

顧客に迷惑をかける自称アーキテクトデザパタ厨ｗｗｗ
http://www.atmarkit.co.jp/farc/rensai/28it02/28it02.html


「なぜこのアーキテクチャを採用したんですか？」

「いや、なぜって……。いま作るならこれがいま一番はやってるからなんですけど……」

「どうしてこんな設計になっているんだ？」

「このシステム、5年はこのまま改修しながら使い続ける予定なんですけど、もちろんそれは考えてのことですよね!?」

「いや、ちゃんと現場を教育し続ければ可能だと思うんですよ、第一……」

「できる、できないの話じゃないんですよ。じゃあ一体その教育コストと時間は誰が払うんですか？ あなた、払ってくれるんですかね？」

「いや、それは……」

「あなたの趣味で作られたら、運用する側はたまったもんじゃないんですよ。私のいってること、理解できますよね？」

「いえ、そもそもソフトウェアというのはオブジェクト指向に基づいてこう作るべきというのが最近の考え方で……」

「あんたから大学の授業みたいなのを聞きたいんじゃないんだよ、もういい。帰って」

>>751
デザインパターン一番の問題はそこだな。
果たしてあの５００ページの本をいかにしてプロジェクトのメンバーに
読ませることができるかということだな。
実績なんていくら挙げたって全く無意味。

デザパタ厨の哀れな末路。

「もういい。帰って。」

上司になんて報告すればよいのだろう。

「お前みたいな技術馬鹿はうちには要らない。」

つうか、全員がコアアーキテクチャまで完全に理解できなきゃダメ、
とか言い出すとオブジェクト指向設計なんて成り立たん。
(少なくとも、業務システムである程度高度なことやろうと思ったら)
業務コード書く人間は、コアアーキテクチャをほとんど知らなくて
書けるようにするための、デザインパターンだろ。

まあ、>>751 の例はちょっと説明能力なさすぎだけど・・・。

>>754
そもそも、その説明から何言ってるのかわからねーんだよ奴等には。
ソース見て、一瞬で「やる気ねー」ってところですでに駄目。
「この本を読んで」ってのは技術者同士では通じても、
ビジネスの話では全く通用しない。
あまりにも時間がかかりすぎる。
リンク先にも書いてあるでしょ？
一般の業務をやってる人間でもプログラムに関わることが多くなった。
って。それはそういうことなんだよ。

アナリシスの話と設計の話を同一視して語ってもなんにもならない。
「顧客」と「アナリスト」の関係と、「アナリスト」と「設計者」の関係の共通点を抽出すれば何か発見できるのか？

>>756
そんなことは関係ない。
これは実際の現場で実際におきている、もしくはこれからおきる問題だ。

>>755
>そもそも、その説明から何言ってるのかわからねーんだよ奴等には。
いや、クライアントに説明するときには、こんな言葉は使わんけど・・・。

>リンク先にも書いてあるでしょ？
というか、リンク先の記事は、デザパタ云々というレベルの話じゃないと思うけど。
組織分析とか、業務分析の問題でしょ。
このレベルの説明でデザインパターンなんて持ち出さないよ。

>>757
君にとっては「「顧客」と「アナリスト」の関係」は「実際の現場」じゃないのか？

アナリストって何？肛門の穴にやたらと指を突っ込みたい香具師の事か？

ここでいう「アーキテクチャ」はデザパタみたいな小さい意味での
アーキテクチャとは違うわな。IT Architect 読んでる奴なら分かると思うけど。
ちょっと的外れな気がする。

>>760
ちょっｗｗｗｗｗｗｗｗｗﾌﾘｽｸ入れてみれｗｗｗｗｗｗｗ

>>760
そのとおり。
ちなみにクライアントは性格の暗い蟻のことだ。

>>758
いや、モロにデザパタのことでしょ。
これまででた胡散臭い開発手法を一掃しなきゃいけないときがきたってことでしょ？
そもそも、デザパタを導入しなきゃいけない理由を説明できるの？

業務分析やアーキテクチャ、運用計画とデザパタの区別がつかんような奴には俺はよう説明せん。

>>764
同じなんだよ。
デザパタを導入する＝人にその開発手法を押し付ける
こと自体お金がかかるんだ。
必ず説明責任が発生するんだよ。
いままでの技術者相手に相手の不勉強を理由に自分の正当性を突き通すことは全くできなくなった。
ってことだよ。
頭使え馬鹿。

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

デザパタ終わったな。

ｷﾀ━━━━デザパタ完全消滅決定━━━━ｯ!!

>>764
同じなんだよ。
構造化プログラミングを導入する＝人にその開発手法を押し付ける
こと自体お金がかかるんだ。
必ず説明責任が発生するんだよ。
いままでの技術者相手に相手の不勉強を理由に自分の正当性を突き通すことは全くできなくなった。
ってことだよ。
頭使え馬鹿。

>>769
ハイハイ。
その時代には素人が開発には入ってなかったのでまったく意味が通じません。
コピペするにも頭が悪いと効果が薄いですねｗ

デザパタって開発手法だったのか

>デザパタを導入する＝人にその開発手法を押し付ける
デザパタって開発手法だったんだ

ふつう開発手法というと、WaterFallとかAgileとかXPとか開発プロセスの
話になるかと思うんだけど？

デザパタは単に（建築）工法とか（建築物の）様式ぐらいの話じゃない？

食いつきすぎ

>752
形を真似て形に入り
形を極めて形から自由になる

デザパタに囚われちゃいかんよ。
システムにフィットさせるために修正・改変するのは当然のことですな。

システム（問題領域）にとって最適な形だったら、ちょっとぐらいむずかしくても
理解しやすいだろうし。
＃お客はその問題領域のプロ（のはず）なんだからね……

だから、この段階ではデザパタなんて元々出てこねぇって。

客が実装に関わる事はない。
なんでデザパタと結びつくと思ったんだ？的外れすぎて（ ﾟдﾟ）ﾎﾟｶｰﾝ

てか、ここはDIコンテナで実装して代替性を確保して下さいね
とか言ってきたら怖いっての、色んな意味でｗ

デザパタ信者必死過ぎｗ

ハイハイ、全然的外れな問題にすりかえないでね。
対象が客なんて誰も言ってないよ。

対象は素人なの？うちの職場に素人は居ません。てか、要りませんｗ

>>779
君は馬鹿だからレスしないでねｗ

デザパタ終了！残念！

そ、それはひょっとしてｷﾞｬｸﾞで言ってるのか…？

キチガイの一人芝居乙

まあ、デザパタ批判はあっていいけど、
関係ない記事を引用して我田引水な論理を展開されてもなぁ。
やるなら、もうすこし議論のしがいのある内実を伴った批判を
してほしいもんだ。電波いじりも面白くないわけじゃないがそろそろ飽きた。

Gag of Four

ポリシー無くただ流行っているというだけで
過去に無かった設計技術を導入するのもどうかと思うけど、
http://www.atmarkit.co.jp/farc/rensai/28it02/28it02.html
を書いた人の会社 豆蔵 のページ(※)を見てみると、
デザインパターンそのものを否定したくって
この記事を書いているようにも思えないんだけど？
つか@ITの記事にデザインパターンなんて言葉でてないし・・・

※
【ホームページ】 http://www.mamezou.com/
【技術情報】 http://www.mamezou.net/

>>748
相変わらずバカだな。

こっちが書いたまんまググってんじゃねぇ〜よボケナスが。
キチガイはどこまでいってもキチガイだな

devil様降臨age

おー
釣れてるしー

その貧困なボキャブラリで

>1.品詞抽出法： 名詞ならオブジェクト、動詞なら(動作主体となるオブジェクトの)メソッドにする(詳細ばっさり略)
>1.の拡張1：　　　それでは接続詞は？連体修飾語は？
>　　　　　　　　　　動詞の解釈はホントそれでいいの？
>　　　　　　　　　　だいたい仕様書の字面が、本当に意味する事を正確に表しているわけじゃないよね？

こんなのできるわけないじゃん...

どんだけIQ低いんだよ
お前IQいくつだ？

　∞
8 ※ 8 ここまでよんだ。 平成17年9月14日(水)
∞

ICQってまだあるの?

変態じゃ、変態の仕業じゃ

http://www.iqtest.dk/main.swf
さぁ、お前らのIQを晒しなさい。スクリーンショットも撮っとけよｗ

ちなみに、俺は107だった。世の中に俺よりIQ低い奴が30億人
くらい居ると思うと人生に希望が持てたよ（ ´,_ゝ｀）ﾌﾟｯ

お、122だ、嘘くせーテストだなｗ
30億人とかはどこに出るんだい？答えもみたいなぁ

ttp://64.233.179.104/search?q=cache:s3DZRuO65scJ:ja.wikipedia.org/wiki/%E7%B2%BE%E7%A5%9E%E5%B9%B4%E9%BD%A2+%E6%88%90%E4%BA%BA%E5%BE%8C%E3%81%AF%E3%81%82%E3%81%BE%E3%82%8A%E6%9C%89%E7%94%A8%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84&hl=ja&lr=lang_ja&inlang=ja
ココは子供が多いスレですね

19だからｷﾞﾘｷﾞﾘOKなのか？

デザインパターンの本読んでみたけど
「ふーん、こんなの普通に使ってるよ」ていうような手法が多かったな。

でも読む価値はある本だ。

ゲームに役立つパターンってありますか？

ビットパターン

切り番ゲットパターン

>>793
これスピード関係ねーのかな？
めっちゃくちゃ遅くても１３０とか出たぞ。

>>793
107ってめちゃ低いんじゃんひょっとしてw

>>802
100くらいが平均だと聞いたが。

>>798
ステートパターン
タイトル画面とかの状態をごちゃごちゃ入れ替えると楽

>>802
本来のIQテストは125を越えると天才で1300でルチ将軍と言われてる。

>>798
シングルトン一択。
>>804←馬鹿

そ、それはひょっとしてｷﾞｬｸﾞで言ってるのか…？

ギレン・ザビは180、だと思った。

その割にはアサーリ嵌められて氏んだなｗ

デザインパターンって「あるある」って思うパターンに名前付けただけだよね。
いろんな本にも書いてあるけど。

クラスを挟んでくっ付ける。ハイッ、ハイッ、ハイハイハイ？

>810
デザインパターンは「あるある」って思うパターンを名前付けて『整理した』ものです。
指南書ですな。

しかし、本を読まなければ「○○パターンですよ」とか言われても、書かれてもさっぱりですな。

なんだ、就業時間中から暇持てあましてるとは、
非就業者か社内失業者か、はたまた開店休業状態の会社の社員か？
ここに常駐している約一名の困ったチャンわ(w

>>798
> 品詞抽出法 (略) 動詞の解釈
ｼﾗﾈ〜ﾖ、そんなﾉｰﾀﾘﾝ方法論の詳細は。
不安だったら自分で調べたらどう？
ＤＢﾃﾞｰﾀの画面編集ｼｽﾃﾑに何十億もかけてる現場に行けば、
DOAの一環で名詞句抽出法業務辞書を作って、ﾃﾞｰﾀ項目候補にしているから、
そこで動詞の扱い聞いて来い(ﾜﾗ

(つづく)

Gag of Four ← ﾜﾛﾀ

>>798
> 仕様書に全て(の要求が)書かれているわけない

そこまで素人じみた考えする奴ぁ滅多に居ね〜よ。20年前の通産省のお役人ならいざ知らず(ｗ

ユースケース・シナリオを使ったユースケース分析の本でも読んで
機能要求文の名詞や動詞が､分析モデル(分析レベルのオブジェクト)のどんな要素に対応するか
そのﾉｰﾀﾘﾝ頭で考えれ(ｗ
話を即座に設計モデル〜実装に結びつけない慎重さが肝心だ(ﾜﾗ

> IQいくつ？
１８０

つか､素人がよく勘違いして騙されてるから警告のﾈﾀ振り

>>814を読んで、VC/Aliance先向け事業説明資料を書き直しているのが約一名

そーいえばakonて一体どーなったの？

>>816
それはひょっとしてｷﾞｬｸﾞで（ｒｙ

キチガイはさっさと氏ね

いやいやお兄さん

>（あなたの）その貧困なボキャブラリで(>>787を参照）
>こんなの（機能要求の分析）できるわけないじゃん...

っていう煽りなのよ>>798は
この程度の煽りは意図通り解釈して欲しかったなあ

なんか空回っちゃって周囲の人大変そうだな

まちがった

>>820
あえて釣られてやろう。お前最低だな。

相変わらず話の隅っこ突いて喜んでる幼い奴だなあ。

ここまでトロくて厚顔無知だと、周りの人達は大迷惑だよな(ぷ
akonもこんなにトロいのか？

Chain Of Responsibilityってどんな時に使うのか教えて下さい！

>>824
わかんねーもんわざわざ使おうとすんな！
馬鹿が！すっこんでろ！カス！クズ！ボケ！アホ！

このように直接回答することを避け、返答する人が見つかるまで繋げていく場合に使います。
詳しい話は更に↓で。

null

つーか、Chain Of Responsibilityで成功（？）した時に
値を返したい時ってどうすればいいの？

Escape from Responsibility

>828
というよりも、自分で処理できない時に、return中で委譲する関数を
呼出す（＝委譲する関数の返す値を返す）のが肝だと思うけど。

C++でも継続を扱えりゃあなぁ……

>>830
つ[longjump]

>>828
Commonsの実装ではChainに登録するCommandのインターフェイスは
こう定義されてる。

public interface Command {
　public boolean execute(Context context) throws Exception;
}

だから、Command間で共有したい値から、最後のCommandを実行した
後の返り値まで、全部Contextで盥(たらいってこんな字なの？初めて
知った（ ﾟдﾟ）ﾎﾟｶｰﾝ)回す。
成功と同時に以降のCommand実行を省略したいなら、executeメソッド
の返り値にtrueを投げてやればいい。
てか、教科書的な実装なんで、別にCommonsだからってわけでもないな。