トップページ⇒tech
981コメント402KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2005/06/19(日) 14:17:54
形を真似て形に入り
形を極めて形から自由になる

関連情報は >>2-10
0002デフォルトの名無しさん2005/06/19(日) 14:19:40
過去スレ
デザインパターンの単純そうな質問 - (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
0003デフォルトの名無しさん2005/06/19(日) 14:20:05
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
0004デフォルトの名無しさん2005/06/19(日) 14:20:21
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
0005デフォルトの名無しさん2005/06/19(日) 14:20:50
書籍
オブジェクト指向における再利用のためのデザインパターン
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/
0006デフォルトの名無しさん2005/06/19(日) 14:21:51
終了。後は焼くなり煮るなり好きにしてくれ。
0007デフォルトの名無しさん2005/06/19(日) 14:26:22
[録画開始済]
0008デフォルトの名無しさん2005/06/19(日) 14:39:59
デザパタ厨のこれまであった特徴
・自分の言葉で語れない　（技術者としてはずかしくないの？マジで）
・オブジェクト指向が理解できない　（おそらく　設計→ソース　にする段階で駄目なんだろうな）
・理論より実績にばかりコダワル　（とても技術者とは思えない）
・紹介する書籍はすべて読んで無い　（読んで無いもの人に奨めるな）
・デザパタを知らない人＝馬鹿　（そんなマイナーなもの常識にされてもね）
・設計の話をしているのにソースコードの提出を執拗に求める　（真性？）
・事実を捻じ曲げて正当化しようとする　（オブジェクト指向にはもう１つの意味が・・・って、ねぇよ）
・わかりやすく人に伝えようとする技術が欠落している　（オブジェクト指向が理解できない要因でもある）
・たまにデザパタ厨同士でデザパタについて話をしているが噛み合ってない場合が多い　（役に立ってねーじゃんｗ）

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

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

自分の言葉をもってないのがディスプレイ越しにわかるんだよ。
どう頑張ってもこういうの誤魔化すの無理だから。
同じような職場で似たような仕事してんじゃん。俺等。
思考回路も似たようなもんなのわかるんだよ。
0010デフォルトの名無しさん2005/06/19(日) 16:03:59
頭の狂ったOcaml厨ﾏ━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━ﾀﾞ????
0011デフォルトの名無しさん2005/06/19(日) 16:22:38
>9の通り、荒し（自演含む）が常駐しているので放置するべし。
特に“オブジェクト指向使えりゃデザインパターン不要”を唱えているやつ
……やっぱりID必要だわな。

上記の話題については
　　>前スレ6
　　デザインパターンというと、かつては
　　　　・コンポーネント設計のための指針
　　　　・設計へのデザパタ・テンプレートの導入
　　　　・クラス間の相互作用に基づく自己組織化(w
　　などという工学的な視点から語られる事もあったが、
　　最近は
　　　　・教育カリキュラムとしてのデザパタ
　　　　・企業アプリ構築ノウハウとしてのパターン
　　に力点が移動してきている。
0012デフォルトの名無しさん2005/06/19(日) 16:23:49
　　>前々スレ802-803(前スレ846)
　　>802
　　前スレどうだったっけ？と思って読み返してみたら、デザパタは
　　囲碁の定石みたいなものだってところで切れてた。
　　みたいじゃねぇよ！なんて終わり方だ⊂⌒~⊃｡Д｡）⊃
　　>803
　　「囲碁の定石」か。
　　囲碁は、ゲーム展開の状態数が極めて多いんで、
　　チェスのように機械で力づくで先読みをして、
　　人間のチャンピオンと対等に戦うようには、当分ならないそうだ。
　　(今後DNAコンピュータや量子コンピュータが実用になったら、ワカランけどｗ)
　　で、人間がそのような状態数の多いゲームをうまく扱うのは、
　　ヒューリスティックにパターン化をして、扱う状態数を圧縮してるのではないか、と。

あたりに最終的には落ち着いとります。
0013デフォルトの名無しさん2005/06/19(日) 16:30:18
定石よりは手筋のほうがしっくりくるよ。
0014デフォルトの名無しさん2005/06/19(日) 17:02:42
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)
0015デフォルトの名無しさん2005/06/19(日) 17:07:46
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
0016デフォルトの名無しさん2005/06/19(日) 17:16:44
実装上のTIP程度のものをデザインパターンとか称して馬鹿じゃねーの？ｗ
0017デフォルトの名無しさん2005/06/19(日) 17:29:12
なんでデザパタとMLってなかわるいの？　
0018デフォルトの名無しさん2005/06/19(日) 17:32:35
>>16
なぜそれじゃいけないのか？
もっと高尚・高度なものであるべきなんて思ってた？
0019デフォルトの名無しさん2005/06/19(日) 17:37:53
デザインパターンについて語る朝鮮人がいるスレはここですか？
0020デフォルトの名無しさん2005/06/19(日) 17:39:41
>>18
こんなゴミパターンいちいち登録させてたら、１ヶ月で１０００超えるｗ
パターン作るのはいいけどいい加減に使う方のこと考えたほうがいいよ。
人間がパターンとして利用しやすいのってどれくらいなのかだいたいの最適値を理解しなよ。
精々１０個ぐらいだよ。
0021デフォルトの名無しさん2005/06/19(日) 17:40:07
　　　　　　　　　−　注意と警告　−

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

【学習障害の特徴】

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

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

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

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

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

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

・相手の思いや感情を考えて、行動することが困難
　状況判断が苦手
　（人の嫌がることを言ったり、わがままを言う)
0022デフォルトの名無しさん2005/06/19(日) 17:40:47
>>20
おまえ、アフォか？
0023デフォルトの名無しさん2005/06/19(日) 17:42:45
この後、>>22がデザインパターンの未来を力説！
0024デフォルトの名無しさん2005/06/19(日) 17:44:38
もうさぁ、
「GoFデザインパターンは、ソフトウェア・パターンのプリミティブだから
パターン一つ一つは非常に単純だが、
より上位のパターンを記述する上で重要な基盤である」
つうことを理解できない構ってクンは放置して、
より高度なパターンについて語ろうよ。例えばPoEAAとか。
0025デフォルトの名無しさん2005/06/19(日) 17:45:19
>>24
設計にソースコードが出てくるデザパタにそんなもんは無いｗ
0026242005/06/19(日) 17:45:44
あ、俺これからディナーに出かけるから。
話題は後で振るね。じゃ
0027242005/06/19(日) 17:48:43
>>25
> 設計にソースコードが出てくるデザパタにそんなもんは無いｗ

↑この人変な妄想垂れ流してるな。日曜の晩にカワイソウな人だ
0028デフォルトの名無しさん2005/06/19(日) 17:51:33
>>24
夕飯はもう済んだのか？ｗ
0029デフォルトの名無しさん2005/06/19(日) 17:52:32
可哀想だからほっといてやれよｗ
0030デフォルトの名無しさん2005/06/19(日) 17:55:03
NGワード推奨：W
　　　　　　　　　　↑全角文字
0031デフォルトの名無しさん2005/06/19(日) 17:59:15
つか、オブジェクト指向を理解しなよ。
理解できないの？
0032デフォルトの名無しさん2005/06/19(日) 17:59:19
結局デザパタしかりかいできないからだろW
0033デフォルトの名無しさん2005/06/19(日) 18:00:42
オブジェクト指向を理解しないでデザパタしか理解していない？！
そんなことってあるのか？
0034デフォルトの名無しさん2005/06/19(日) 18:01:58
>>33
お前みたいなの。
0035デフォルトの名無しさん2005/06/19(日) 18:04:48
ゴミ以上のものではないね
0036デフォルトの名無しさん2005/06/19(日) 18:05:51
オブジェクト指向が理解できたら、デザパタをおかしいと思うだろ。普通。
0037デフォルトの名無しさん2005/06/19(日) 18:08:19
なんで？
おれは、あーなるほどと思ったけど
0038デフォルトの名無しさん2005/06/19(日) 18:10:14
>>37
>なんで？
嘘吐くな。
オブジェクト指向の場合、対象物をそのままクラスに写し取るだけだ。
デザパタなんてでる幕は無い。
0039デフォルトの名無しさん2005/06/19(日) 18:12:19
ゴキブリホイホイスレ！！！！！！！！！！！！！！
0040デフォルトの名無しさん2005/06/19(日) 18:14:42
そんなに違うパラダイムを受け入れるのが困難なのか？
柔軟性の無い奴らだなぁ。
0041デフォルトの名無しさん2005/06/19(日) 18:15:46
>>38
業務で大規模J2EEアプリケーションを組んだことあるか？
いちいちモデル抽出するよりもパターンに当てはめた方が圧倒的に効率的なんだよ。
業務では、効率的で誰にでもわかりやすい設計が一番正しいんだよ。
大規模プロジェクトで、メンバー全員に毎回毎回他人流モデルを理解させる労力なんて考えたくもない。
0042デフォルトの名無しさん2005/06/19(日) 18:21:37
>>41
>効率的で誰にでもわかりやすい設計が一番正しいんだよ。
デザパタの普及率について
0043デフォルトの名無しさん2005/06/19(日) 18:25:06
>>41
じゃあ、オブジェクト指向言語なんて使わなきゃいいじゃん。
何を基準にしてクラスを作ってて、どういう基準でメソッドを作ってるのかてんでバラバラなんでしょ？
最悪。絶対参加したくないプロジェクトだな。
0044デフォルトの名無しさん2005/06/19(日) 18:32:11
J2EEパターンなんてOOとは関係なし。
J2EEの構造上の欠陥・罠を避けるためのただのノウハウ集じゃん。正攻法とか以前の問題。
0045デフォルトの名無しさん2005/06/19(日) 18:33:38
どこがどうおかしいのか　俺にはわからない
たとえばなんだ？お前らの言うおかしいものとは
0046デフォルトの名無しさん2005/06/19(日) 18:35:23
＞ デザパタの普及率について
会社でも協力会社でも普通に使ってるよ

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

で、大規模J2EEアプリ組んだことあるの？
0047デフォルトの名無しさん2005/06/19(日) 18:35:39
>>45
誰に何の問題についてきいてんだよ。
アンカーもつけられないようじゃ話にならないよ。
0048デフォルトの名無しさん2005/06/19(日) 18:36:30
>>46
オブジェクト指向と関係無いことで騒がれてもねｗ
0049デフォルトの名無しさん2005/06/19(日) 18:36:40
J2EEに問題があるとすれば、どこ？
具体的に説明してほしい。
0050デフォルトの名無しさん2005/06/19(日) 18:37:51
なにも、問題は無い
デザパタ否定する者たちが、引くに引けなくなってどうしようもないのさ
0051デフォルトの名無しさん2005/06/19(日) 18:39:28
>>49
まず、J2EEがどうしてオブジェクト指向の話ででてくるのか説明してくれない？
0052デフォルトの名無しさん2005/06/19(日) 18:42:01
J2EEなどのデザインパターンというかフレームワークみたいなものを否定するなら、
その代替案はあるのか？
0053デフォルトの名無しさん2005/06/19(日) 18:42:22
否定するものが出したからだろ？
J2EEパターン
0054デフォルトの名無しさん2005/06/19(日) 18:44:51
>>52
そもそも触ったこと無いから、まずいもなにも知らないんだけど。
0055デフォルトの名無しさん2005/06/19(日) 18:45:21
言って置くが、
デザインパターンのなかにJ2EEパターンといわれるものは当然含まれていることは分かっているよな
もしこのスレタイ通りGoFのみならばそれで語るのもいいが
内容は変わらない
0056デフォルトの名無しさん2005/06/19(日) 18:45:56
>>55
それも知らない。J2EE触ったこと無いし。
0057デフォルトの名無しさん2005/06/19(日) 18:46:44
J2EEパターンがOOの正攻法とでも？ｗ
0058デフォルトの名無しさん2005/06/19(日) 18:48:28
ていうか>>41がJ2EEをなんのつもりで出したのか正直わからないな。
0059デフォルトの名無しさん2005/06/19(日) 18:48:48
ここのアンチは、何のフレームワークにも頼らずに、
案件ごとにフルスクラッチでプログラミングしてるのだろうか？
0060デフォルトの名無しさん2005/06/19(日) 18:50:26
>>59
てゆうかJ2EE知らない時点でその扱い？ｗ
Javaの仕事に当たったことが無い時点で知らないでしょうよ。
0061デフォルトの名無しさん2005/06/19(日) 18:56:28
>>58
OO原理主義者は、GoFや、それをJ2EE向けにアレンジした
デザパタなどを使わないで
毎回、すべてのクラスをモデリングするんだろ？
２億超規模の案件で毎回そんなことするのかと思うと気が狂いそうになる。
0062デフォルトの名無しさん2005/06/19(日) 18:57:08
Javaやってない奴はOOやってない扱いなんだ？ｗ
デザパタ信者はSmalltalkはやってるの？ｗ
0063デフォルトの名無しさん2005/06/19(日) 18:58:30
じゃあ、何について知っているんだい？C++？
0064デフォルトの名無しさん2005/06/19(日) 18:58:53
>>62
その理論だとsimulaからやってもらわないと納得いかない。
0065デフォルトの名無しさん2005/06/19(日) 19:02:05
フレームワークとデザインパターンはちょっと違うような
0066デフォルトの名無しさん2005/06/19(日) 19:02:29
面と向かってこんな子供の口喧嘩見たいなことはやらないだろ？おまえら？
いい年して恥ずかしいと思え
まともに議論できないのか？
チョコチョコ書くから誤解を招くんだ
最低意味のある400文字ぐらい書け
小出しにするからﾂﾏﾗﾝこと食いつかれる
小出しにするから誰が誰かわからなくなる
0067デフォルトの名無しさん2005/06/19(日) 19:03:31
>>63
オブジェクト指向だよ。
0068デフォルトの名無しさん2005/06/19(日) 19:03:59
コミュニケーションが下手なんです。
0069デフォルトの名無しさん2005/06/19(日) 19:07:12
>>67
オブジェクト指向っていっても脳内だけの話だと何の役にも立たないのでは？
オブジェクト指向プログラミングをサポートする言語を使用してそれを実現しないと...

で、どんなオブジェクト指向言語を使用してるんだい？
0070デフォルトの名無しさん2005/06/19(日) 19:08:48
ダメだこりゃ・・・
どっちも口喧嘩に勝つ方法しか考えていない
0071デフォルトの名無しさん2005/06/19(日) 19:11:18
>>69
主にC++を使っておりますよ。
0072デフォルトの名無しさん2005/06/19(日) 19:11:52
いや、マジでアンチが使用しているオブジェクト指向言語には興味があるよ。
なに使ってるんだろう？
0073デフォルトの名無しさん2005/06/19(日) 19:12:34
OCamlです。
0074デフォルトの名無しさん2005/06/19(日) 19:14:28
アンチはどの程度の規模でどんなアプリを組んでいるのか？
規模はプロジェクト予算でも、人月でもいいよ。
0075デフォルトの名無しさん2005/06/19(日) 19:14:29
>>72
だからC++だって。
0076デフォルトの名無しさん2005/06/19(日) 19:16:13
>>74
３年かけてゲーム作ったことありまする。
転職して、３ヶ月でウィンドウズアプリ作ったこともありまする。
0077722005/06/19(日) 19:18:39
>>75 スマン、タイミングがずれちまった。

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

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

これって問題あると思う？
0078デフォルトの名無しさん2005/06/19(日) 19:19:35
>>76
とても仕事でプログラミングしてる奴の発言とは思えない。
規模を言えといってるのに。

＞３年かけてゲーム作った
＞３ヶ月でウィンドウズアプリ作った
0079デフォルトの名無しさん2005/06/19(日) 19:24:13
なんでJava（特にJ2EE）も知らないでパターン適用を全否定できるのか、アタマの構造を疑うな。
自分が今まで関わってきた分野に関してはOOでいけるってだけだろ？
0080デフォルトの名無しさん2005/06/19(日) 19:25:03
>>77
デザパタとなんの関係が？

>>78
いちいち人を馬鹿にするのが好きだね。
人数はプログラマだけ？デザイナ、サウンド、その他含めた数をいうの？
全部合わせると１００人越えると思うんだけど。
予算なんて知るかよｗ
0081デフォルトの名無しさん2005/06/19(日) 19:26:27
>>79
Javaを知らない奴は全員馬鹿ですか？そうですか（苦笑ｗ

＃単に自分のやってきた分野がJavaだけだっただけだろｗ
0082デフォルトの名無しさん2005/06/19(日) 19:28:37
>>80
開き直るなよｗ
0083デフォルトの名無しさん2005/06/19(日) 19:32:50
ＯＯで行ってるってことは知らず知らずデザパタになっているのでは？
0084デフォルトの名無しさん2005/06/19(日) 19:32:56
>>80
えっ？？？なんでこんなレスが？

私は、C++でオブジェクト指向プログラミングの範疇から外れた、
templateを使用した「デザインパターン」を使ってプログラミングしているのですが、
このような開発スタイルについて、「具体的」な問題点があれば例示していただけないでしょうか？
0085デフォルトの名無しさん2005/06/19(日) 19:33:47
>>83
大体その場合が多いと思うけどね。
本人が気づいてないだけで。
0086デフォルトの名無しさん2005/06/19(日) 19:33:53
100人だって・・・もろ失敗プロジェクトジャン
0087デフォルトの名無しさん2005/06/19(日) 19:35:49
お前らが普段利用しているJavaのAPIの中にもそんなのゴロゴロしているんだが
それを知っててooさえ知っていればっていうのはおかしいよなぁ
知らないのなら、まぁ勘で喋ってたんだなって納得できるんだけど
0088デフォルトの名無しさん2005/06/19(日) 19:37:28
>>83
何度もいうけどオブジェクト指向とデザパタは水と油だ。
0089デフォルトの名無しさん2005/06/19(日) 19:38:01
>>88
>>87
頭冷やして来い
0090デフォルトの名無しさん2005/06/19(日) 19:39:50
>>88 その理由も前スレかどっかに書いてある？
0091デフォルトの名無しさん2005/06/19(日) 19:40:13
>>84
要するに何がいいたいの？
デザパタを使ってることについてどう思うか聞きたいんでしょ？

テンプレートを使ったデザパタでも、テンプレートを使わないデザパタでもデザパタはデザパタだよね？
>>77ってテンプレートの話からしたからすげーわけわかんなかったじゃん。
なんか違うの？
0092デフォルトの名無しさん2005/06/19(日) 19:40:32
>>90
ありまくり。
0093デフォルトの名無しさん2005/06/19(日) 19:41:06
>>90
うざいぐらい書いた。
そのたびに荒らしだのなんだの言われまくった。
0094デフォルトの名無しさん2005/06/19(日) 19:42:11
まぁ、勘違いしてたってことで勘弁してくれや
0095デフォルトの名無しさん2005/06/19(日) 19:42:44
一番明確に書いている奴を教えてくれ>>93
0096デフォルトの名無しさん2005/06/19(日) 19:44:49
>>81
Javaを知らないのが馬鹿だなんて言ってないだろ。
パターン適用が有効である分野があることを知らないで全否定するのは馬鹿だと思うがね。
0097デフォルトの名無しさん2005/06/19(日) 19:46:13
＞パターン適用が有効である分野
分野ってなんの分野だ？J2EE、J2SDK？そんなの関係ないと思う
0098デフォルトの名無しさん2005/06/19(日) 19:48:01
>>95
これ↓

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

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

だったはずだ。
要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
この基本は絶対に変わらない。
プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
無かったら真っ先に担当者を問い詰めることができる。
これがオブジェクト指向の単純な利点だ。
0099デフォルトの名無しさん2005/06/19(日) 19:51:12
>>88
「水と油」だけでは分からないと思うぞ。
具体的なパターンと、それを利用するとどのような具体的な害があるのか説明してやらねば。

言語はC++でな。
0100デフォルトの名無しさん2005/06/19(日) 19:51:42
>>96
何が言いたいの？この人？
わけわかんない。

俺はデザパタはオブジェクト指向にのっとってねーぞ。
C++使ってやんじゃねーよボケ。っていいたいだけなんだけど。
0101デフォルトの名無しさん2005/06/19(日) 19:52:24
>>99
アプローチから間違ってるっていってるのがわからないのか？
何度言わせるんだ？
なんでソースが必要なんだ？
0102デフォルトの名無しさん2005/06/19(日) 19:53:04
>>98
言っていることはよく分かった
しかし、DPとの水と油関係はその話からは見えないよ
あのさぁ
日本人がよくオブジェクト指向を初心者に分かりやすく解説するときに
オブジェクト＝物って言う教え方しているけどあれをそのまま飲み込んでいないか？

オブジェクト指向は「物」の考え方もあれば「機能」でわける方法もあるということをお忘れなく
J2EEパターンで利用されているのは機能に着目したOOPです
0103デフォルトの名無しさん2005/06/19(日) 19:53:58
>>100
なぜC++限定？
Javaはオブジェクト指向言語ではないとでも？
0104デフォルトの名無しさん2005/06/19(日) 19:56:01
>>102
だからー。
デザパタってのはあるパターンがあってそれに当てはめる過程を必ずたどるわけじゃない？
俺はそこがまずいっていってんの？わかる？
0105デフォルトの名無しさん2005/06/19(日) 19:56:37
>>103
いや、オブジェクト指向言語って意味で書いた。（こういうのいちいち説明させるのか？ｗ）
0106デフォルトの名無しさん2005/06/19(日) 19:57:17
>>100
デザインパターンを利用したプログラミングが、
由緒正しいオブジェクト指向に従っていないとするのはいい。
特にC++だとtemplateが絡むとデザインパターンは、
オブジェクト指向プログラミングとは別の次元になるし。

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

「悪」であるとするなら、その理由を述べよ。
0107デフォルトの名無しさん2005/06/19(日) 19:57:20
>>104
そういうやり方はデザパタの本質ではない
それはここにいるデザパタを（立場的に）擁護している人たちは知っています
0108デフォルトの名無しさん2005/06/19(日) 19:57:23
>>97
ここで話題になっているのはJ2EE SDKじゃなくて
J2EEテクノロジを利用したエンタープライズアプリケーションだ。
Servlet/JSP/EJB等のJ2EEに含まれる技術を利用したアプリで、
J2EEパターンなどを一切無視して全てのクラスを毎回抽出するのか？
0109デフォルトの名無しさん2005/06/19(日) 19:58:13
>>98
つまり自然にオブジェクトにすることが可能な対象を、
パターンに当てはめるために歪めるのが悪いってことか？
歪めるプログラマが悪いんであって、
パターン自体が悪いとは思わないなぁ。

とかいう反応ぐらいあったと思うから、
その書き込みへのリンク貼って欲しいな。
0110107続き2005/06/19(日) 19:58:49
>それに当てはめる過程を必ずたどるわけじゃない？
無理やりこんなことやる人はいないです
01111072005/06/19(日) 20:01:12
もし、あなたが
>それに当てはめる過程を必ずたどるわけじゃない？
と考えているのであれば
DPを無理やり使いたがる人と同じです
あなたが思うよりもDPを擁護する人たちは
きちんとその辺の距離を置いていますよ
0112デフォルトの名無しさん2005/06/19(日) 20:04:52
>>106
オブジェクト指向言語でそれをやっちゃうのは駄目じゃない？
原点に戻るけどオブジェクト指向言語っつーのはオブジェクト指向を実現するために・・・以下略
もういいだろｗ

この理由が駄目な理由として受け入れられないとなると
そもそも言語の設計理念を無視して進んじゃってるわけだからもうなにもいうことはないな。
0113デフォルトの名無しさん2005/06/19(日) 20:05:45
>>104
つうかそれって結局使い手に依存する話なんだよね
0114デフォルトの名無しさん2005/06/19(日) 20:05:53
つーか、「設計が下手糞」って言えばいいのか。
開き直って「それがどうかしましたか？」っていわれりゃそれまでだなｗ確かにｗ
0115デフォルトの名無しさん2005/06/19(日) 20:07:55
DPの本とかにも結局、あなたの言うように何でもかんでもDPに当てはめてつくるという事はしないように注意書きがある
読んでいる人であればそれを理解しているはず
0116デフォルトの名無しさん2005/06/19(日) 20:09:20
（例えば大規模J2EEアプリの開発の現場など、）
本来のオブジェクト指向に則った設計だけでは
立ち行かなくなってる現実があるからこそ、
パターンが生まれたのでは？
実際、毎回OOに則って全てをオブジェクトモデリングしていたら
気が狂うと思うけどね。
0117デフォルトの名無しさん2005/06/19(日) 20:11:10
J2EEパターンの場合、規約的な意味合いもあるかも知れない
0118デフォルトの名無しさん2005/06/19(日) 20:17:04
>>116
>本来のオブジェクト指向に則った設計だけでは 立ち行かなくなってる現実があるからこそ
いや、このスレの奴等は必ず、デザパタがオブジェクト指向にのっとっているものだと
信じている奴等ばっかりだった。>>83,85等←こんなこと言ってる奴のが多い現実。
オブジェクト指向を理解できない奴がデザパタへ逃げるんだよ。
俺はこれが残念でならなくてね。
0119デフォルトの名無しさん2005/06/19(日) 20:23:52
>>118
デザパタはオブジェクト指向言語の機能を利用した物ではあるからな。
勘違いとか、オブジェクト指向という言葉の定義が曖昧なままスレが進んでいるようにも思えてきた。
0120デフォルトの名無しさん2005/06/19(日) 20:25:41
>>112
プログラミング言語というものはオブジェクト指向を実現するためだけに
あるのではないでしょ。C++なんか特にそう。

オブジェクト指向だろうがデザパタだろうが有効なものは使ってしまえという発想が
なぜいけない？
0121デフォルトの名無しさん2005/06/19(日) 20:30:56
>>120
さすがに　はぁ？　って感じｗ
0122デフォルトの名無しさん2005/06/19(日) 20:31:06
このスレで>>116、>>118が一番分かりやすかった。
0123デフォルトの名無しさん2005/06/19(日) 20:32:26
>>112
C++はオブジェクト指向言語ではない。
0124デフォルトの名無しさん2005/06/19(日) 20:39:06
＞ オブジェクト指向を理解できない奴がデザパタへ逃げるんだよ。
それはどうかな？
オブジェクト指向をわかってないとデザパタの存在意義や目的が理解できないと思うけど。
0125デフォルトの名無しさん2005/06/19(日) 20:46:55
>>124
だね。実際にプログラミングして設計に失敗した経験がないと、
パターンのありがたみは分かり難いと思う。
0126デフォルトの名無しさん2005/06/19(日) 21:07:13
>>124-125
じゃあ、>>83,85みたいな奴はなんなのかと。
こいつらはデザパタ破門ってことでいいですか？
0127デフォルトの名無しさん2005/06/19(日) 21:14:11
>>126
デザパタ破門ってよくわからんが・・・
>>119 のようなことなのじゃないのか？
そいつらの頭の中では
オブジェクト指向言語の機能を利用していることと本来の意味でのオブジェクト指向設計が同義に
なってるのだと思う。
0128デフォルトの名無しさん2005/06/19(日) 21:17:43
>>127
なにがいいたいのか全くわかんねー
0129デフォルトの名無しさん2005/06/19(日) 21:18:59
>>127
書き込んだ後一瞬で理解したｗすまんこｗ
0130デフォルトの名無しさん2005/06/19(日) 21:37:46
OCamlが悪いとは言わないが、使っている人間が糞では、
どうしようもありませんねｗｗ
0131デフォルトの名無しさん2005/06/19(日) 21:39:43
デザパタが駄目、
オブジェクト指向か駄目、

というより、

日曜の晩にこんな所で不毛な議論してる奴の
人間性が駄目
0132デフォルトの名無しさん2005/06/19(日) 22:04:51
>>131
オマエガナ
0133デフォルトの名無しさん2005/06/19(日) 22:08:53
たかが道具ごときに信者とかアンチとか騒いでる俺らもバカ
0134デフォルトの名無しさん2005/06/19(日) 22:13:22
おれならMLでスマートに書くんだけどねｗ
0135デフォルトの名無しさん2005/06/19(日) 22:20:45
ここ読んでたら、実務経験のみを参考に雇用許否を決定する現在の
システムは、問題も持ってるけど理には適ってるなと思った。
0136デフォルトの名無しさん2005/06/19(日) 22:58:39
>>135
確かに。机上の空論程度にしか理解してない癖に、偉そうに語るアホが
一人いるね。
0137前8372005/06/19(日) 23:00:50
お前ら名無し止めろ。誰がどの立場で話しているのかわからん。
ML／OCalm推薦しているやつとオブジェクト万能論のやつは
別人ということでいいのか？

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


0138デフォルトの名無しさん2005/06/19(日) 23:07:17
>>137
お前どうして、設計の話してんのにソースコードばっかり欲しがるんだ？ｗ
0139デフォルトの名無しさん2005/06/19(日) 23:20:31
あぁぁらら・・・。
屑が粘着してるからやめとけっつってるのに、
いつの間にやら某自称コンサルの人まで参戦してる・・・

・・・所詮この程度の人だったのか。残念なことだ
0140デフォルトの名無しさん2005/06/19(日) 23:21:56
いや〜C++でやるデザパタは最高やねｗｗ
0141デフォルトの名無しさん2005/06/19(日) 23:25:38
自分の意見に自信がないからコテにできないんだよｗ
0142デフォルトの名無しさん2005/06/19(日) 23:25:47
つーか、設計の話してるのにソースコード欲しがる消防レベルのＰＧは
この先どうするんだ？そんなに馬鹿で。マジで心配になるよ。
0143デフォルトの名無しさん2005/06/19(日) 23:26:48
>>142に心配されたら本気で終わりだな。
0144デフォルトの名無しさん2005/06/19(日) 23:27:22
>>141
俺は一貫してデザパタがオブジェクト指向から
外れていることを唱えているからコテにしなくても一目瞭然だな。
0145前8372005/06/19(日) 23:31:19
>138
設計をやらせるためにアーキテクトを雇うのならソースコードはいらんでしょうな。
そんときゃUML書かせるのかね？

……だから誰が何の話しているのか良くわからんつうとるだろうに。
実装レベルの設計とシステムレベルの設計がごっちゃになって疑似問題起こしてるよ。
0146デフォルトの名無しさん2005/06/19(日) 23:34:27
まぁデザパタは実装をターゲットにした詳細設計レベルのパターンである
という点については、誰も反論がないだろう。

このレベルで反論してくるヤシは、プログラムなどやった事もないど素人の煽り。
0147デフォルトの名無しさん2005/06/19(日) 23:38:39
>>146
つーか、オブジェクト指向に基づいてもいないから使う意味もないね。
0148デフォルトの名無しさん2005/06/19(日) 23:39:40
↑とりあえずGoFのデザパタの件ね。>>実装前提のパターン

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

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

ま、プログラムも設計もした事ないのに煽ってる素人の人には、
まるっきり関係ないけどな
0149デフォルトの名無しさん2005/06/19(日) 23:40:38
>>147
お前はさぁ、キチガイ病院に早く入院したほうがいいと思うよ。
そのうちどうせ、通りに出て無差別殺人とかやるんだろ
0150デフォルトの名無しさん2005/06/19(日) 23:48:19
>>148
そういうのおぼえんの面倒臭ぇじゃん。
オブジェクト指向１つで解決するならその方がいいと思わない？
ま、そのオブジェクト指向が理解できないのが問題なんだろうけどさｗ
0151前8372005/06/19(日) 23:49:12
>144
>デザパタがオブジェクト指向から外れていることを唱えているから
それではわからんて。いろんなヤツが「オブジェクト指向とデザパタは別物」と
発言しているからな。
それに>147 >150 みたいなバカな発言もお前のということでいいの？

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

>147
良くいった。オブジェクト指向に基づいていない手法（構造化とか総称性など）
は使わないつうことだな。ガンがれ。
0152デフォルトの名無しさん2005/06/19(日) 23:54:13
>>151
設計の話でソース欲しがるおめーはアホだからもう寝ていいぞｗ
0153デフォルトの名無しさん2005/06/19(日) 23:59:58
>>152
　>>146
　バカはお前
0154デフォルトの名無しさん2005/06/20(月) 00:04:35
詳細設計とかしたこと無いんでしょ。
許してあげな。
0155デフォルトの名無しさん2005/06/20(月) 00:11:04
>>137
実務経験ない奴はそのトライアルへの参加資格すらない。
そもそも、実際に人を動かす型の雇用試験はコストが掛かりすぎる。
実務経歴を用いた机上トライアルで篩い、残りを仮実務によるトライ
アルに掛けるというのが現実解だろう。
0156デフォルトの名無しさん2005/06/20(月) 00:24:13
馬鹿ばっかり。。。
0157デフォルトの名無しさん2005/06/20(月) 00:27:36
プログラム技術板に強制ID制を導入すべきか否か
http://etc4.2ch.net/test/read.cgi/vote/1118144381/
0158デフォルトの名無しさん2005/06/20(月) 00:29:57
ID ついても馬鹿は馬鹿でしょ。
0159デフォルトの名無しさん2005/06/20(月) 00:35:35
今北産業。
なにこのスレの成長具合？ｗｗｗｗｗｗ
プログラム板でまれに見る良スレじゃねｗｗｗｗｗｗｗｗ
0160前8372005/06/20(月) 00:36:55
>155
まあ、そのための試用期間だしね。
ただ、一度現場に引き入れた人間にダメ出しするのは色んな意味で難しそう
……てかよほどダメじゃないと普通無理だよ。

>137 >142 >152
だからお前誰だよ。
ちなみに>145で
　プログラマ募集時：ソースコードで判断
　アーキテクト募集：UMLなど設計の成果物で判断
のようなこと言ってるんだけどな。
0161デフォルトの名無しさん2005/06/20(月) 00:39:08
>158
いいんだよ。バカのIDが識別できれば。自作自演もわかるしね。
0162デフォルトの名無しさん2005/06/20(月) 00:39:59
発言に継続性が生まれれば、発言者の中身が見えてくるし
誰がどの立場で話してるかも分かる。
0163デフォルトの名無しさん2005/06/20(月) 00:41:35
困るのはあのコピペ野郎と人をキチガイ扱いする・・・やっぱりコピペ野郎かｗ
俺は一貫してデザパタはオブジェクト指向では無いと・・・略ｗ
0164デフォルトの名無しさん2005/06/20(月) 00:42:26
キチガイはキチガイじゃん。誰が見てもわかるよ。
気がつかないのは本人だけ。ﾜﾛｽｗ
0165デフォルトの名無しさん2005/06/20(月) 00:47:25
>>163 頼むからコテハン付けて
0166デフォルトの名無しさん2005/06/20(月) 00:49:27
ＩＤはつけてほしいね。自作自演乙とか言われても困る。
俺、前スレで「自作自演乙」とか2回も言われた。してねぇちゅーの。

ところで、なんか最近このスレのレスがvip化してるような気が・・・ﾜﾛｽとかｶﾜｲｿｽとか。ﾃﾗﾜﾛｽｗｗｗｗ
0167デフォルトの名無しさん2005/06/20(月) 00:57:41
>>166
その手の語尾はどういう意図で付けてるんだろう？
それだけで馬鹿っぽく見えてしまうから、発言の価値を
下げてしまって損だと思うんだけど？
文章を図的に見た場合に注意を引きやすいとかの効果
が期待されてるのかな？
01681662005/06/20(月) 01:07:42
マジレスで。
私も最初は>>167氏と同じ意見（馬鹿っぽく見える）でしたが
ニュー速vipという板を見に行くとみんな普通につけているので感覚が麻痺します。
スレ違いで申し訳ないですが一応レスを返しておきます。
0169デフォルトの名無しさん2005/06/20(月) 01:23:13
。の変わりだと思うと気が楽だよｗ
0170デフォルトの名無しさん2005/06/20(月) 04:01:06
みんなの語尾がおかしいわけではなく、
約一名変なのがしつこく粘着しているだけ。
0171デフォルトの名無しさん2005/06/20(月) 04:39:43
ｗが3つ以上並んでいて、かつ読む価値のあるﾚｽというものを
見たことがない。
0172デフォルトの名無しさん2005/06/20(月) 04:48:48
全角ダブリュー３つはNGワード推奨。
括弧開く全角ダブリューおよび全角ダブリューは、
多くの人々が使うが、この板では意味のない発言に付く事が極めて多い。
0173デフォルトの名無しさん2005/06/20(月) 05:38:20
>>172
うっせハゲ
0174１５2005/06/20(月) 05:48:18
うは。URL間違えた・・・

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

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

の間違いです。訂正してお詫びいたしますです。
0175デフォルトの名無しさん2005/06/20(月) 06:03:19
>>147って冷静に考えたら凄い発言だ。
いったい>>147はふだんどんな言語を使っているんだろう？
0176デフォルトの名無しさん2005/06/20(月) 06:04:52
脳内言語
0177デフォルトの名無しさん2005/06/20(月) 06:09:35
>>175
OCaml。ﾃﾗﾜﾛｽｗｗｗ
0178デフォルトの名無しさん2005/06/20(月) 06:10:28
以前この板で、
「アスペクト指向は、オブジェクト指向を前提とした技術ではないが、
　現在最も普及しているのがオブジェクト指向言語だから、
　オブジェクト指向言語の拡張としてアスペクト指向言語が実装されている」
という話をした事がある。
「オブジェクト指向を前提としてはいない」＝「ポスト・オブジェクト指向」というニュアンスなのだが。

ここに居る「デザパタはオブジェクト指向ではない論者」は、
上記の話のバリーエーションで、なんか変な妄想(プログラムできない素人の妄想)をして
変な煽りをやっているだけだろう。
キチガイじみた煽りっぷりを見れば、まともに相手にしてもしょうがない事がわかると思うが。
0179デフォルトの名無しさん2005/06/20(月) 07:06:23
>>178
断片的に現れる電波じみた書き込みを見ると、どうも彼は

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

という考えに囚われている気がする。
0180デフォルトの名無しさん2005/06/20(月) 07:07:33
MVC with Objective Caml
http://www.lri.fr/~signoles/mvc.en.html


0181広義の設計パターンと関数型言語2005/06/20(月) 07:19:10
広義の設計パターンと関数型言語について、
こういう言い方をする人も居る。

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.
0182デフォルトの名無しさん2005/06/20(月) 07:45:53
>>181
読めないよ。
全部訳してそれに対する自分のコメントふれって言ってるだろ。
なんで人の言葉を借りなきゃしゃべれないんだ。お前は
0183デフォルトの名無しさん2005/06/20(月) 07:46:24
>>179
そんなこといってないじゃん。
捏造までするのか？
0184デフォルトの名無しさん2005/06/20(月) 07:51:01
>>182-183
英語読めない人間が偉そうな口聞くな。
逝ってよし
0185デフォルトの名無しさん2005/06/20(月) 07:51:54
イマドキ、学部生どころか高校生だって英語読めるわよねぇ〜（ｷｬﾊ
0186デフォルトの名無しさん2005/06/20(月) 07:54:11
>>181
こういうレスが一番むかつくんだ。
自分で読んですらいない文章だから、コメントも付けないで貼り付けるんだろ。
本当に読んでいるならそれに対する自分のコメントを添えろ。

いざとなったら、著者の実績を盾にして内容の正当化をしようとしてるのがみえみえなんだよ。
あいかわらず卑怯な発言ばっかりしやがって。
てめぇは自分の言葉ももってねぇくせに発言するんじゃねぇ糞が！
ホントクズにもほどがある。
死ね。もうてめぇは勉強なんてする必要ねぇだろ。
0187デフォルトの名無しさん2005/06/20(月) 07:57:03
デザパタ信者でもこういう自分の言葉ももってねぇで
リンクばっかり貼り付けるクズ野郎の扱いってのはどうしたもんだろうね。
0188デフォルトの名無しさん2005/06/20(月) 07:57:50
内容云々の前に技術者としてこんな卑怯な奴絶対に認めるわけにはいかないよ。
0189デフォルトの名無しさん2005/06/20(月) 07:58:28
> 全部訳して

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

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

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

あんたを説得するなんていう苦難苦行をやるつもりは一切ない。
あんたみたいなのを相手にするほど、こちらは暇ではない。
0190デフォルトの名無しさん2005/06/20(月) 07:59:48
>>186-188
英語読めないって、もしかして中学も出てないのか？

月曜朝から気分の悪いコメントを書きまくる
お前の人間性は最悪だ
0191デフォルトの名無しさん2005/06/20(月) 08:02:28
【NGワード推奨】
自分で読んですらいない
自分の言葉ももってねぇ
卑怯な
0192デフォルトの名無しさん2005/06/20(月) 08:04:29
>>190
俺の文章読んで要点が英語だけだと思うほどお前は馬鹿なのか？
0193デフォルトの名無しさん2005/06/20(月) 08:06:08
おまえの文章なんてNGワードだらけだから読むわきゃねーだろ
0194デフォルトの名無しさん2005/06/20(月) 08:06:39
>>181
なんだろうね。こいつ。
もう性根から腐ってる。
一体、どんな教育受けてきたのかマジで不思議でしょうがないよ。
どうやったらここまでキタネェ奴を育てることができるんだ。
もう、根本から糞。人として駄目。マジで吐き気がするわ。
0195デフォルトの名無しさん2005/06/20(月) 08:10:25
一時期荒らしが粘着していた某板の某スレは、
最近なかなか良い感じになってきて、
打てば響くようなレスがなかなか心地良いんだが、
こっちのスレはどうしようもねぇな。

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

世界はおめぇ中心に回ってるんじゃねぇんだよ
さっさと巣に帰ってブルブル震えてろって
0196デフォルトの名無しさん2005/06/20(月) 08:12:04
朝鮮人か支那人かもしれんね。ここまで薄汚いと。
0197デフォルトの名無しさん2005/06/20(月) 08:13:08
>>181
なんで他の人間の言葉を借りなきゃしゃべることができないんだ？
匿名掲示板ですら自分の意見を自分の言葉で言えないのか？

マジでこいつとは育った環境や文化からちがうんじゃないかと思うよ。
0198デフォルトの名無しさん2005/06/20(月) 08:15:25
>>197
そうだねぇ、キミとは随分育ちが違うと思うよ。
普通に英語の読み書きできるし、普通に仕事してるし、
博士課程もでてるし、
匿名掲示板で無視されたからって朝から荒れたりしないし。
0199デフォルトの名無しさん2005/06/20(月) 08:15:53
同じ内容のレスを繰り返すのはなぜですか？
02001982005/06/20(月) 08:17:23
たぶん頭が悪いから、相手を同じ言葉で罵詈雑言する事でエクスタシーを感じてるんじゃないかな。

普通に仕事してる人間は、月曜朝からこんなキチガイじみた書き込みをしないと思うけど
0201デフォルトの名無しさん2005/06/20(月) 08:22:22
もしかしてここ荒らしてるのは、
「『今度は逃げない』と言って、また(業務コンサルの)会社を作った人」
だったりして
0202デフォルトの名無しさん2005/06/20(月) 08:29:23
>>197
文章にオリジナリティを求めるなら、その内容でしょ。
文章の表現にオリジナリティを求めるなとは言わないけど。

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

そりゃ、分かりやすいように表現してくれるほうがありがたいが、
間違ったことを（しかも主観まじりの）書かれるよりはよっぽどいい。
0203デフォルトの名無しさん2005/06/20(月) 08:32:02
>>202
ほう、では>>181の英文の内容を、大まかでいいから、意訳してみろよ。
読めるという証拠に。自分は普通に読めるからする必要がない、という
方向はなしで。

そんな事もできないようだったら、お前の協調性はゼロだ。社会に出ても
だれもまともに相手もしてくれないだろう。
0204デフォルトの名無しさん2005/06/20(月) 08:33:37
>>203
俺は202じゃないけど、
人に物を頼むときはそれなりの礼儀が必要なんじゃないかな。
ましてやアンタは札付きの荒らしなわけだし。善意を持って接する必然性がない。
0205デフォルトの名無しさん2005/06/20(月) 08:35:35
>>204
言うと思ったよ。なんだかんだ理由つけて、結局英語読めないんじゃん。
だからここにいる皆に嫌われるんだよ。わかる？わからないだろうな。
0206デフォルトの名無しさん2005/06/20(月) 08:40:23
>>203
やってもいいけど、タダではやれない。
あなたに技術的文書を理解させるのが私の仕事でない。

>>181で書いてあることがを理解したと思うのなら、あなたが読みなさい。
でも、翻訳した文書を貼り付ける必要はありません。
0207デフォルトの名無しさん2005/06/20(月) 08:40:45
こ　こ　に　は　ま　と　も　な　人　は　一　人　も　い　な　い　ん　で　す　か？
0208デフォルトの名無しさん2005/06/20(月) 08:45:31
>>206
お前が>>181か？
英文なんて貼ったら荒れるに決まってんだろ。
そんなことも分からないほどバカなのか？
0209デフォルトの名無しさん2005/06/20(月) 08:47:53
>>206
＞あなたが読みなさい。

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

こんなの機械翻訳に掛ければ今時辞書など見ずともおおよその意味くら
い誰でもわかる。しかしお前はタダではできないとか、本質的な理由とは
おおよそ違った事を言いながら、結局は何もしようとしない。
0210デフォルトの名無しさん2005/06/20(月) 08:51:04
>>206
君の底の浅さが知れたよ。アホだね。
0211デフォルトの名無しさん2005/06/20(月) 10:11:19
アンチの特徴：具体例を求められると断固として拒否。
例：「ソース出せ」「設計出せ」「訳してみろ」「じゃあお前はどんな方法使ってるの？」などなど。
0212デフォルトの名無しさん2005/06/20(月) 10:27:02
また穀潰しが仕事もしないで
昼間っから掲示板に粘着してんのか
0213デフォルトの名無しさん2005/06/20(月) 10:31:58
>>209
英語読めないのからかうと面白すぎだな。
まず>>209が訳してみろ(ﾜﾗ
0214デフォルトの名無しさん2005/06/20(月) 11:10:47
MonadicなアプローチなんてまともにサポートしてるのってHaskellぐらいなもんでしょ。
少なくともOCamlは違う。ｗ
0215デフォルトの名無しさん2005/06/20(月) 11:37:38
相変わらず乞食みたいなのがしつこく荒らしてるな。

そろそろ語尾ｗくんと罵詈雑言くんはデフォでスルー、
何言っても相手しないって事でいいとおもう。
0216デフォルトの名無しさん2005/06/20(月) 11:51:22
>>202
だよなぁ。
プログラミングにしたって、ユニークなアルゴリズムは歓迎されるけど
ユニークなコーディングスタイルはそうではないからなぁ（むしろ凡庸なほうがいい）。
# 表現自体のユニークさが求められる世界もあるとは思うが。
0217デフォルトの名無しさん2005/06/20(月) 11:56:09
関数言語と広義の「設計パターン」の使用例２

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.
0218デフォルトの名無しさん2005/06/20(月) 12:14:46
>>182
> >>181
> 読めないよ。
> 全部訳してそれに対する自分のコメントふれって言ってるだろ。

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

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

> 誰でもわかる。
> 誰でもわかる。
> 誰でもわかる。
0219デフォルトの名無しさん2005/06/20(月) 12:38:51
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.
どこだよ。こうゆうの解らなくて英語は（もか？）かんべんです。

まるで私の無能をさらけ出してる様だ。
0220関数言語コミュニティではDPをIdiomと呼ぶ事が多いらしい2005/06/20(月) 12:48:08
関数言語コミュニティと関数言語デザインパターン
　　　　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
0221デフォルトの名無しさん2005/06/20(月) 13:05:27
>>219
　>>217は、あちこちの用語解説Wikiに載っている Lazy Evaluationの解説文。
あっちの国でも、他の辞書の解説をパクって使いまわすのね（笑

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

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

　最近のコンピュータ上での遅延評価の別の例としては、メモリーアローケーションにおける
　Copy-on-writeが挙げられる。(訳注: Mach, WinNTをはじめとするマイクロカーネルOSの機能)
0222デフォルトの名無しさん2005/06/20(月) 13:40:19
>>221
thx！

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

うあ、内容なくてｽﾏｿ
0223デフォルトの名無しさん2005/06/20(月) 14:02:23
やっぱりOCamlが最強なんだな。
0224デフォルトの名無しさん2005/06/20(月) 14:32:30
OCmalは良いが、OCamlを使う人間が腐ってる。
0225初期不良2005/06/20(月) 16:05:13
Lazy evaluation って late binding とか lazy binding と同義？
0226デフォルトの名無しさん2005/06/20(月) 16:22:31
Lazy evaluationは、ソバ屋の出前　(催促を受けてから提出物を作る)
Late bindingは、不動産屋の売り文句 (お客さんいい物件ありまっせ→客の好みを理解してから押し込める物件を探す)
0227デフォルトの名無しさん2005/06/20(月) 17:14:28
結局オブジェクト指向よりも関数型の方がいいということか
0228デフォルトの名無しさん2005/06/20(月) 18:26:01
>>227
なんでそうなる。
「ソバ屋の方が良心的」って話だ。
0229デフォルトの名無しさん2005/06/20(月) 18:46:54
>>226
前にTIPSとしてLazy instantiationというのを習ったんだけど
その時の説明もソバ屋の出前だった。
Lazy instantiationとLazy evaluationは同じものと考えても
よいの？それとも違うものと考えるべき？
0230デフォルトの名無しさん2005/06/20(月) 20:21:32
OCaml厨には、人格障害人間が多いという事だけは、はっきりとわかった。
0231デフォルトの名無しさん2005/06/20(月) 23:13:50
俺ならデザパタなんかなくてもMLでスマートに書いちゃうけどねｗ
0232デフォルトの名無しさん2005/06/21(火) 00:19:09
>>218
>>197は俺だけどそれ以降は俺じゃないんだが。
0233デフォルトの名無しさん2005/06/21(火) 00:32:21
つか、結局デザパタ使ってる奴はこういうので満足なの？
俺はオブジェクト指向を理解できていない状態でデザパタに逃げちゃうのは本当にもったいないと思うよ。
デザパタとオブジェクト指向はアプローチから全然違うものだからね。
オブジェクト指向言語の機能を使ってもオブジェクト指向は理解できないよ。

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

これができりゃどんなプログラムでも組めるって自信がつくぞ。
できるプログラマが人の１０倍〜２０倍の仕事ができるのはね。
俺はオブジェクト指向が理解できるかどうかといってもいいと思ってる。
デザパタじゃ所詮はパターンだ。
0234デフォルトの名無しさん2005/06/21(火) 00:46:41
------ ここが我慢のしどころです ------
0235デフォルトの名無しさん2005/06/21(火) 00:52:00
>>233
1億2億を超える大規模エンタープライズシステム開発で、スキルもまちまちな
有象無象のドカタ達を抱えるソフトハウス何社も使うプロジェクトを仕切ってから言ってみろよ。
オブジェクト指向だけじゃ限界があることを思い知るぞ。
0236デフォルトの名無しさん2005/06/21(火) 00:52:21
>>234
ｽﾏｿ。我慢できなかった。
0237デフォルトの名無しさん2005/06/21(火) 00:53:57
>>233 オブジェクト指向を理解してないとデザパタなんか理解できないぞ？
0238デフォルトの名無しさん2005/06/21(火) 00:57:51
↓以下放置でおながいします
0239デフォルトの名無しさん2005/06/21(火) 00:58:20
>>237
オブジェクト指向とデザパタはアプローチが全く異なる。
これは前から連呼している通りだ。
君はオブジェクト指向を理解できてはいない。
0240デフォルトの名無しさん2005/06/21(火) 00:58:57
とりあえず、批判するのは最低以下の２冊を読んでからにしようぜ。
そしたら >>233　のような頓珍漢な的外れの罵倒はなくなるはずだ。
"Design Patterns" Gamma, Helm, Johnson, Vissides, Addison-Wesley
"Modern C++ Design: Generic Programming and Design Patterns Applied", Andrei Alexandrescu, Addison-Wesley
0241デフォルトの名無しさん2005/06/21(火) 00:58:57
>>237
何度もいうがオブジェクト指向言語を使ってもオブジェクト指向は理解できない。
0242デフォルトの名無しさん2005/06/21(火) 00:59:36
>>240
その知識を使って俺を論破してみなよ。
その２冊でできるんだろう？
0243デフォルトの名無しさん2005/06/21(火) 01:00:06
アプローチが同じだったらデザパタが存在する意味がないじゃん。
オブジェクト指向を理解して、その限界もわかってるからデザパタがあるんだよ。
0244デフォルトの名無しさん2005/06/21(火) 01:02:45
>>243
全然ベクトルが違うし、オブジェクト指向が理解できていればデザパタは必要無い。
苦し紛れにいうのはかまわないが、自分がオブジェクト指向を理解することは不可能だと決め付けるのはよくない。

簡単に説明するが、
オブジェクト指向は対象物をそのままクラスに映すだけだ。
パターンは必要ない。
0245デフォルトの名無しさん2005/06/21(火) 01:04:31
オブジェクト指向は、いわゆるオブジェクトがファーストクラスオブジェクト
な計算のことだYO
0246デフォルトの名無しさん2005/06/21(火) 01:05:27
そのままクラスに写すアプローチはひとつとは限らんぜ。
それを共有するのがパターンなわけだが。
0247デフォルトの名無しさん2005/06/21(火) 01:05:42
>>242
じゃぁ論破するための論とやらを開陳しろよ。
0248デフォルトの名無しさん2005/06/21(火) 01:06:57
>>247
なんだそれ
0249デフォルトの名無しさん2005/06/21(火) 01:08:01
>>247
じゃあ、>>233で君が頓珍漢だといった内容で頼む。
0250デフォルトの名無しさん2005/06/21(火) 01:10:29
オブジェクト指向と一言で言っても設計の話なのかコーディングの話なのかでずいぶん変わると思うんだがどっちなんだ？
0251デフォルトの名無しさん2005/06/21(火) 01:11:33
おまえかあの書き込み？ >>233
それで言わせて貰うと、君は全くデザインパターンを知らないか、
まったく理解できていないかのどちらかだ。
議論以前の問題。上に挙げた２冊をよんだら >>233が恥ずかしくなるはず。
以上。
0252デフォルトの名無しさん2005/06/21(火) 01:13:05
たまには建設的な話し合いをしようぜ
0253デフォルトの名無しさん2005/06/21(火) 01:15:36
>>251
それじゃ話が違うじゃん。
ルール破ったのそっちだし、俺の不戦勝でいい？
0254デフォルトの名無しさん2005/06/21(火) 01:18:05
はい>>253の勝ち、終了。
0255デフォルトの名無しさん2005/06/21(火) 01:18:33
>>253
不戦勝でもなんでもいいから、もう来ないでよ。
0256デフォルトの名無しさん2005/06/21(火) 01:21:38
>>255
つーか、いつまでデザパタなんかにすがってるつもり？
もう、いい加減オブジェクト指向と向き合う覚悟を決めなよ。
0257前8372005/06/21(火) 01:23:22
>233
だからお前は誰だと

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

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

はウソだ、つうてるだけで。
0258デフォルトの名無しさん2005/06/21(火) 01:23:29
ざっと眺めただけだが「オブジェクト指向が理解できればデザパタは不要」以上の具体的な内容が全く出てないような気がする
0259デフォルトの名無しさん2005/06/21(火) 01:24:23
>>235
> 1億2億を超える大規模エンタープライズシステム開発

ぷっ。
￥１００，０００，０００　÷　￥１，０００，０００ [円/人月]　＝ １００人月　＝ ２０名×５ヶ月
0260デフォルトの名無しさん2005/06/21(火) 01:26:31
アプローチが違うと具体的にどんな不具合があるのかと聞いてみたいなぁ．
0261前8372005/06/21(火) 01:29:12
>256 だからお前は誰だと

それを言う前に“定石としてのデザインパターン”という考え方を論破してみろ。
0262デフォルトの名無しさん2005/06/21(火) 01:30:48
>>260 どうせ答えられないんだからきいても無駄だよ。
0263デフォルトの名無しさん2005/06/21(火) 01:31:38
>>258
１０倍〜２０倍の仕事ができるようになりまつ。
0264デフォルトの名無しさん2005/06/21(火) 01:31:53
20人を5カ月回して成果を出すの？デスマの予感……
5人x20カ月の方が良いなぁ
0265デフォルトの名無しさん2005/06/21(火) 01:32:26
>>260
設計が汚くなります。
0266デフォルトの名無しさん2005/06/21(火) 01:34:16
>>264
ここは業界常識が欠けたｲﾝﾀｰﾈｯﾄですね
0267デフォルトの名無しさん2005/06/21(火) 01:36:11
>>263
うさんくさい広告以下だなｗ
0268デフォルトの名無しさん2005/06/21(火) 01:37:27
>>265
実に主観的で解釈をめぐってもめる典型的な釣りじみた内容ですなぁ
0269デフォルトの名無しさん2005/06/21(火) 01:38:41
>>267
それが事実になるから強烈なんだよｗ
言語の設計理念に革命をもたらしただけのパワーはあるよ。
それは保障する。
0270デフォルトの名無しさん2005/06/21(火) 01:39:44
アプローチが異なると何で設計が汚くなるのかきいたらまずいだろうなぁ...
0271デフォルトの名無しさん2005/06/21(火) 01:40:36
>>269を見て思わず詐欺とか宗教の勧誘とかを想像したのは漏れだけですか？
0272デフォルトの名無しさん2005/06/21(火) 01:42:08
>>270
それはマズイかもね。逆切れされるかもよ。
0273デフォルトの名無しさん2005/06/21(火) 01:44:29
>>271
詐欺や勧誘のほうがもっと巧妙だと思われ
0274デフォルトの名無しさん2005/06/21(火) 01:52:36
それだ！なんか胡散臭いものを感じていたんだが、宗教臭いんだよ。
日本には信教の自由というものがあるから（藁）、気に入らなかったら
デザパタなんか信用しなくてもいいんだぜ。
0275デフォルトの名無しさん2005/06/21(火) 01:53:21
ま、基地外の戯言など聞くだけ無駄だしね。
0276デフォルトの名無しさん2005/06/21(火) 01:55:57
相変わらずアンチの論旨は具体性0だな
0277デフォルトの名無しさん2005/06/21(火) 01:57:57
具体的な話に踏み込むレスをｽﾙｰして勧誘(>>233 >>256 >>269)とは恐れ入る
0278デフォルトの名無しさんNGNG
よっしゃ俺が具体的な話に踏み込んでやるぜ。お前らひれ伏せろ。

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

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

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

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

※1 そんなものは STL 使えばいいじゃん、と言うかと思うが、
　STL もデザインパターンの1つだと思う。
0279デフォルトの名無しさんNGNG
上で述べたように共同開発を円滑にすることも重要だが
自分的には「言葉」と「知識」を繋げて定義してくれたことが
とてもとても大きな恩恵だと思う。

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

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

知識の再利用なんて昔からあったが、重要なのは「言葉」→「知識」の参照速度なんだよなぁ。
まさに情報社会の利点を存分に引き出すデザインパターンとその考案者に敬意を示すぜぇぇぇ！AGE!
0280デフォルトの名無しさんNGNG
>>278の(※1)はアレだ。リストの管理方法を示したかっただけだ。
キューとスタックじゃ機能的に意味が違ってくるが気にするな！晒しSAGE!
0281デフォルトの名無しさんNGNG
>>277への突っ込みは俺の勘違いですた。スマソ

あと「よっしゃ」まで読んだ、とかいうレスはやめてね。落ち込むから。
0282デフォルトの名無しさん2005/06/21(火) 03:26:42
お兄ちゃん、今日は駄目

まで読んだ
0283デフォルトの名無しさん2005/06/21(火) 04:19:13
「パターンはオブジェクト指向じゃないからダメ」ってなんだよその論理？
オブジェクト指向でやった結果、ある程度Genericに纏められる部品がでてくるってだけの話じゃん。
どうオブジェクト指向じゃないのか根拠もなしにダメってそりゃダメダメだな。
STLだってパターンの部分集合。Genericな構造でしかもオーバーヘッドがないなら使わない理由がない。
あんたの作る独りよがりな汚いtemplate classを読まされるくらいなら、Genericな物を使ってくれた方が同僚はありがたい。
いいから"Modern C++ Design"を読んで理解してから落ち着いて書き込め。
0284デフォルトの名無しさんNGNG
パターンを否定する人はたぶん職人気質なんだろうなぁ。
何もかも自分で考え自分で作り出さなきゃ気がすまない、という具合の。
意気込みを否定する気はないが、
その限界を知っておかないと周りに迷惑をかけることになるぜ。

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

>>282
ﾊｧﾊｧ
0285デフォルトの名無しさん2005/06/21(火) 05:10:19
>>284
そういう人は、例えばデータ圧縮ならハフマン符号化からJPEGまで楽勝で発明できるんだろうか？
他人の技術を使わないでランレングスしか思いつかなかったら、その人の圧縮率の限界はランレングスなわけだなｗ
確かに独自に発明しようというクラフツマンシップは大切だけれども、先人が既に解法を見つけているものを再発明しても、
それは個人の自己満足レベルの話でしかないわな。大学の研究者なら有り得ない愚かさだ。
先人の知恵を一生懸命学んで模倣して、こっから先は人跡未踏という位置で戦うのが普通。
0286デフォルトの名無しさん2005/06/21(火) 06:02:35
>>233は、ヘボライターということで終了ですか。
0287デフォルトの名無しさん2005/06/21(火) 06:53:31
>>285
それって設計の話か？
0288デフォルトの名無しさん2005/06/21(火) 07:28:02
バカが自分でも理解できるからもてはやしているだけのインチキ技術が
デザパタｗ
0289デフォルトの名無しさんNGNG
>>287
285ではないが、ものを学ぶ姿勢のあるべき姿の話だろう。
これは精神論ではなく実益を生むぜー。

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

とまとめてみるテスト。
0290デフォルトの名無しさん2005/06/21(火) 07:50:38
>>289
何寝ぼけたこといってんの？
>>285の内容は全然設計と関係ない話じゃない。
どうしてここで圧縮技術の話なんか出てくるのか馬鹿の考えることはさっぱり理解できない。

だいたい、先人の知恵をきちんといかすなら基本となるオブジェクト指向をもっとしっかり理解すべきだ。
それをやらずにデザパタに逃げてるだけの人間なんて誰も評価しない。
0291デフォルトの名無しさん2005/06/21(火) 07:54:52
>>285
だいたい大学の研究者ってプログラム組むのうまいかのー。
極めてハイレベルなところが世の中にあるのかもわからんが、大抵は・・・なレベルだよｗ
そもそも数年前に研究内容があまりにも幼稚で企業に見切り付けられたところがほとんどなのになｗ
昔は企業と大学がそんなこんなでリンクしてた神話（笑）の時代があったかもしれんが、
実態が浮き彫りになってからはそれもないのーｗ
教授の顔パスで就職なんて景気のいい話は最近めっきり聞かないなｗ
0292デフォルトの名無しさん2005/06/21(火) 08:03:47
デザインパターンを使う者がオブジェクト指向を理解していないと言い切るところがすごいな。
アンチはデザインパターンを否定しているがデザインパターン肯定派はオブジェクト指向を否定していないところに気づけ。
大規模プロジェクトではパターン化しないと立ち行かないことも知れ。

0293デフォルトの名無しさん2005/06/21(火) 08:05:34
>>292
何言ってるのかわかんないけど、オブジェクト指向は覚えた方がいいよ。
0294デフォルトの名無しさん2005/06/21(火) 08:07:47
>>292
俺も何言ってるのかわからないけど、こんな実装よりのパターンが
大規模プロジェクトなんかで役に立つわけが無い。
0295デフォルトの名無しさん2005/06/21(火) 08:10:17
まあ、結城先生の「ギコ猫とデザインパターン」を読んで
笑える様になる事を目指すのが最初かな。
あれは、デザパタを知ってる人じゃないと、その面白さに
気付かないシロモノだからね。
0296デフォルトの名無しさん2005/06/21(火) 09:13:20
>>295
アンチにはとうてい理解できないだろうね
0297デフォルトの名無しさん2005/06/21(火) 10:28:13
>>295
てか、デザインパターンって日本語で言えば定石でしょ。
カタカナ語が多いから少し高尚な感じがするけど、
それに惑されて勘違いしてる人多いんだよね。
言ってる事は常識的な話で、とりたてて騒ぐもんじゃない。
0298デフォルトの名無しさん2005/06/21(火) 10:34:05
>>297
それがわかってないから、
騒ぐ奴がいるんだ
0299デフォルトの名無しさん2005/06/21(火) 10:51:21
>>293-294 脳内で実装不可能な設計でもやってなさい
0300デフォルトの名無しさん2005/06/21(火) 10:54:49
レベル低いのが毎日粘着してるな。
２ちゃんだからしょうがないけど、本当にくだらねぇ
0301デフォルトの名無しさん2005/06/21(火) 10:59:11
>>293-294
脳内なら、好きなように設計できるぞ。デザインパターンなんてものはない。
あるのはオマエの敬愛してやまないオブジェクト指向のみだ。やったな！
0302デフォルトの名無しさん2005/06/21(火) 12:15:54


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

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

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


これを読み終えたら、もう二度とスレを荒らすのをやめろ。
0303デフォルトの名無しさん2005/06/21(火) 12:18:19
2ちゃんで人生とは・・。
0304デフォルトの名無しさん2005/06/21(火) 12:19:07
腐った魂の臭いがする
0305デフォルトの名無しさんNGNG
>>302
誰に言ってるんだ？
0306デフォルトの名無しさん2005/06/21(火) 12:20:53
おまえ
0307デフォルトの名無しさん2005/06/21(火) 12:22:57
アンチってゲームプログラマーに多いかもしれない。
ゲームはモデリングに関しては、あんまり悩む余地はないからね。
#表面的にはね。本当は工夫のしようはいくらでもあるんだけど...

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

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

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

こんなのは可愛いほうで、ここには書けないようなヒドイこともたくさんあった。
彼らのプロジェクトにデザインパターンなんか導入したら、発狂もんだろうな...
「構造体に関数がくっついたのがオブジェクト指向。それ以上でもそれ以下でもない。」
みたいなことを涼しい顔してのたまうオジサンもいたし。orz
0308デフォルトの名無しさん2005/06/21(火) 12:23:50
デフォルトNGワード：ア　ン　チ
0309デフォルトの名無しさん2005/06/21(火) 12:24:56
こんな下らない話タラタラ書くのは、どっかの同人作家崩れのデブヲタなんだろうな
0310デフォルトの名無しさんNGNG
>>307
学習の敷居に発狂、成果の大きさに発狂、どっちだｗ

＞それ以上でもそれ以下でもない
この表現好んで使う奴いるよな。かっこいいこと言った気分になるらしい。
0311デフォルトの名無しさんNGNG
しかしム板にはID表示されないんだな。
お笑い板とかならむしろ表示しないほうが逆におもろいけど
議論が必要なこういう場ではID必要だろう。いろんな意味で。
0312デフォルトの名無しさん2005/06/21(火) 12:33:20
>>181の訳

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

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

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

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

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

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

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

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

(訳注2: 本文後半、数学概念の説明に関して、後続レスで議論あり)
0313デフォルトの名無しさん2005/06/21(火) 12:36:47
再利用技術を否定するアンチ君はきっと、
受注したシステムの著作権ごと売り渡してしまい
毎回1から作り直してる零細ソフトハウスにお勤めなんだろう。
0314Ocamlとデザインパターン2005/06/21(火) 12:36:51
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

以下、未

[構造に関するパターン]
　　　　未
0315デフォルトの名無しさん2005/06/21(火) 12:42:20
結論1： オブジェクト指向拡張のなされた関数言語 (OCaml)とデザインパターンは両立しうる　(>>314)
結論2： 関数言語の世界でも、熟練したプログラマーが使うノウハウは
　　　　　イディオム、デザインパターン、プログラミングスタイルなどと呼ばれる形で蓄積されている。
　　　　　例えば純関数型言語Haskellを特徴づける Monadicプログラミングも、その一例である。
結論3： デザイン・パターンを「設計上よくあらわれるパターン」という一般概念として考える場合、
　　　　　それは全てのプログラム開発で発生する事象である。
　　　　　デザイン・パターンなど必要ないという人物は、単にプログラミングをした事がないだけである。
03163072005/06/21(火) 12:46:28
>>310 成果の大きさに発狂だといいんだけどね...

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

プロジェクトが終わり、彼が充実感を得たのは理解できたんだけど、
その他の烏合の衆までが充実感を（錯覚して）感じているのに正直ムカついた。
0317デフォルトの名無しさん2005/06/21(火) 12:50:52
アンチはサーバサイドアプリケーションを作ったこと無いに一票。
0318デフォルトの名無しさん2005/06/21(火) 12:54:21
>>312補足

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

また、中島秀之先生(現在はこだて未来大学長)のProlog/KR本に載っている「多重世界機構」
(アイデアの源泉はたぶんミンスキーの「フレーム理論」)も、
Monadicプログラミング・パターンの実例なんだ。
0319デフォルトの名無しさんNGNG
あのさ、俺今気づいたんだけどさ、っていうか今更気づく俺が馬鹿なんだけどさ、
みんな分かってると思うんだけどさ、

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

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

今の現状じゃぁデザインパターンの議論にすらたどり着いてないじゃん。
こんな低クオリティ見てらんない。
Ｃ言語のスレで「本当にＣ言語は必要か」なんて議論、普通しないだろ？
0320デフォルトの名無しさん2005/06/21(火) 12:57:26
>>307,>>310,>>316
デザパタ関係ねぇじゃん。スレ違いうざい。
愚痴はプログラマー板に書け
0321またデブヲタ同人作家のオナニーか2005/06/21(火) 12:58:25
NGワード：発狂
0322デフォルトの名無しさんNGNG
>>316
彼が感じたのは充実感でなく開放感である気がします。気がするだけです。

ド素人でもゴリ押しで動くものが作れてしまうところがプログラムの怖いところ。
それで妙な自信を持たれても困るんだよぅ。
彼らの自信を打ち砕くには、涙が出るほどに素晴らしいソースコードを見せる以外にない
と思うが、たぶん見てくれないだろうなぁ。必要ない、って言って。
0323デフォルトの名無しさん2005/06/21(火) 13:04:34
>>319
粘着してるアンチに言ってくれ
0324デフォルトの名無しさんNGNG
>>320
スマソ。

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

というまとめで許してくらさい。短絡的とか言わないで。
03253162005/06/21(火) 13:07:55
>>322 ああ...そうかもしれない。orz
私自身も達成感より開放感のほうが勝っていたなぁ。
0326デフォルトの名無しさん2005/06/21(火) 13:16:41
スレ違い。さっさと出て毛
0327デフォルトの名無しさんNGNG
>>326
君は肯定派？否定派？
0328デフォルトの名無しさん2005/06/21(火) 13:23:00
>>307,>>310,>>313,>>316-317,>>322-325

スレ違いの話題でスレを荒らすな。
さっさと出てけ
0329デフォルトの名無しさん2005/06/21(火) 13:24:11
否定派が図星を指されて荒れているような。
0330デフォルトの名無しさん2005/06/21(火) 13:25:28
>>323
おまい煽るのやめれ。

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

>>319の言うとおり、デザパタ否定してる奴は専用スレでも建ててやってくれ。
このスレでデザパタは必要かどうか言及するのはスレ違い。
0331デフォルトの名無しさん2005/06/21(火) 13:56:49
>>330
> >>319の言うとおり、デザパタ否定してる奴は専用スレでも建ててやってくれ。
> このスレでデザパタは必要かどうか言及するのはスレ違い。

デザインパターンが、所謂定石だとしたら、使われている用語が不味いと
思うぞ。なぜにあないな、カタカナ語なんだろう？もっと普通に書ける
と思う。
0332初期不良2005/06/21(火) 13:59:14
>>319
なんかもう音楽理論とかデッサンとかと全く同じ流れやね...
理論なんて必要ねえよセンスさえあれば。
ってそういう議論は別スレに隔離ってのが定説。
0333デフォルトの名無しさんNGNG
>>331
そんなにカタカナ語ばかりか？

まぁ下手に和訳されると
海外の人とデザインパターンを共有したいときに、
元の英語を覚え直さなきゃならん手間が出るから
むしろカタカナのままのほうがいいとも思うが。用語とか固有名詞とかはね。
0334デフォルトの名無しさん2005/06/21(火) 14:30:50
>>331
日本で作られたモノではないのだから仕方ないだろう。
0335デフォルトの名無しさん2005/06/21(火) 14:31:40
和訳は紛糾するだろなぁ
0336デフォルトの名無しさんNGNG
というかプログラムを書くのにサポートされている文字が
アルファベットのみであることが多いから、
海外の人と〜とか言う以前に、やっぱり用語はカタカナ（英語）のほうが
プログラムに書きやすいと思う。
0337デフォルトの名無しさんNGNG
336は333の続きね。
0338デフォルトの名無しさん2005/06/21(火) 14:35:36
イディオムとかアルゴリズムとかだってカタカナ語だが、そんなにカタカナって不味いのかね？
わけわからん
0339デフォルトの名無しさん2005/06/21(火) 14:38:57
デザインやパターンやオブジェクトやパラダイムやメソッドやクラスや・・・
0340デフォルトの名無しさん2005/06/21(火) 14:51:17
カタカナがどうこう以前に、
外国人と一緒に仕事するときは英語を使わざるをえない。
# 英語苦手なのに・・・大変だよぉ
0341デフォルトの名無しさん2005/06/21(火) 14:59:54
(´･ω･｀)話がそれとるがな

訳といえば、PoEAA日本語訳の変なのをどなたか何とかして下さい。
データ”変換”オブジェクトとか”軽（重）”オフラインロックとか…
0342デフォルトの名無しさん2005/06/21(火) 15:09:55
ゆるロック
0343デフォルトの名無しさんNGNG
ヒドいよね…。パターンの恩恵を半分失ってるに等しいと思う。
名前を訳してしまうこと自体犯罪に等しいのに、ましてやあのセンスはなんだよ。無期懲役モノだよ。
レビュー見ただけで買う気が萎えたんで読んでないけど。

がんばって英語版読むさ…。
0344デフォルトの名無しさん2005/06/21(火) 15:46:04
日本語文献では一般的になっている言葉だが、
悲観的ロック・楽観的ロックという用語にも違和感を感じる。

Sunのドキュメントの
配備（デプロイ）
配備解除（アンデプロイ）
配備記述子（デプロイメントディスクリプタ）
要求（リクエスト）
応答（レスポンス）
本体（ボディ）
持続性（Persistence）
にも違和感を感じるよ。
「要求の本体」って何かと思ったら「(HTTP)リクエストのボディ」だもんな。
0345デフォルトの名無しさん2005/06/21(火) 16:57:12
>>334
そは訳したとはいえない。カタカナ語も一緒。
デザインパターンやってる人から、こんなに
ベタな反発くらうとは思わなかった。
0346デフォルトの名無しさん2005/06/21(火) 17:28:10
>>345
別に「うまく訳す」ことはないんでない？
カタカナ文字で大げさと感じたならそれはしょうがないけど。
まあ、とにかくデザパタ本の日本語訳が良いか悪いかはスレ違いかと。
03473462005/06/21(火) 17:31:10
というか、最終的に日本語に置き換えてもあまり使われない希ガス。
特にオブジェクト指向用語など。たとえば「多態性」とか。
解説サイトではみんなポリモーフィズムだかポリモルフィズムだかで呼ぶし。
0348デフォルトの名無しさん2005/06/21(火) 17:59:01
すっごい亀なんだけど、意見させてくれ

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

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

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

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


おまけ: 「俺は Tree パターンを使ったわけじゃない。木構造を表現したら、たまたまソックリになっただけだ」
0349デフォルトの名無しさん2005/06/21(火) 18:22:00
デザインパターンはプログラミングテクニックの様に自己内で完結するものじゃなくて
不特定多数の人間の間で「特定の手法」(設計)を明示化する事によって
設計全体を理解しやすくする為のものじゃないの？

>>348 の言うように、ある実装の形が
偶然「特定の手法」と一致したとしても、
明示化しなければデザインパターンの理想には叶っていないのでは？
0350デフォルトの名無しさん2005/06/21(火) 18:27:13
「C++プログラミングの筋と定石」と「GoF本」を読み比べてみることをお勧めする。
0351デフォルトの名無しさん2005/06/21(火) 18:30:56
分かりました。読み比べてみます。
03523482005/06/21(火) 18:32:33
>>349
＞不特定多数の人間の間で「特定の手法」(設計)を明示化する事によって

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


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

もちろん。だから 「あ、ココは前に使った ○○ を使おう」 って発言が出せる筈。
0353デフォルトの名無しさん2005/06/21(火) 18:38:10
新しいパターンやパターン言語の将来を語るのではなく、
デザインパターンの定義をぐちぐちやってるあたりが悲惨だな。
最近とんと名前聞かないけど、JPLoPもこんな感じなのかな。
0354デフォルトの名無しさん2005/06/21(火) 19:10:51
http://pc8.2ch.net/test/read.cgi/tech/1119348596/

隔離スレ作ったから、今後はスレ違いの荒らしはスルーしろよな。
0355デフォルトの名無しさん2005/06/21(火) 19:33:46
>>354
ナイス
ようやく普通の話が出来るな
0356デフォルトの名無しさん2005/06/21(火) 19:47:12
>>354
神。
冷静に考えると、何故今まで隔離スレがなかったのか謎。
0357デフォルトの名無しさん2005/06/21(火) 20:30:32
>>354-356
ナイスつーか正直、対処がガキっぽい。
彼が本当にデザパタの存在意義を言及したいなら自分で作るっしょ。

>>350
分かりました。読み比べてみます。
0358デフォルトの名無しさん2005/06/21(火) 20:34:59
あのさ、悪いんだけど「デザインパターン」とは「定石」か否か？
つう議論も引越してもらえないかな。
それ、デザインパターンがわかってない人が重箱の隅突っついてるだけの
肝っ玉ちっさい議論なんだけど
0359デフォルトの名無しさん2005/06/21(火) 21:26:21
>>357
>ナイスつーか正直、対処がガキっぽい。

どうしろっていうんだよ・・・
0360デフォルトの名無しさん2005/06/21(火) 21:38:37
私は２つに分かれて議論したほうが良いと思っていたので、今回の措置は歓迎です。
ってこの話題ももうやめましょうね。
03613572005/06/21(火) 22:11:27
>>359
すまん。うまく隔離できてるっぽいね。
ああいう奴だとスレ作っても移動してくれないかと思ったので言ってみた。
ってことで、この話題はもうやめよう
0362デフォルトの名無しさん2005/06/21(火) 22:55:11
デザパタ否定厨にお願い。
クライアントアプリやスタンドアロンアプリじゃなくて
デザインパターンを使わないWebアプリケーションの設計の具体例希望。
悪いけど、超初心者が書いたスパゲッティコードのようなものしか想像できない。
あんたの言う、「オブジェクト指向で設計すればデザパタ不要」が全くイメージできない。
フォーマットはUMLでいいよ。
0363デフォルトの名無しさんNGNG
>>362
http://pc8.2ch.net/test/read.cgi/tech/1119348596/
こちらへどぞー
03642852005/06/22(水) 00:13:27
>>289
＞何寝ぼけたこといってんの？
＞>>285の内容は全然設計と関係ない話じゃない。

「先人が発明したパターンを学び、設計上で再発明をしない」っていう話のどこが設計と関係ないんだよ。
抽象レベルで話しても理解できないアンチパターンバカのために、圧縮技術を具体例に挙げたんだろうが。
メタファーとか比喩とか全く通じないやつってほんと知能が低いと思う。>>289
だから、抽象の抽象って理解できないんだろうなぁ。ある意味高度な知的活動だから。
たぶんポインタのポインタも理解できないから、アンチC/C++言語でもあるｗ
0365デフォルトの名無しさん2005/06/22(水) 00:21:06
>>364
http://pc8.2ch.net/test/read.cgi/tech/1119348596/
こちらへどぞー
0366前スレ9462005/06/22(水) 00:27:28
だから最初から分ければいいといっておいたのに。
お前らときたら。。。
0367デフォルトの名無しさん2005/06/22(水) 00:40:53
だからそーゆー不毛な発言は慎めって。
あなたがそう思ったなら、あなたが実行してもよかったはずだ。
0368デフォルトの名無しさん2005/06/22(水) 00:41:43
あーあ、隔離しちゃったらDAT落ちしちゃうのに。
0369デフォルトの名無しさん2005/06/22(水) 00:43:22
>>368
http://pc8.2ch.net/test/read.cgi/tech/1119348596/
こちらへどぞー
0370デフォルトの名無しさん2005/06/22(水) 00:45:38

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

みたいなパターンってありますか？
0371デフォルトの名無しさん2005/06/22(水) 00:53:29
これから、命名するところです
0372デフォルトの名無しさん2005/06/22(水) 01:17:36
俺ならMLでスマートに書くんだけどね。
0373デフォルトの名無しさん2005/06/22(水) 01:25:26
>>372
　>>312-315
0374デフォルトの名無しさん2005/06/22(水) 02:42:46
>>353
そうなっちゃう原因が、プログラミングを良く知らない人間が、
翻訳してるのか、日本語を知らない人間が翻訳してるのか？
どっちか分かりかねるが、言葉の問題だと思うんですよね。

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


0375デフォルトの名無しさん2005/06/22(水) 02:49:40
例えば、Widgetって何だよ？
ってところで詰まってたりする。
0376デフォルトの名無しさん2005/06/22(水) 03:02:57
>>375
そうですね、例えばCOBOLで業務系アプリ作ってる人にとっては、
Widgetと言われても困るわけです。

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

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

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

デザインパターンは新人ちょっと過ぎが、迷わないための仕組みなんですから。
0377デフォルトの名無しさん2005/06/22(水) 03:11:30
>>376
すばらしい分析です。特に訳書批判部分。
で、Widgetって何？
0378デフォルトの名無しさん2005/06/22(水) 03:23:09
>>377
揚げ足鳥パターンですね。
0379デフォルトの名無しさん2005/06/22(水) 03:28:48
>>378
あ、ひょっとしてあなたもwidgetで困っている？
0380デフォルトの名無しさん2005/06/22(水) 03:31:00
辞書に載ってないのでググッてみました。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.
だそうです。
0381デフォルトの名無しさん2005/06/22(水) 03:52:38
難しく考えないでも、Windowsで言うコモンコントロールをイメージすればいんでない
0382デフォルトの名無しさん2005/06/22(水) 03:57:51
>>381
ぶっちゃけそれで良いとは思うけど、デザインパターンの本だとか
に出て来るWidgetsクラスてのは、Windowsで言うコントロール程
多機能化されてないので、このX11WidgetsをWindowsのコントロール
並にするてな話の中でデザインパターンを説明してたり。

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

デザインパターンを混乱に陥れてると思う。
0383デフォルトの名無しさん2005/06/22(水) 04:15:50
Widgets：（名前が分からない［思い出せない］）何とかいう部品

つまりな、「えーと、アレ、アレ」だよ。
0384デフォルトの名無しさん2005/06/22(水) 08:16:59
>>370
A，B のモデルとして適切かどうかわからないが，
A の中の取り出したい特定要素を a というオブジェクトでもつ様にして，
a を prototype にして a' を作って B に渡したらいいんじゃない？
0385デフォルトの名無しさん2005/06/22(水) 09:23:09
>>370
ObjectA a = new ObjectA();
ObjectB b = (ObjectB)Factory.newInstance(a);
オブジェクトＡからＢを生成しちゃってるけど、こういう事ではなくて？
0386デフォルトの名無しさん2005/06/22(水) 09:37:31
>>370は、下記の定義をちゃんと説明しないと、他の人が回答しようがない。なんなら英語で書いてみて。

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

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

・・・まぁ俺もPrototypeかFactoryを連想するわけだが
0387デフォルトの名無しさん2005/06/22(水) 10:04:36
>>358
掘り返してすまんのだけど、デザパタって定石みたいなものでない？
どうわかっていないのか聞きたい。

今後、新規に人が来て「デザパタは設計だろ？」とか聞いてきた時に、
また、「いや違う、定石だろ」だの、なんだのの話でループしてしまうと思うから、
その時にみんなが納得できるレスを返せるよう、この辺は明確にしておきたいんだけど。
0388デフォルトの名無しさん2005/06/22(水) 12:32:32
その話は隔離スレでどぞー
0389デフォルトの名無しさん2005/06/22(水) 12:46:50
>>388
隔離スレへ誘導するほど知識ない奴が書き込むんじゃない。
0390デフォルトの名無しさん2005/06/22(水) 13:37:15
まぁまぁ...おちついて。

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

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

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

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

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

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

#この話もこれで終わりにしましょう。
0391デフォルトの名無しさん2005/06/22(水) 14:00:04
>>390
「デザインパターン」を「フレームワーク」に置き換えたほうがしっくりくるな。
03923902005/06/22(水) 14:05:24
>>391
あー...その...
1つのたとえ話としておいてください。
# 終われない。
0393デフォルトの名無しさん2005/06/22(水) 14:05:51
>>391
禿同意。
この話もこれで終にしましょう、とか偉そうに言うくせに頓珍漢なんだよなー。
0394デフォルトの名無しさん2005/06/22(水) 14:07:22
>>392
そんなレスつけるとこみると、本気で勘違いしてる。
とおもう。
03953902005/06/22(水) 14:13:08
デザインパターン≒骨格という例えは、よくありませんでしたね。
一つのアプリケーションに何個も骨格があることになってしまいますから...
視点が局所的になってました。
0396デフォルトの名無しさん2005/06/22(水) 14:35:25
>>390
たとえ話はあんまり得意じゃないんだけど、あえて言うなら骨か？

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

デザインパターンをあえて言い換える必要はないとするのは同意。
0397デフォルトの名無しさん2005/06/22(水) 14:46:14
>>395-396
デザインパターンそのものが、建築でいう江戸間関西間2X4を
ソフトの世界で使うように造語したもんだから、言い換え可能だよ。

高尚でも何でもないのに、高尚ぶりたがる奴が多くて、せっかくの
概念がだいなしだと思う。
0398デフォルトの名無しさん2005/06/22(水) 15:01:19
>>397 それって言葉のせいかな？
例えば「定石」と言い換えたって高尚ぶりたい人は、そうするよ、きっと。
それに「デザインパターンを「○○みたいな物」って言い切っちゃうと、
その「○○みたいな物」から誤解が生じる可能性もあるしさ。

ってホントにやめないか？
0399デフォルトの名無しさん2005/06/22(水) 15:08:03
>>398
はぁ(ため息)

やめるのは、君の方だってことが分らないのか？
0400デフォルトの名無しさん2005/06/22(水) 15:50:07
俺ならMLで簡潔に書くんだけどね。
0401デフォルトの名無しさん2005/06/22(水) 15:52:40
>>387-400
平日昼間から白熱した議論を展開している方が約一名居られるようですので、
新ｽﾚを立てました。
あちらで思う存分議論をして下さい。

〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119423033/l50
0402デフォルトの名無しさんNGNG
デザインパターン⊃フレームワーク
だと思うが。
いちいち噛み付くなよ。
話が逸れるにしても、もうちょっと紳士的な議論はできないのか。
0403デフォルトの名無しさんNGNG
>>401
ｺﾞﾒｿ
0404デフォルトの名無しさん2005/06/22(水) 16:02:39
分離スレ

〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119423033/l50
こちらでどぞー
0405デフォルトの名無しさん2005/06/22(水) 16:13:18
俺ならMLでスマートに書くからデザパタなんか必要ないんだけどね
0406デフォルトの名無しさん2005/06/22(水) 16:18:18
>>405
　>>312-315

〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119423033/l50
続きはこちらでどぞー
0407デフォルトの名無しさん2005/06/22(水) 17:46:15
どんどん増えてゆく隔離スレ
0408デフォルトの名無しさん2005/06/22(水) 18:06:57
ひろゆきの２ちゃん支配は、分割統治が原則だからな
0409デフォルトの名無しさん2005/06/22(水) 18:22:17
スレ立て厨は、この間からの議論厨よりタチが悪いな
0410デフォルトの名無しさん2005/06/22(水) 18:22:29
まさにデザインパターンだな
0411デフォルトの名無しさん2005/06/22(水) 18:55:54
>>409
ご謙遜ですか・・・
0412デフォルトの名無しさん2005/06/22(水) 21:08:40
デザパタスレの中心で脱構築
0413デフォルトの名無しさん2005/06/22(水) 23:11:36
>>386
>>370です。今帰宅しました。

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

Prototype、Factoryについて調べてみます。
ありがとうございました。
0414デフォルトの名無しさん2005/06/22(水) 23:12:08
>>412
よーし、パパ記念に隔離スレたてちゃうぞー
〔隔離〕デザパタスレの中心で脱構築〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1061947883/l50
続きはこちらでどぞー



つくってねーよｗｗｗｗｗ
0415デフォルトの名無しさん2005/06/22(水) 23:16:54
>>413
乙かれちゃん。
1(2) ValueObjectとかDTO (DataTransferObject)じゃないかなぁ。
0416デフォルトの名無しさん2005/06/22(水) 23:36:24
>>413
オブジェクトＡ→状態オブジェクト
この流れは生成に関するパターンから拾える可能性が高い。

状態オブジェクトをオブジェクトＢに適応する部分は両者の
関係がもう少し詳しく分からないと何とも言えない。
両者は＝なのか⊆なのか⊂なのか、そしてオブジェクトＢ
は固定なのか変動の余地があるのか？
0417デフォルトの名無しさん2005/06/22(水) 23:42:53
「状態オブジェクト」というあまりポピュラーではない単語の定義はなんですか？
0418デフォルトの名無しさん2005/06/22(水) 23:45:40
このスレの主旨でいけば、Stateパターンのはずなんだけど、
一連やり取りの文脈上は、オブジェクトの状態の一部のスナップショット、強いて挙げるとMementoパターン？
0419デフォルトの名無しさん2005/06/22(水) 23:46:58
>>417
特に深い意味はない。
「コピーに必要な情報を保持しておくオブジェクト」という意味で使っただけ。
0420デフォルトの名無しさん2005/06/22(水) 23:49:33
>>418
いや、そういう意図は全然なかった。
一応、パターンを表す時にはローマ字表記で統一してたんだけど
事前に説明がないと伝わらん罠orz
0421デフォルトの名無しさん2005/06/22(水) 23:52:01
ぐぐってみると、
SunがJavaのjava.util.EventObjectをイベント状態オブジェクトと称していたり、
M$ ASPのHttpWebRequest/HttpWebResponse(wを「状態オブジェクト」と呼ぶ人が居たり、
M$ ASPのセッションオブジェクトを「セッション状態オブジェクト」と呼ぶ会社があったり（ｗ、
いろいろヤバイ表現が転がってるな。
・・・もしかしてMonadic プログラミングとか意識してる？（ｗ
0422デフォルトの名無しさん2005/06/23(木) 11:27:49
>>421
そこに上がっている例のうち、EventObject, HttpWebRequest　は、
「要求のカプセル化」という観点に着目すると、一種のCommandパターンだな。
ただし後者は「要求」といっても「HTTPプロトコル」レベルで抽象度低いから、
Commandとは言いくいような気がするが。
0423デフォルトの名無しさん2005/06/23(木) 17:02:32
>>418
オブジェクトを再現するのに必要なデータを保持ってことなら
Mementoだろうね。
0424デフォルトの名無しさん2005/06/23(木) 22:45:11
俺ならデザパタもML風に定式化するんだけどね。
0425デフォルトの名無しさん2005/06/23(木) 22:54:10
で、>>424以外誰も読まない
0426かわいそうな人だねえ2005/06/23(木) 23:12:19
>>424
　>>312-315
0427デフォルトの名無しさん2005/07/03(日) 18:51:04
プログラム板が荒れているため、IDを導入するか検討中です。
賛成の方も反対の方も、このスレで自分は賛成か反対かをお書きください。

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

理由などの記入は別に構いません。
<<賛成>>か<<反対>>かだけ御記入頂ければ結構です。
ちなみに、当たり前ですが運営の方にIPが見えているので、1日ごとにIDが変わるからといって多重投稿しないでください。
0428デフォルトの名無しさん2005/07/04(月) 01:33:40
デザインパターンを参考に、ウィンドウシステムのフレームワークを作ってみました。

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

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

一応、Strategy的にイベントをフックできるようにしてるので
継承しなくても多くのことはできるのですが、
メソッドのオーバーライドをしたいときは、やはり継承したほうがいいように感じます。
0429デフォルトの名無しさん2005/07/04(月) 01:59:53
相変わらず意味不明なことを言ってるな。特にこのあたり。
　＞一応、Strategy的にイベントをフックできるようにしてるので
　＞継承しなくても多くのことはできるのですが、
　＞メソッドのオーバーライドをしたいときは、やはり継承したほうがいいように感じます

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

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

0430デフォルトの名無しさん2005/07/04(月) 02:00:29
解答１
　もし、抽象クラスButtonのインタフェース(method)だけで
　Win32版、X版の機能拡張を実装できるのならば、
　(例: ボタン外観のカスタマイズという拡張を行うとして、
　　　　外観のカスタマイズに必要なインタフェース(method)が
　　　　全てButtonクラスに揃っている、等)
　単にWin32ButtonとXButtonを拡張し、
　その拡張したクラスをFactoryが生成してやれば良い(はず。Liskov置換則あたりかな)
　
　　　　　　　Button　　　　　　　　　　　　WindowFactory
　　　　　　　　 △　　　　　　　　　　　　　　　：createButton()　　
　　　　　　　　 │　　　　　　　　　　　　　　　：
　　　　　　　　 │　　　　　　　　　　　　　　　：　WindowFactoryExt
　　　　┌──┴──┐　　　　　　　　 　 .：　　　　　：createButton()
　　Win32Button　　XButton←…………･　　　　　：
　　　　△　　　↑　　 △　　　　　　create　：　　　　 .：
　　　　│　　　　……│ …………………･　　　　 .：
　　　　│　　　　　　　│　　　　　　　　　　　　　　　　 .：
　　　　│　　　　　　　│　　　　　　　　　　　　　　　　 .：
Win32ButtonExt　　XButtonExt ←………………･
　　　　　　　　 ↑　　　　　　　　　　　　　　　　　　　　　：
　　　　　　　　　 ……………………………………･
04314282005/07/04(月) 02:20:07
アプリ側では
Win32Button を継承したクラスと XButton を継承したクラスの両方を
作って、WindowFactory の子クラスで生成を振り分けるってことでしょうか。

目的のボタンの実装では Button のインターフェースしか使用せず、
Win32ButtonExt と XButtonExt の実装が、継承元以外はまったく同じに
なってしまい、無駄が出る気がするのですが、これは仕方ありませんか？
0432デフォルトの名無しさん2005/07/04(月) 02:36:38
質問が更に空理空論っぽくなってきたな。>>431に解答する前に。
-----------------------------------------------------------------
解答1への注
　要するに解答１は、基底クラスButtonを拡張する事なしに、
　サブクラスの拡張が可能であれば良い。
　(例)では、基底クラスButtonのインタフェースを使って拡張を行うと仮定したが、
　基底クラスのインタフェースでは不可能な拡張を行うなら、
　各プラットフォーム用サブクラスを拡張するしか方法がない。

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

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

0434で解答2005/07/04(月) 02:40:11
>>431
> アプリ側では
> Win32Button を継承したクラスと XButton を継承したクラスの両方を
> 作って、WindowFactory の子クラスで生成を振り分けるってことでしょうか。

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

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

はぁ？上のケース1, ケース2であれば、表示コードや振る舞いコードが異なるはずだよな。
あんた、単に多重継承とかダイヤモンド継承みたく、無意味に複雑なケースを妄想して
独りで落とし穴に落ちて喜んでるだけとちゃうかぁ〜アホらし。
0435デフォルトの名無しさん2005/07/04(月) 02:47:49
お〜い>>428＝>>431、また死んだフリか？
04364282005/07/04(月) 02:48:44
これは単純な例ですが、たとえば

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

こういうことをしたいってことです。
0437デフォルトの名無しさん2005/07/04(月) 02:51:45
>>436
　>>432
> 別の問題として抽象クラスButtonの拡張(サブクラスButtonExt)が必要となる場合は、
> ・各プラットフォーム用サブクラスの親クラスを変更するか、あるいは、
> ・ButtonExtを多重継承した、各プラットフォーム用サブサブクラスを作る
> 必要がある。
0438デフォルトの名無しさん2005/07/04(月) 02:58:56
要するに>>428の質問は、
コアの単純な問題>>436に、
余分な笛や太鼓 (Factory, Strategy, プラットフォーム依存性の分離, 挙句に継承)を付けた、
典型的な混乱した質問ってこった。
0439デフォルトの名無しさん2005/07/04(月) 03:03:06
いや、そもそも継承による差分プログラミングを理解していないのだと思う。

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

もし実装が丸きり同じサブクラス作るなら、
クラス定義の中身はコンストラクターだけだよな。
本当にプログラミングした事あるのかね。
04404282005/07/04(月) 03:04:13
アプリに依存した Button を作りたいという話なので、
アプリを作るごとに親クラスの変更をしていくのは無理です。
04414282005/07/04(月) 03:05:28
>>439
コンストラクタ以外に、>>436で挙げたようなアプリ依存の実装があります。
0442デフォルトの名無しさん2005/07/04(月) 03:07:02
>>440-441
　>>437
04434282005/07/04(月) 03:10:31
もしかしたら「実装」の意味で誤解があるのかもしれませんが、
Win32ButtonExt と XButtonExt の実装が同じ、というのは、
これらのクラスで定義されるメンバ関数のコードが同じ、という意味で、
継承元の実装が同じ、という意味ではありません。

>>442
>>440は>>437に宛てたレスのようなものです。
プラットフォームに依存せずに Button の機能を引き継ぎたい、ってことなのですが。
0444デフォルトの名無しさん2005/07/04(月) 03:13:33
貴方は随分コマメにレスを下さるが、
議論の進め方、単語と意味の結びつきが、
撚れている感がある。

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

　　http://etc3.2ch.net/denpa/
04454282005/07/04(月) 03:15:54
唯一、正解に見えたのはこれだけですが。
＞Factoryパターンが提供するのは、生成時のサブクラス依存性の除去である。
＞　サブクラスの拡張に関するソリューションは提供していない。
0446デフォルトの名無しさん2005/07/04(月) 03:16:36
>>436
　>>432
> 別の問題として抽象クラスButtonの拡張(サブクラスButtonExt)が必要となる場合は、
　(略)
> ・ButtonExtを多重継承した、各プラットフォーム用サブサブクラスを作る
> 必要がある。

>>444
どうせ毎日暇で暇で困っている構ってちゃんだろ。
もう相手にする必要ねぇよ。
0447デフォルトの名無しさん2005/07/04(月) 03:17:32
>>446
そうだな。
プログラミング用語の認識すら曖昧な厨房相手に
マジレスし過ぎた。

もう寝るわ
04484282005/07/04(月) 03:18:53
>>446
ButtonExtを作るためにButtonExtを多重継承するってのは意味が通らない気がしたので
その文の理解は飛ばしたのですが、どういう意味でしょうか。
0449デフォルトの名無しさん2005/07/04(月) 03:19:51
>>447
この板は強制fushianasan導入して、荒らしを徹底排除しないとダメだな。
オヤスミ
0450とおりすがり2005/07/04(月) 03:25:03
多重継承嫌なら委譲すりゃえぇーやん。
まったくスレ汚しもいいとこだな
04514282005/07/04(月) 03:29:14
>>450
さすがに全部のメソッドを委譲可能にするのは骨が折れます。
できればオーバーライドできたらいいな、って話で、
その方法があれば教えていただきたいと思い、書き込んだ次第ですが。
0452デフォルトの名無しさん2005/07/04(月) 06:59:01
質問の内容がくるくる変わる、ズブの素人議論は
下記の隔離スレでどうぞ。

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

0453デフォルトの名無しさん2005/07/04(月) 08:11:34
>>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+"]");
　//などなど。全部の関数を委譲しなきゃいけないのが面倒ではあるが……
}
04544532005/07/04(月) 08:19:34
あ、もう一段追加すればいいだけか。

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");
}
0455デフォルトの名無しさん2005/07/04(月) 08:29:09
スレ違い。
議論の続きは下記でどうぞ

　〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
　http://pc8.2ch.net/test/read.cgi/tech/1119423033/
04564282005/07/04(月) 09:25:35
>>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");
}
0457デフォルトの名無しさん2005/07/04(月) 09:29:10
C++で多重継承も書けねぇのか。
悲惨。ついでにスレ違い。
議論の続きは下記でどうぞ

　〔隔離〕ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝとは何か〔スレ〕
　http://pc8.2ch.net/test/read.cgi/tech/1119423033/
0458デフォルトの名無しさん2005/07/04(月) 09:49:29
いつのまにやら、プラットフォーム毎の実装サブクラスの話が消し飛んでるのがご愛嬌だな。
こーゆー展開を「グダグダな似非議論パターン」と呼ぶ。

ようやくパターンスレらしいオチが付いた
0459428=4562005/07/04(月) 09:58:12
UserButtonのコンストラクタ内でFactoryを用いることにより
プラットフォーム依存の実装を隠蔽してるわけですが。
0460なんだ結局キチガイの荒らしか2005/07/04(月) 11:18:55
デザインパターンを参考に、ウィンドウシステムのフレームワークを作ってみました。

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

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

一応、Strategy的にイベントをフックできるようにしてるので
継承しなくても多くのことはできるのですが、
メソッドのオーバーライドをしたいときは、やはり継承したほうがいいように感じます。
0461なんだ結局キチガイの荒らしか2005/07/04(月) 11:21:47
アプリ側では
Win32Button を継承したクラスと XButton を継承したクラスの両方を
作って、WindowFactory の子クラスで生成を振り分けるってことでしょうか。

目的のボタンの実装では Button のインターフェースしか使用せず、
Win32ButtonExt と XButtonExt の実装が、継承元以外はまったく同じに
なってしまい、無駄が出る気がするのですが、これは仕方ありませんか？
0462なんだ結局キチガイの荒らしか2005/07/04(月) 11:22:28
もしかしたら「実装」の意味で誤解があるのかもしれませんが、
Win32ButtonExt と XButtonExt の実装が同じ、というのは、
これらのクラスで定義されるメンバ関数のコードが同じ、という意味で、
継承元の実装が同じ、という意味ではありません。

>>442
>>440は>>437に宛てたレスのようなものです。
プラットフォームに依存せずに Button の機能を引き継ぎたい、ってことなのですが。
0463なんだ結局キチガイの荒らしか2005/07/04(月) 11:23:01
ButtonExtを作るためにButtonExtを多重継承するってのは意味が通らない気がしたので
その文の理解は飛ばしたのですが、どういう意味でしょうか。
0464なんだ結局キチガイの荒らしか2005/07/04(月) 11:23:19
>>450
さすがに全部のメソッドを委譲可能にするのは骨が折れます。
できればオーバーライドできたらいいな、って話で、
その方法があれば教えていただきたいと思い、書き込んだ次第ですが。
0465なんだ結局キチガイの荒らしか2005/07/04(月) 11:24:11
>>453-454
うむむ、やっぱり委譲ですか。
こういうケースにぴったりハマるパターンがあったらな、と思ってましたが。
アプリ側のコードはすっきりするようになったので、これでいいかな、と。
ありがとうございました。
隔離スレで誰かが書いていた、「全ての問題は間接参照をはさめば解決する」という言葉の意味を実感。
0466こいつがコンサルとかSEとか名乗ってるんだから笑える2005/07/04(月) 11:47:12
パターン名：
　　　　グダグダ似非議論パターン

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

方法：
　　　　・良スレに混乱しまくった質問を書き込み、レス住人の反応を待つ。(>>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

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

04674532005/07/04(月) 11:49:40
>>456
> こういうケースにぴったりハマるパターンがあったらな、と思ってましたが。
これってDecoratorっていわないかい。
0468デフォルトの名無しさん2005/07/04(月) 11:51:53
……………　悪　霊　退　散　……………
0469デフォルトの名無しさん2005/07/04(月) 11:53:32
>>467
平日昼間っから暇そうでいいな。
俺、午後からリサーチャ募集の面談だわ。
いい加減、ダメダメ議論を振るのは勘弁願いたい。
0470デフォルトの名無しさん2005/07/04(月) 12:57:38
●●●●●●●●●●●●●●●●●●●●●
●　　　　　　　　　　　　 　●　　　　　　　　　　　　　 ●
●　　　　　　　　　　　　　 ●　　　　　　　　　　　　　 ●
●　　　　　　　　　　　　 　●　　　　　　　　　　　　　 ●
　　●　　　　　　　　　　 　●　　　　　　　　　　　 ●
　　　　●　　　　　　　　　●　　 　　　　　　　 ●　　
　　　　　　●　　　　　　 ●　 　　　　　　 ● 　　　　　　 　　　＿（ "''''''::::.
　　　　　 　　●　　　　● ●　　 　　 ●＿＿　____,,,... --‐'''^~ 　　ヽ 　　゛゛:ヽ
　　　　　　　　　●　 ●　　 　●　 ●:::::::::....:""""　　・　　　　・　　. ＼::.　　 丿
　　　　　　　　　　● ●　　　　● ●::::::::::::::::::: 　　　　　 ・　　....:::::::彡''ﾍ::::／
　　　　　　　　　　　●　　　　　　 ●:::::::::::::::::::::::::::::;;;;;,, ---‐'' "^~
　　　　　　　　　　　　●●●●●-‐‐ ''^~
0471デフォルトの名無しさん2005/07/04(月) 14:14:09
>>469
>>467はニート。
0472デフォルトの名無しさん2005/07/04(月) 19:08:10
>>466もかなりの暇人だと思うがどうか。
0473デフォルトの名無しさん2005/07/04(月) 22:51:58
>>470のほうがもっと暇人だろ
ご飯食った後ﾃｨﾝﾎﾟはみでているんだぜ？
0474デフォルトの名無しさん2005/07/05(火) 05:00:20
>>428の話は、質問の最中に、勝手に元の質問を変えていき、自己矛盾を起こす厨房議論だ
って先生がゆってた
0475デフォルトの名無しさん2005/07/05(火) 09:19:43
まだこのスレ続いてんのか
いいかげんキエロや
0476デフォルトの名無しさん2005/07/05(火) 12:12:02
>>456
UserButtonというよりは、それがButtonでいいんじゃないか？
Buttonというインタフェースまで作る必要は・・・あるか。うーんむずいね。
04774282005/07/05(火) 13:45:00
>>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のパクリですが。
0478デフォルトの名無しさん2005/07/05(火) 17:13:08
要するに、あんたの>>428の質問はためにする質問で、
継承じゃなくて委譲って言って欲しかっただけなのね。

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

うんざり
0479デフォルトの名無しさん2005/07/05(火) 17:15:50
自分は賢いと勘違いしてる初心者がやらかしがちな、
「問題設定が不適切かつ、問題設定の説明が不充分な質問」
って奴だな。
0480デフォルトの名無しさん2005/07/05(火) 17:22:24
自演乙
0481デフォルトの名無しさん2005/07/05(火) 17:27:29
相変わらず>>480はバカだな。
04824762005/07/06(水) 13:02:41
>>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)をわければできないかな？
外部公開用と実装用をいっしょにしてしまっているからできないのだとおもう。
04834762005/07/06(水) 13:04:10
>477
＞UserButton : public Button は処理を Button のインスタンスに委譲しますが、
＞WIN32_Button : public Button は処理を WIN32_WindowImp (HWNDを保持したモノ) のインスタンスに委譲してます。
とおもったらそういう仕組みにしてるのかな？('A`)
実装できないといっている理由がよくわからん。
0484デフォルトの名無しさん2005/07/06(水) 13:14:39
トップレベルのウィンドウをそのまま AbstractFactory にしてみるとか

Window *w = new W32Window();
Button *b = w->CreateButton();
0485デフォルトの名無しさん2005/07/06(水) 13:16:35
アンチが失言待ちか
0486デフォルトの名無しさん2005/07/06(水) 13:32:13
>>485
失言待ちアンチを無視してアンカーつけつつ話し合い、
失言待ちアンチが必死になる様を楽しもうではないか
04874762005/07/06(水) 15:23:41
>>484
あまり、W32Window()と実装が具体的すぎるのもどうかと。
Xだと、その部分がXWindow()になるのかな？
ＯＳが変わっても互換性が保てるソースコードでないとライブラリとしては厳しいｷｶﾞｽ。

トップレベルがAbstractFactoryってのは、なかなかおもしろいアイデアですな。
04884282005/07/06(水) 18:13:07
>>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
それ面白そうですね。思いつきませんでした。
ウィンドウの親子管理が簡潔になるかも。
04894282005/07/06(水) 18:26:20
new や delete を隠蔽したいもうひとつの理由として、
コンストラクタ、デストラクタの前後に初期化や終了の処理を入れたい場合があるからです。
初期化はすべてコンストラクタで行えばいいと思うかもしれませんが、
クラス設計がポリモーフィズムのオンパレードなので、コンストラクタ、デストラクタ中で
目的のメソッドを正常に動かすことは難しいです。
（最新の注意を払えばそれも可能ですが、その注意の手間はけっこうな損失になると思います）

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

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

のような処理をしているケースがあります。（同様に終了処理も）
04904762005/07/06(水) 20:07:58
>>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()とかならいいんだけど。
まあ、これも個人の好みの問題だと思うけど。
04914762005/07/06(水) 20:08:36
２９行か、漏れよくがんばったなぁ('A`)
0492デフォルトの名無しさん2005/07/06(水) 21:04:07
>>482
> 実装用のインターフェース(ButtonImpl)と、外部公開用のインタフェース(Button)をわければできないかな？
> 外部公開用と実装用をいっしょにしてしまっているからできないのだとおもう。

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

で、ちょっと話がよく見えないのは、
1. プラットフォーム共通の拡張コード (>>436) はどうするって話になったの？
　公開用インターフェース Buttonの下に実装クラス(またはサブクラス)作って、そこにメソッド書くのかな。
2. プラットフォーム非共通の拡張コード (>>432の最後の黒丸)はどうするつもりなの？
　結局 >>490上側のクラス関連図に載ってるクラスを全部拡張する必要があると思うけど。
0493デフォルトの名無しさん2005/07/06(水) 21:18:36
一貫性のない議論を自作自演するような奴に、マジ質問して答えが返るわけがなかろう
04944282005/07/07(木) 02:22:59
>>490
＞違ったらすまんのだけど、>>428の設計だと↓のような設計だと思う。

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

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


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

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

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

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

拡張メソッドは基底クラスにある既存のメソッドにより実装しています。
04954922005/07/07(木) 08:49:47
>>494
結局あなたとは最後まで話が通じませんでしたね。
私は>>492の2.に関して、現在の議論の状態を聞いている。
あなたが答えているのは、最初の>>428レベルの話に逆戻りしている。
細部が矛盾もしくは不明確だらけで、よく議論が継続しているものだと感心する。

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

0496デフォルトの名無しさん2005/07/07(木) 08:53:47
・・・って、結局プラットフォーム共通の拡張しかできない仕様なのね。
うーむ、問題が発散しすぎていて、明確な解答を出しようが無い話だった。

おしまい
0497デフォルトの名無しさん2005/07/07(木) 09:14:43
【>>492以前の結論】
　[公開ｲﾝﾀﾌｪｰｽ]　　[実装]

　 　　　　　　　　　 ──→ ButtonFactory->createButton().─────┐
　　　　　　　　　 ／　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .│
　Button class ───→ ButtonImpl abstract class　　　　　　　　　　　　│
　　　△　　　　　　　委譲　　　　△　　　　　　　　　　　　　　　　　　　　　　　　 │
　　　│ﾕｰｻﾞ拡張　　　　　　　　： 抽象ｸﾗｽ　　　　　　　　　　　　　　　　　　 │
　ButtonExt　　　　　　 ┌……┴…………┬………………┐　　　　　 .│
　　　　　　　　　　　　　　 ：　　　　　　　　　　　 .：　　　　　　　　　　：　　　　　. .│
　　　　　　　　　　　Win32ButtonImpl　XButtonImpl　OsakaButtonImpl ←┘
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　生成
0498デフォルトの名無しさん2005/07/07(木) 09:15:59
注) ButtonImplをｲﾝﾀｰﾌｪｰｽか抽象ｸﾗｽか、はたまた実装ｸﾗｽとするべきかは、
　　 まだ正確な議論は行われていない。
04994762005/07/07(木) 16:25:59
なんだか話が複雑になってきてわかんなくなってきた（＾ω＾；）

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

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

あっ、って>>496解決してた？らｽﾏｿ（＾ω＾；）
0500デフォルトの名無しさん2005/07/07(木) 23:57:50
>497
UMLもどきをASCII図で書くとは・・・。しかし、なぜかとても懐かしい。
0501デフォルトの名無しさん2005/07/08(金) 00:11:18
すごく低レベルな質問ですが、C++のシングルトンは
普通のグローバルインスタンスでは駄目なのでしょうか？
グローバルインスタンスの方がデバッグがしやすいのですが。
シングルトンの全ての利点よりデバッグのしやすさの利点の方が
でかいと思うのですが。
0502デフォルトの名無しさん2005/07/08(金) 00:14:48
>>501
スレッドとか関係しなくて、メンテナンス性とか考えずに
それで済むならそれでもいいんでないか

0503デフォルトの名無しさん2005/07/08(金) 03:24:53
>>501
どういうデバッグのしにくさがあるのか知らんが、
自分で使っていて使いづらいと思ったら、
無理してパターンにあてはめる必要はないかと思われ。
0504デフォルトの名無しさん2005/07/08(金) 03:28:00
注意深く見たら OsakaButtonImpl じゃねーか。ｵｰｻｶﾃﾗﾜﾛｽ（＾ω＾ ）
0505デフォルトの名無しさん2005/07/08(金) 12:50:07
>>504
死ね
0506デフォルトの名無しさん2005/07/11(月) 04:52:18
べつに C でやってもいいじゃん＞＞デザパタ
0507デフォルトの名無しさん2005/07/11(月) 05:24:14
>>506
それがさ、このスレには、頭の堅い粘着馬鹿がいるもんで、
なかなかそうも行かなくてねえ。
0508デフォルトの名無しさん2005/07/11(月) 08:10:27
Cやアセンブラのマクロでやろうが問題ないがここで話題にする意味はないな
0509デフォルトの名無しさん2005/07/11(月) 23:58:39
何を訳の分からんことを・・・
デザインパターンっていうのはオブジェクト指向言語を対象に
考えられたものだから非オブジェクト指向の言語じゃできないんだよ？
ＯＫ？
0510デフォルトの名無しさん2005/07/12(火) 00:50:23
>>509
ライブラリじゃなくてパターンなんだから、言語に関係なく本質は流用できるだろ。
0511デフォルトの名無しさん2005/07/12(火) 01:25:31
>>509
LispでOOPしちゃった俺が来ましたよ。
0512デフォルトの名無しさん2005/07/12(火) 05:05:46
ほう。CLOSかFlaversかな、それともLOOPSかな。
その上でのパターンについて語ってもらいましょうか。
0513デフォルトの名無しさん2005/07/12(火) 14:53:55
>>509
>デザインパターンっていうのはオブジェクト指向言語を対象に
>考えられたものだから
不合格。
0514デフォルトの名無しさん2005/07/12(火) 14:59:00
GoFのデザパタは、OOPL限定のデザパタ　だが
デザパタという言葉はOOPLに限定された言葉では無い
05157312005/07/13(水) 03:11:05
お舞ら胴でもいい話でループしまくてますね。
自分はデザインパターン愛用してますが。考え方ね。それでいいや。
0516デフォルトの名無しさん2005/07/13(水) 15:42:11
俺は、大した知識も経験もないくせに、他人を見下したように偉そうに
語る馬鹿が嫌いなだけ。
0517デフォルトの名無しさん2005/07/13(水) 20:47:03
俺漏れも。
特に>>516見たいな奴。
0518デフォルトの名無しさん2005/07/13(水) 20:49:30
俺も。
特に>>517みたいな奴。
0519デフォルトの名無しさん2005/07/13(水) 21:28:51
俺は>>519が嫌いだよ。。。(;;)
0520デフォルトの名無しさん2005/07/13(水) 22:10:44
俺は>>521が嫌い…
0521デフォルトの名無しさん2005/07/13(水) 22:50:45
(T_T)
0522デフォルトの名無しさん2005/07/14(木) 01:16:17
>>520はツンデレ
0523デフォルトの名無しさん2005/07/14(木) 01:29:05
>>523は絶倫
05245062005/07/14(木) 11:32:08
いや、結局関数ポインタを構造体で包んで組み合わせればそれらしく出来るだろ？
どうしてもってところはvoid*が必要になるかも知れないけど
そこはassertを使うなりして積極的にデバッグでつぶすなりしてさ
0525デフォルトの名無しさん2005/07/14(木) 16:04:22
ポリモーフィズムもデザインパターンの一種だからな。
0526デフォルトの名無しさん2005/07/14(木) 20:09:57
Cだと
同じ型の関数ポインタの配列作ってコマンドパターン風とか
同様のやり方でステートパターン風とか（これは普通配列は使わない）
はわりとありがちだな。

Observer風にコールバック関数を使うのも普通だ。
だいたいは、オブジェクトの替わりに関数ポインタとMagic Cookieとしての
void*ポインタが使われるな。
0527デフォルトの名無しさん2005/07/15(金) 00:45:49
>>526
フランスとかイタリアとかの料理みたいで素敵だな（○○風）
0528デフォルトの名無しさん2005/07/15(金) 00:51:06
Cでやる場合はデザパタなんて大仰な言い方はしないし、
昔からのテクニックだからな。
だから〜風。
0529デフォルトの名無しさん2005/07/15(金) 00:58:22
入社二年目のときにはじめてC++プログラムを書いたのだが、
オブジェクト指向が身についてなくて、クラスは一つも無く、
関数ポインタとコールバック、STL（これだけはなぜか知っていた）
が主な成分の、なんちゃってC++プログラムだった。無論デザパタ
なんて何のこっちゃだ。

しかしVC++5の、まだ出来たてほやほやのバグバグSTLを使うなんて、
今考えれば恐ろしいことをやったもんだ。
05305092005/07/15(金) 19:20:13
馬鹿かお前ら。屁理屈を言うな。
OOPL以外でやるデザパタなんざデザパタじゃねーんだよ。
もう一度出直してきな！
0531デフォルトの名無しさん2005/07/15(金) 19:40:27
釣り？
0532デフォルトの名無しさん2005/07/15(金) 19:50:20
釣りだろ。
0533デフォルトの名無しさん2005/07/15(金) 19:54:57
GoFのデザパタと、GoF以外のデザパタ
0534デフォルトの名無しさん2005/07/15(金) 21:54:57
ダイアモンド頭？
0535デフォルトの名無しさん2005/07/17(日) 07:06:53
釣りじゃねーよ。
非OOPLでデザパタやれんのかよ？
やれねーだろ。馬鹿かお前ら？
0536デフォルトの名無しさん2005/07/17(日) 08:53:55
Java厨というオチでしたか
0537デフォルトの名無しさん2005/07/17(日) 12:46:50
トリッキー君だろ？尻尾でてるしｗ
0538デフォルトの名無しさん2005/07/17(日) 13:44:04
>>537
自作自演で書いてるのか、仲間内で書いてるのか分からないけど、
発言ポインターを示さないからどっちがどっちに文句言ってるのか
全然分からない。

0539デフォルトの名無しさん2005/07/17(日) 14:10:58
非OOPLでデザインパターン？
酔狂も甚だしいなｗ
0540デフォルトの名無しさん2005/07/17(日) 18:23:24
>>538
535 = トリッキー君
0541デフォルトの名無しさん2005/07/17(日) 18:24:30
GoF は Interpreter 以外は完全に OOPL 依存だいな

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

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

======

>>539
「OOP = クラスベース」の意味なら言い直しを要求する
0542デフォルトの名無しさん2005/07/17(日) 19:20:10
>>541
そうかそうか。お前の言いたいことはよくわかったぞ。
0543デフォルトの名無しさん2005/07/17(日) 19:39:50
OOP+ ってなんやねん俺
0544デフォルトの名無しさん2005/07/17(日) 22:28:19
つかさ、本ｽﾚに書くならもっとアップトゥデートな話題にしてくれ。
ここは20年前の話題をノスタるスレじゃねぇーぞ
0545デフォルトの名無しさん2005/07/17(日) 22:54:01
>>542
逃げ腰発言ﾃﾗﾜﾛｽｗｗｗｗ

>>544
つかさ、ここは君のスレですか。君が気に入る話題じゃないと投稿しちゃいけないんですか。そうですか。
0546デフォルトの名無しさん2005/07/17(日) 23:04:17
>>544
GoF本自体の更新がとまっちゃってるのにそれは無理な話だぜ兄弟ｗ
0547デフォルトの名無しさん2005/07/17(日) 23:12:02
GoFのパターンは色々な意味で完成度が高いからな。
ＩＴ関係で5本の指に入る名著だ
0548デフォルトの名無しさん2005/07/17(日) 23:29:03
ひょんな事から、自然言語の流行と進化について、最近強い関心を持っている。
とりあえずある仮定がテーマなんだが、
自然言語が時代と共に変化していくのと同様、
建築やソフトウェアのデザインパターンも変化が避けられないと考えている。

例えば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とか、言語が変わる度に、実務的な基底は変化するから、アップデートが面倒ってば面倒なんだが
0549デフォルトの名無しさん2005/07/17(日) 23:34:52
↑に書いたのは、あくまで言語やパターンをとりまく外部環境の変化が主題なんだが、
それだけではなく、パターンに内在しパターンを形成する力となっているものが、
実は多くの人の手を通り年月を経る事で、次第にプログラミング言語への改善フィードバックを起こし、
最終的にはパターン言語自体にも目に見える変化をもたらすと考えている。

上記の話は、それほど突飛ではなく、むしろ当たり前の話に見えるかもしれない。
むしろこれから扱うべき問題は、パターン内部に働き、プログラム言語やパターン言語に変化をもたらす
特性の体系的な把握、そしてコントロールだろう。
このテーマにおいて、自然言語と同様に確率・統計的手法を適用できればいいんだが。
0550デフォルトの名無しさん2005/07/17(日) 23:35:56
×　変化をもたらす特性
○　変化をもたらす力
0551デフォルトの名無しさん2005/07/18(月) 00:13:37
こうずらずら書き並べてもらっても何言ってるのかわからないんだよね。
0552デフォルトの名無しさん2005/07/18(月) 00:32:41
Eclipseプラグイン開発を読んでて思いついたんだが、ホストプラグイン(エクステンション
プラグインに提供する拡張点を持ったプラグイン)を書くのは将来の拡張可能性を考慮し
て予め拡張点を仕込まなければならず、これは(設計が)相当難しい。
これはEclipseのホストプラグインに限らず、拡張可能なフレームワークを書く時に出てく
る一般的な悩みなんじゃないかな？

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

問題は、どこからでもインスタンスを取得できる(複数のクラスで共有される)事でスコー
プの範囲が限定できなくなる(しかし、限定されると拡張できない)点。
今はただの思いつきだけど、掘ってみると何か出てきそうな予感なんだけど、どうよ？
0553デフォルトの名無しさん2005/07/18(月) 00:39:38
あそ。読解力に問題ありだな。

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

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

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

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

0557デフォルトの名無しさん2005/07/18(月) 00:45:05
すまん。誤爆った。
05585542005/07/18(月) 00:46:24
ああ。そんなとこだと思うよ。

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

もういい加減、無理に協調性を発揮して、痛い人の相手をしてあげるのはやめ、
今後一切スルーしようと思う。
0559デフォルトの名無しさん2005/07/18(月) 00:56:39
うは。こりゃひでぇ議論妨害だな。
誤爆装って議論妨害しまくるとは、ゴミクズもいいとこだ。
人間、孤独が極まるとキチガイになるんだな。

>>548さん、議論の続きをどうぞ。
0560デフォルトの名無しさん2005/07/18(月) 01:02:56
>>554
ありゃま、失礼。て言うか、最初の草稿時には書いてた気がするんだけど･･････
行が伸びたんで削った時に、その部分が含まれちゃったみたいorz

AOPを仕込むにはインスタンスが必要なんだよ。
例えば、あるクラス内でnewによって生成されたインスタンスがあるとする。
このインスタンスにAOPを仕込むには、なんとかして外部からそのインスタンス
を取得する必要がある。
生成をFlyweightパターンに一任すると、何処からでもインスタンスを取得でき
るから、自由にAOPを仕込める。
0561デフォルトの名無しさん2005/07/18(月) 01:04:54
>>560
失敬な奴だな。
先に始められてる議論を無視して議論妨害か。
ろくな人生歩んでないなお前。

さっさと死ね
0562デフォルトの名無しさん2005/07/18(月) 01:07:29
>>561
ええー。
興味あるレスにアンカーつけてレスすればいいじゃん。
掲示板だし話題にのりたくなければのらなくてもいいんじゃない？
0563デフォルトの名無しさん2005/07/18(月) 01:10:36
>>556, >>560
こちらでどーぞ

　【GoF】生成パターンを語るスレ【ﾃﾞｻﾞﾊﾟﾀ】
　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
　
05645522005/07/18(月) 01:14:23
>>558
そのレスって俺宛？意味不明の言葉って＿|￣|○|||

規模の大小を問わずフレームワークを考える場合に、拡張性を考えれば
考えるほどゴールからは遠くなるという悩みどこに対する解法として一石
を投じたつもりだったんだけど･･････

>>561
投稿前にリロードしてみて良かった。なるほど、そういう前提なわけね。
板とスレという単位でしか枝を持てない２ちゃん型掲示板ではそういうルー
ルなの？
MLなんかだと複数スレッド同時進行は当たり前なんで、俺的にはそういう
ノリだったんだけど･･････そういうルールがあるなら暫く黙っとく事にするよ。
0565デフォルトの名無しさん2005/07/18(月) 01:15:37
>>562 >>564
議論の続きは、ぜひあちらでどうぞ

　【GoF】生成パターンを語るスレ【ﾃﾞｻﾞﾊﾟﾀ】
　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
　
0566デフォルトの名無しさん2005/07/18(月) 01:20:10
確率・統計的って言われてもイメージが湧かない
具体的にいうと？
0567デフォルトの名無しさん2005/07/18(月) 01:28:51
情報通信学会〜情報処理学会の論文を検索してみたら？
ここ数年で、随分進歩した様子が伺える。
あと、それを扱った本も出ているが、どうせ立ち読みもしないだろうから割愛。
0568デフォルトの名無しさん2005/07/18(月) 01:30:26
>>564
早速新スレの方にレスが付いてるよ。
新スレにちゃんと答えてあげたらどう？
0569デフォルトの名無しさん2005/07/18(月) 01:31:03
>>567
>情報通信学会〜情報処理学会の論文を検索してみたら？
いい加減こういうレス止めてほしいんだけどいいかな？
0570デフォルトの名無しさん2005/07/18(月) 01:34:14
いや、それならアンタには理解が無理だ。
残念だったね。
0571デフォルトの名無しさん2005/07/18(月) 01:35:43
>>570
結局、そうやって馬鹿にするのが目的でそういうこというわけでしょ？
だからいらないっての。
0572デフォルトの名無しさん2005/07/18(月) 01:38:45
この手の議論は、判る奴だけで進めれば充分。
素人に苦労して説明しても、説明範囲外でデタラメ解釈するのが関の山だし、
このスレには散々他人に苦労かけ、罵倒し倒して聞き出した情報を、
他のスレの荒らしに使うキチガイが居るからな。

素人の相手してもしようがない。つか、素人でも判る奴には判る。
結局、どれだけ新しい話題にアンテナ張って、貪欲に知識を吸収するか、
という生き方の問題なんだ。
0573デフォルトの名無しさん2005/07/18(月) 01:40:56
>>571
荒らすなバカ

>>572
あるある（笑
「素人にでも判るアインシュタインの相対性理論」読んで、
次の瞬間に「アインシュタインは間違っている」とか言い出す素人（笑
0574デフォルトの名無しさん2005/07/18(月) 01:41:09
>>572
その方針はこのスレみんなの決定事項なの？
だったら二度とこないけど。
0575デフォルトの名無しさん2005/07/18(月) 01:43:18
来なくていいんじゃない？誰も困らないよ。

あと、ここをウダウダ荒らす暇があったら、
新スレ
　【GoF】生成パターンのスレ【ﾃﾞｻﾞﾊﾟﾀ】
　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
で議論した方がよっぽど有意義なんじゃない？

もし貴方が荒らしじゃないと仮定しての話だが。
0576デフォルトの名無しさん2005/07/18(月) 01:43:44
>>572
誰がそんなこと勝手に決めたんだ。

>>574
こいつは
　http://pc8.2ch.net/test/read.cgi/prog/1114768433/815
　http://pc8.2ch.net/test/read.cgi/prog/1114768433/830
だから気にしなくていいよ。
0577デフォルトの名無しさん2005/07/18(月) 01:45:15
===========================================
キチガイ警報発令！！！！！！！！！>>764
===========================================
0578デフォルトの名無しさん2005/07/18(月) 01:45:58
===========================================
キチガイ警報発令！！！！！！！！！>>５６７
===========================================
0579デフォルトの名無しさん2005/07/18(月) 01:47:13
>>577-578 おいおい誤爆しまくりだぞｗ

===========================================
キチガイ警報発令！！！！！！！！！>>５７６
===========================================
0580デフォルトの名無しさん2005/07/18(月) 01:50:05
そして、ウダウダ言ってた荒らし >>556, >>560, >>562 >>564 は、
決して新スレ　http://pc8.2ch.net/test/read.cgi/tech/1121616564/
にレスを付けない、と。

いつものお決まりのパターンだな。

>>548
決着が付いたところで、議論の続きをどうぞ
0581デフォルトの名無しさん2005/07/18(月) 01:52:41
>>575
これで次に奴が来たら、奴は荒らし決定だな。
だって自分でもう来ないと宣言したのだから。
0582デフォルトの名無しさん2005/07/18(月) 01:58:38
>>581
どうみても一連のレスが個人のものにしか見えないけど？
これが「某スレ３２」って奴？
やっぱりＩＤ必要だな。
0583デフォルトの名無しさん2005/07/18(月) 02:16:58
荒らしが一人前の口利くんじゃねぇよ。
さっさと巣に戻って、プルプル震えてろよクズ。
おまえの巣はν速だろ。いつもヲチしてるよ。
05845482005/07/18(月) 02:18:58
相変わらずレベル低いのが粘着してるね。
05855482005/07/18(月) 02:22:35
レベル低いって言えば、こいつ。

> 569 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/18(月) 01:31:03
> >>567
> >情報通信学会〜情報処理学会の論文を検索してみたら？
> いい加減こういうレス止めてほしいんだけどいいかな？

こいつがレベル低いのは、別に
学会に入って居ないからとか、論文検索できないから、
なんていう意味じゃなくて、そもそも自主的な調査なり勉強を拒絶している所。
まあ荒らしだから、どれだけ自分がトンチンカンな発言してるか、理解してないんだろうけど。
0586デフォルトの名無しさん2005/07/18(月) 02:25:30
>>585
そいつ、業界外の素人つうか、単なる引き篭もりだよ。
自称年収５千万のスーパープログラマとかほざいといて、
実際はプログラムもできない素人だとバレて、
PC板の厨房に叩かれてた。合掌
0587デフォルトの名無しさん2005/07/18(月) 02:38:12
>>583-586
２〜３分刻みで必死だなｗ
0588デフォルトの名無しさん2005/07/18(月) 13:18:29
>>587
OCNが規制されたらぴたりと止んだね。
0589デフォルトの名無しさん2005/07/18(月) 13:26:44
＝＝＝＝＝＝＝＝＝＝＝＝
DQN>>588粘着中。スルー推奨
＝＝＝＝＝＝＝＝＝＝＝＝
0590デフォルトの名無しさん2005/07/18(月) 14:04:29
>>588
今頃、キーボード掻き毟って悔しがってる姿が目に浮かぶなｗ
２〜３分ごとにリズミカルに投稿したら、誰だって同一人物だって気が付くよな普通。
自分がレス飛ばしたら、相手のレスを待てよな。
こういう会話のキャッチボールのできない奴が、どの口で設計を語ってるのかホントわからんね。

設計なんてどんなにすごい技術を使ってあろうが、最新だろうが流行りだろうが実績あろうがなかろうが、
根本に「人にわかりやすく物を伝えたい」って気持ちがなきゃすべてが無駄。

俺の言葉を理解したいなら、この本と、この本と、この本を読んで勉強してきてから〜略
まあ、それでも君がボクの言ってることを理解するには○○年は無理だね。
なんて基本的に人を見下してる奴が、設計なんてやって上手くいくはずが無い。
0591デフォルトの名無しさん2005/07/18(月) 16:37:10
うっわ。すごいことになってるな。

このぶちきれて、いつも>>563みたいな行動にでる奴はなんなんだ？
自分が気に入らないレスがあると新スレ建設か？
別に何を話してもいいだろ。２ｃｈの掲示板なんだから。
このスレ自体たいした議題もないんだし。
別にお前のスレじゃないんだから。お前がスレの方向性きめるなつの。
05925912005/07/18(月) 16:53:18
>590 (= >587 = >589？)
＞ 設計なんてどんなにすごい技術を使ってあろうが、最新だろうが流行りだろうが実績あろうがなかろうが、
＞ 根本に「人にわかりやすく物を伝えたい」って気持ちがなきゃすべてが無駄。

考えてること、言ってることは非常にマトモなんだが、
どうして、そうヒネくれた小学生みたいなレスしか返せないんだ君は…。
端からみてると君の方が荒らしに見えるよ…。
0593デフォルトの名無しさん2005/07/18(月) 17:02:23
IDｷﾎﾞﾝ
05945912005/07/18(月) 17:46:02
>>593
とりあえず、一時凌ぎで名前欄に最初に投稿したレス番つけるの推奨とか。
自作自演する奴は見抜けないけど。
0595デフォルトの名無しさん2005/07/18(月) 20:44:20
最近ム板で大暴れの出張粘着氏についてまとめました。
事実誤認があれば指摘願います。

数年前から主に情報システム板で書込む出張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
0596デフォルトの名無しさん2005/07/18(月) 20:46:40
どっちが粘着だかわかんない
0597デフォルトの名無しさん2005/07/18(月) 21:13:20
自分の気に入らないレスがあると新スレ立てて追い出そうとする手口とか
このスレでもあったね。そういえば。
んで、結局、こっちのスレって過疎スレになっちゃって誰も書きこまない毎日ｗ
新スレの方が盛り上がっちゃったんで出張３２おかんむりｗで新スレ荒らしにくるし
ほんとどうしようもない馬鹿だよなｗ
今思えば奴１人だったんだろうなｗ

その性格じゃ、どこいったってみんなから
排除される運命だってことがわかってないのがうざいな。
0598デフォルトの名無しさん2005/07/18(月) 21:16:27
え〜っと、え〜っと …… ゴバク乙なのですよ〜
0599デフォルトの名無しさん2005/07/18(月) 21:59:41
Sくん相変わらず大変だな。
こっちはとりあえず位相幾何学まで守備範囲を広げる事になりそうだ。
0600デフォルトの名無しさん2005/07/18(月) 22:06:31
あと情報システム板に関して削除人が及び腰になってるのは、
なんかカラクリがあると睨んでる。

Googleで検索順位が恣意的に下がるなんて叩く連中は２ちゃんに多いけど、
情報システム板周りは真っ黒々なものが漂ってるな。
0601デフォルトの名無しさん2005/07/18(月) 22:24:08
>>597に関して。
彼(>>597)はそもそも、自分が言い放ったことを、
責任持って実現する努力のできる人間なのだろうか？

彼の話は最初は威勢がいいのだけど、
細部が見えてくると精細を失い、
本当に責任を持って行動しなきゃいけない場面で
フェードアウトを繰り返していると聞く。
akon曰く「今度は逃げないといってまたなんか始めた」。

お前本当に信用あるのか？
酒飲んで仲良く馴れ合うこととが、本当に受け入れられたって事じゃないよ。

人を叩くのは結構だが、俺の場合は「受け入れられない」のではなく
「関わっても無駄な奴とは没交渉」になるだけだ。
結構大変だよ、人よりIQ高い人生は。多数派は頭の回転が普通の方ばっかだからね。
初対面に近い、常識的に見て非常に高い学歴を持った先生から
「おまえIQ幾つだ？」みたいな訳のわからん言われる。
やるべき事を普通にやってるだけで、何かと障害が多いし、
挙句に煽り半分で「○×分野で奇才と呼ばれる研究者(?!)」の仕事紹介されたり、
「○×分野で世界トップクラスの学者とのミーティング」をこっそり設定されたり、
はたまた、「△□分野の世界コンテストで優勝した変わり者の某大研究者」なんての紹介されかかったり。
なんでおまいらそんなムキになるの、っつうくらい。
0602デフォルトの名無しさん2005/07/18(月) 22:33:29
あなたの肉棒を」まで読んだ
0603デフォルトの名無しさん2005/07/18(月) 22:38:43
#　IQ　が頭の良さと相関関係が無いことが再確認出来て嬉しいな
0604デフォルトの名無しさん2005/07/18(月) 22:51:03
>>603
乙かれちゃん！

けっきょく住んでる世界違うから、
貴方の世界の「頭いい」つうのとは価値観違うかもね。
貴方の世界の「頭いい」つうのは、あれっしょ、
しょぼいカードをいかに強いカードに見せるか？っつうポーカー技術
0605デフォルトの名無しさん2005/07/18(月) 22:53:27
そしておいらの住んでる世界の「頭いい」は、
知的誠実さと呼ばれる素直な知的能力を指してる。
貴方の世界では「素直、率直」は、食い物にされる弱者の属性なのだろうけども。
0606デフォルトの名無しさん2005/07/18(月) 22:54:52
IQ 無くたって頭良いか悪いか位の判別は付きますが
0607デフォルトの名無しさん2005/07/18(月) 22:57:26
住んでる世界違うからねぇ。ごめん、これ以上会話しても有意義なものは得られないみたい。
06086032005/07/18(月) 23:05:33
私の発言は二回目だよ。
もとより会話する気なぞありません
0609デフォルトの名無しさん2005/07/18(月) 23:06:37
出張３２がきてるの？
そのうちガイドラインができるんだろうなｗ
0610デフォルトの名無しさん2005/07/18(月) 23:08:41
出張３２はアンタ>>609

>>603
ああ。そこまでムカついてるなら、
俺はバカって事でもいいよ。
そのかわりアンタはバカの発言すら充分に理解できない大バ(略
0611デフォルトの名無しさん2005/07/18(月) 23:13:41
まぁとりあえずジャレ愛はこれくらいにして。

質問です。

オブジェクト指向〜計算モデル理論周りで、
型を位相幾何で扱う試みをしている方は居られますか？
OOに適用できるかどうか全く不明なのですが、
応用数学分野でそーゆーネタがあるのを今日知ったもので。
0612デフォルトの名無しさん2005/07/18(月) 23:17:25
>>611
なんだそれ？
お前また騙されたのか？ｗ
0613デフォルトの名無しさん2005/07/18(月) 23:18:58
>>612
煽り乙。これはネタじゃないんで、おまいさんはちょっと遠慮してもらえるかな？
S社のA導師が降臨してくれないかなぁ〜って雨乞いの儀式やってる所だから（爆
0614デフォルトの名無しさん2005/07/18(月) 23:20:02
>>611
すまぬ。位相幾何学で型をどうしたいのか想像もできん
0615デフォルトの名無しさん2005/07/18(月) 23:29:38
>>614
http://www.f.waseda.jp/murakami/jugyou/2003/kikagakuB1/print414.pdf
俺なんて、位相幾何学が何なのかすら分からんかったんでググってみた。
型キャストと継承に絡みそうな予感だけはした。けど、既存言語で表現可
能な世界なのか全く不明。
何より、デザパタとどう繋がるのか全く不明⊂⌒~⊃｡Д｡）⊃

て言うか、これこそスレ違いでしょ？
0616デフォルトの名無しさん2005/07/18(月) 23:34:42
ええぇーっとね。ごそごそ。

オブジェクト指向が持ってる属性っつうのは、オブジェクトの型を識別ための情報と仮定しよう。
更に、属性をベクトルで表すと仮定しよう。
すると、型とは属性ベクトルの合成と考える事ができる。

オブジェクト指向の型でこんな事いうと奇妙な感じがするけど、
上記の考え方は、文書集合で文書の特性を示したりするのに使われてて、
実際学会のある分野や、Google近辺で、ここ数年注目を集めてる、ともっぱらの噂だ。

ところで、属性をベクトルとして表現するのは、どうも距離空間に基づく考え方らしい。
ユークリッド幾何学とか射影幾何学で「同じ形」というのは、全てこの距離空間に基づく考え方だ。

とりあえず幾何学分野で形を比較するには、もっと良い方法として「位相幾何学」のやり方があるらすぃ。

ここで疑問。
「オブジェクト指向や計算モデルで言っている『型』とは、どの幾何学に対応するのか？
　例えば『位相幾何学』の考え方を流用する事で、なんらかのブレークスルーが得られないか？」
とゆーのが、とりあえず質問の主旨。

まぁ否定していただいても結構だけど。
OO分析の品詞抽出法(名詞句、動詞句、etc)を進化させちまうのがこっちの狙いなんで。
0617デフォルトの名無しさん2005/07/18(月) 23:35:09
>>615
たぶんこれ
http://nice-choice-peropero.web.infoseek.co.jp/mp3/ogino-rap.swf
http://nice-choice-peropero.web.infoseek.co.jp/flash/kamedat.swf
0618デフォルトの名無しさん2005/07/18(月) 23:38:06
>>615
「型」って言ったのがちょっと不味かったな。
とりあえず「パターン言語」と呼ばれる(たぶんある種の)言語の解析に
自然言語解析の方法を適用し、さらに将来的に発展させるために、
良い方法はないのかちょろちょろ考え始めている。
「位相幾何学」というのは、その一つの道じゃないかなぁ〜、と。
0619デフォルトの名無しさん2005/07/18(月) 23:39:38
>>616
>実際学会のある分野や、Google近辺で、ここ数年注目を集めてる、ともっぱらの噂だ。
噂かよｗ
06206152005/07/18(月) 23:41:50
やべっ、文字があちこち消えてるし・・・とりあえず訂正

3行目訂正
×　オブジェクト指向が持ってる属性っつうのは、オブジェクトの型を識別ための情報と仮定しよう。
○　オブジェクトの型の識別は、オブジェクト指向の属性(変数、メソッド)で行われると仮定しよう。
0621デフォルトの名無しさん2005/07/18(月) 23:42:51
>>619
そこらへんは常識的にボカすしかねぇーだろ。
0622デフォルトの名無しさん2005/07/18(月) 23:45:43
じゃとりあえずこのネタの議論は終了って事で。
0623デフォルトの名無しさん2005/07/18(月) 23:45:52
はい！みなさん！注目！
>>616の文章で一番大事なところは原点になってる考え方がすごくあいまいなこと。
まったく信用できるもんじゃない。
前提から話にならないし、議論の際、相手が発言にどんな軌道修正をかけても
そもそもの前提があいまいなので、まずい発言を繰り返してものらりくらりと逃げ回ることが可能である
という危険性を各自認識した上で議論に望むこと。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上！
0624デフォルトの名無しさん2005/07/19(火) 00:06:04
出張32はレスしなくてイイって言っただろ？
おまえは本当に空気読めない人間だな。

引き篭もってると、そこまでトンチンカンになれるのか。哀れだな
0625デフォルトの名無しさん2005/07/19(火) 00:10:15
>>610
それさ、元ネタは30年前に一世を風靡したネタでしょ？
もちろん、OOの型、DPの言語への適用は、
前例があるのかないのか知らないし、
30年前のネタがようやく実用にされるってのもアリだけど。
(超伝導なんて100年近く前のビンテージネタだけど、
　実利用が始まったのは20世紀も末に入ってからだったし、
　挙句に原理はまだ確定してないし。)
0626デフォルトの名無しさん2005/07/19(火) 00:19:07
そうすると、SRA先端研の青木さんが
「じゅん」で何故、位相幾何学に取り組んだのか？
というあたりが気になるな。

もちろんビットマップ〜ベクター表現のSmalltalkグラフィックスを進化させるという目的は明確だろうし、
具体的な応用事例として構造化学〜生体分子構造論があるだろう事は推測つくけど、
それではその先をどれくらいイメージされているのか？とても気になる
0627デフォルトの名無しさん2005/07/19(火) 07:28:52
>>626
理由なんかないだろ。
単に人の注目集めて、上手く当たってくれりゃ一儲けぐらいにか思ってないって。
設計の分野ってこういう奴多いよ。
0628デフォルトの名無しさん2005/07/19(火) 07:42:18
国立情報研や東大先端研の人達と、
分子構造のインタラクティブな可視化を研究したりされてるようですが。
いいやねいいやね、なんか楽しそうな研究テーマで。

おいらも数年前に、業務ちょっと離れた所で同じネタ振られたことあったんだけど、
生体分子のフォールディング構造予測＋構造活性相関みたいな話だと認識してそこに執着しちゃって
位相幾何なんつーテーマまでたどり着けませんでした（TT）


0629デフォルトの名無しさん2005/07/19(火) 07:51:18
むずかしい言葉を使ってレベルの高そうな話をしているようにごまかしているが、
ココ↓注目

例えば『位相幾何学』の考え方を流用する事で、なんらかのブレークスルーが得られないか？」

要は自分の知ってる知識使ってなんか（なんでもいいから（笑））いいもの発見できないかな？
的なものでテーマすら決まってない程度の低い話であることを忘れてはいけない。
0630デフォルトの名無しさん2005/07/19(火) 08:19:06
レベル高そうも何も

>とりあえず幾何学分野で形を比較するには、もっと良い方法として
>「位相幾何学」のやり方があるらすぃ。

これだけで素人丸出しなのが丸分かりなんだが（苦笑）
「形」も「良い」も数学的・論理的に未定義である以上、上の文章は何も
言っていることにはならない。

なおトポロジー（位相幾何）は数学科なら学部学生程度で学ぶ概念だが、
下積みとして必要とする知識は少ないから、その基礎概念を学ぶだけなら
そんなに難しいものではないよ。
0631デフォルトの名無しさん2005/07/19(火) 10:25:14
カイスタマイズの為にインタープリターまで行くなら、
最初から言語で組んだ方が早いんだよなぁ。

標準言語＋自作テンプレートライブラリで。

頭悪いんだろ。とか思う。
0632デフォルトの名無しさん2005/07/19(火) 12:21:48
>>601
よくわからんが神レベル
0633デフォルトの名無しさん2005/07/19(火) 20:27:05
>>630
一応、今持ってるイメージはちゃんと書いたつもりのつもり。。。。。。
トポロジーが同じっつうのが、なんとなくデザパタでパターンが同じというのと似ていると、
直感的に思った。

つか、オブジェクト指向ってそれ自体、簡単に数学モデルに移せないよなぁ〜。
関数型言語のモデルすら圏論みたいなわけわからんもの使ってるし。
やっぱ位相幾何は、統計とって距離を云々する問題の延長線上でしか使えないかなぁ〜
0634デフォルトの名無しさん2005/07/19(火) 20:52:20
>>633
でてくんなホラ吹き野郎。
ぶっころすぞ。
0635デフォルトの名無しさん2005/07/19(火) 20:59:21
>>634
キミのレスを見れば、キミはまともな仕事をしていないクズである事がよくわかる。
つか、キミってこの板で浮いてる。なんつか渋谷の真ん中で見る、ボロボロのホームレスみたいな衝撃
0636デフォルトの名無しさん2005/07/19(火) 21:13:27
>>635
知りもしない言葉なんか使うからそうやって恥をかくことになるんだよ。
だいたいお前、みんなが知らないような言葉使っただけで悦に浸ってる程度の低い学生だろ？
この業界はね。
頭のいい人ほどみんなにわかる言葉を選んで会話をするもんなんだよ。
0637デフォルトの名無しさん2005/07/19(火) 21:26:19
相変わらず哀れな奴だな。
判る判らないって、お前自身を基準にしちまったら
実も蓋もねぇ〜だろが。

はっきり言うよ、おまえみたいに新しい事への意欲を失っている人間は、
技術系の板に似つかわしくない。さっさと巣に帰って、二度とここにくんな
0638デフォルトの名無しさん2005/07/19(火) 21:30:02
>>635
あとさ、以前俺がお前に言ったこと、もう忘れてるだろ？

知らないという事を恥じるお前のセンスがバカだ。
知らなくてもそれなりに推測を重ね、傍証を重ね、
昨日判らなかったことを今日は判るように努力する、
これが頭がいいって事だって。前、説明しただろ？

あ、俺の文化圏の話だから、お前の文化圏とはまるっきり定義が違うのかもな。
結局お前にレス付けても、まるっきり無駄だと思ってる。おまえ進化しないもん。


0639デフォルトの名無しさん2005/07/19(火) 21:30:38
>>637
論点が全然違うじゃん。
そうやって普段から話をはぐらかす方向にしか議論をしないから
難しい言葉を使って聞き手を煙にまこうとすることしかできなくなっちゃうんでしょ。
かっこ悪いと思わないのか？
0640デフォルトの名無しさん2005/07/19(火) 21:31:36
>>638
サル相手にまともなレスつけてもまた暴れるだけだって。
バカはバカ、永遠に放置しとけばいぃ〜んじゃないの？
0641デフォルトの名無しさん2005/07/19(火) 21:33:26
>>640
おっけ。こいつ(>>634)、精神病んでるみたいだしもう放置。
どうせリアルでも誰にも振り返られない可哀想な生活してるみたいだし。
ネット上だからって律儀に相手する筋合いはねぇよな
0642デフォルトの名無しさん2005/07/19(火) 21:34:07
>>640
また、そこで自作自演？
あのさ、お前しかいないんだよ。
>>616←こんなはずかしい文章読んでうなずいてんのなんて。
はずかしくってレスつけられねぇんだよ普通は。
0643デフォルトの名無しさん2005/07/19(火) 21:34:51
>>633
デザパタの分析に確率・統計適用ってできないもんかね（ﾌﾟｹﾞﾗ
0644デフォルトの名無しさん2005/07/19(火) 21:35:30
>>640-641
いや、よっぽど、アレじゃない限りわかるよ（笑）
0645デフォルトの名無しさん2005/07/19(火) 21:35:46
お、NGワード設定したら結構いけるなこのスレ。
バカの発言全部NG表示になった（藁
0646デフォルトの名無しさん2005/07/19(火) 21:37:00
>>634
犯罪予告として通報しました。
警察がそちらに直行するそうです。
ばいばい
0647デフォルトの名無しさん2005/07/19(火) 21:38:47
>>646
おいおい、しまいにゃ捨て台詞かよｗ
かっこわり〜ｗ
0648デフォルトの名無しさん2005/07/19(火) 21:42:26
「我々の予想に反し、文明社会の住人よりも未開文化の住人方が、羞恥の意識が強かった。
　未開文化の住人は、恥を欠くことを恐れるあまり、社会の進化や他文化との交流を諦めた人達なのである」
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　文化人類学者
0649デフォルトの名無しさん2005/07/19(火) 21:44:27
>>648
しつこいなｗ
0650デフォルトの名無しさん2005/07/19(火) 21:49:49
哀れだな。
スレの主旨も判らず荒らしまくり、
ゴミ扱い、犯罪者扱いされても
まだしつこくまとわりつくとは。

よっぽど他人との交流に飢えてるんだな。
0651デフォルトの名無しさん2005/07/19(火) 21:51:08
＝＝＝＝＝＝＝＝＝＝＝
ストーカー排除＆リセット
＝＝＝＝＝＝＝＝＝＝＝
0652デフォルトの名無しさん2005/07/19(火) 21:51:57
>>650
もうすっかり負け犬根性だなｗ
0653デフォルトの名無しさん2005/07/19(火) 21:54:41
>>651
このうざい枠付きのレスもお前か。
何人自演してたんだホント。病気だな。

この板ＩＤつけちまえよ。
こんな馬鹿までわくようになったのか。
0654デフォルトの名無しさん2005/07/19(火) 21:56:06
位相幾何で「難しい言葉で煙に巻く」だって？ぷげら
0655デフォルトの名無しさん2005/07/19(火) 22:05:26
>>654
ま、結局、本人も「位相幾何」なんてよくわかってないから
こんなこと言っちゃう↓

>なんらかのブレークスルーが得られないか？

はぁ？
相手にしてもらいたいなら、これはお前が見つけてこいよｗ
0656妬み嫉みでｲｯﾊﾟｲｲｯﾊﾟｲの人にも判る２ちゃｎ講座2005/07/19(火) 22:09:28
┌─────────────┐
│枠とは、こういう形のものです　│
└─────────────┘

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
　これは、枠ではありません。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>652-653
のようなレスを、スレ違いの荒らし野郎、と呼びます。

0657デフォルトの名無しさん2005/07/19(火) 22:12:18
なにこのスレ？文末ダブリューの人がまた発狂してるのか
0658デフォルトの名無しさん2005/07/19(火) 22:13:11
>>657
でしょ？本人は至って正常なつもりだからコワヒ
0659デフォルトの名無しさん2005/07/19(火) 23:07:18
まぁあれだよね。
こんな荒れ果てたスレでも、
もしかしてマトモな人が居るかな？居ないかな？
とか思って、リアルの方の仕事をﾃｷﾄｰにぼやかしてマジネタ振ると、
食いつくのはキチガイだけ。

ここってホント終わってるスレだな。
0660デフォルトの名無しさん2005/07/19(火) 23:13:18
マジネタ？(w

イメージ・雰囲気だけで「位相数学」とか言ってるだけじゃん
専門家からは相手にされんよ

仕事とは片腹痛い

位相数学以前に同値類とか見て「あ、これはis a 関係に似ているのかも」
とか、そういう素朴としか言いようの無い反応を示してるんだろうけど

数学的に言うなら、まだ代数のが関連深いと思うよ
0661デフォルトの名無しさん2005/07/19(火) 23:17:27
「知らない」と認める事が恥だと思って、ひたすらハッタる池沼が粘着してるんだもんな。
そりゃ荒れるって。まともな人間と議論が噛みあうわけないだろ。
0662デフォルトの名無しさん2005/07/19(火) 23:26:51
>>661
「俺の知らないことで盛り上がるな」厨も確かにいるけど、
自分も数学系学部学生程度のレベルの人間から見てさえ
厨レベルでしかないことは自覚しろ

複雑系を数学的に理解せずに「チョウチョが飛んだらアメリカが風邪をひく
ことの説明が出来るんです！」みたいなこと言ってる
トンデモ本とレベルは変わらん
0663デフォルトの名無しさん2005/07/19(火) 23:35:04
>>660
マジレス？(藁

相変わらずつまんねぇレスだな。
名詞句抽出法周りでオモロイ見解が見つかったんで、
それをNDAに引っかからない範囲で紹介しようとしたんだけど、
相変わらずあいかわらずだな。
性格悪かろうと、あきんどだろうと、akonの方がよっぽど面白いや
0664デフォルトの名無しさん2005/07/19(火) 23:39:59
>>662
お前も相変わらずバカだな。文面読めてないし。
0665デフォルトの名無しさん2005/07/19(火) 23:44:40
もはや誰が誰だか分からんわけだが

おまいら少しはデザパタの話をしろ
0666デフォルトの名無しさん2005/07/19(火) 23:44:42
>>663-664
忠告だけど。
ここホント箸にも棒にもかからない馬鹿しか居ないから、
もし有意義な議論をしたいのならここではなく他でやった方がいいと思うよ。
0667デフォルトの名無しさん2005/07/19(火) 23:45:38
> 名詞句抽出法周りでオモロイ見解
で、それがどうデザパタと関係するのよ(w
0668デフォルトの名無しさん2005/07/20(水) 00:16:50
自称日本一のコンサルさんなら、
それくらい理解できるでしょう。

なんちゃって。元々は全然別の話題なんだけど、
全然別の所から同じような話が聞こえてきたんで、
まぁとりあえず
とりあえずネタとしては面白いかなぁ、と。
(いまさらApplicationArchitecture-なんちゃらかんちゃらを気にしてる人も居ることだし)

1.品詞抽出法： 名詞ならオブジェクト、動詞なら(動作主体となるオブジェクトの)メソッドにする(詳細ばっさり略)
1.の拡張1：　　　それでは接続詞は？連体修飾語は？
　　　　　　　　　　動詞の解釈はホントそれでいいの？
　　　　　　　　　　だいたい仕様書の字面が、本当に意味する事を正確に表しているわけじゃないよね？
　　　　　　　　　　というネタ。NLP方面追っかけると、いろいろ・・・わかるよ。俺は結構勉強になった。
　　　　　　　　　　あとオマケで、SWEB周りの現状と課題もわかってきた。

2.デザパタに関する話
　　　　　　　　　　こっちが>>610。
　　　　　　　　　　こっちは要するに、NLPやGenom周りでいろいろ応用されて実績のある
　　　　　　　　　　確率・統計モデルに基づく数理的手法を、
　　　　　　　　　　デザインパターンの抽出や分類に使えないかなぁ、というのが第一段階。
　　　　　　　　　　第二段階として、>>610に書いたような話もあるな、と。
0669デフォルトの名無しさん2005/07/20(水) 00:27:40
×　全然別の所から同じような話が聞こえてきたんで、 まぁとりあえず とりあえずネタとしては面白いかなぁ、と。
○　両方に引っかかるキーワードが全然別の所から出てきたんで、まあとりあえずこーゆーネタもあるよ、と紹介できれば良いと思った。
0670デフォルトの名無しさん2005/07/20(水) 00:29:46
なんで情報提供する側が低姿勢で説明しなきゃならんのか？

ここは変な村だな
0671デフォルトの名無しさん2005/07/20(水) 00:54:23
NLPっぽい夢見てるだけじゃん…。
ちょっとかじって面白そうだと思っただけですな。
スレ違いだから他でやってくれよ。ホント。
0672デフォルトの名無しさん2005/07/20(水) 01:03:59
>>668
みたいな事は、7年くらい前に学生だった俺でも考えたよ。
さっさとデザパタの話に戻ろう。
0673デフォルトの名無しさん2005/07/20(水) 07:29:15
ああ、それは良かったね。
なんでそんなに必死なの？

これが２ちゃんクオリティか。
0674デフォルトの名無しさん2005/07/20(水) 07:32:09
>>672
> さっさとデザパタの話に戻ろう。

もういい加減、古臭いGoF２３パターンで何百スレも費やすのは勘弁な。
せめて世の中並みにPoEAAかAPの話題にしてくれよ。

さもなきゃNLPのためのパターンでも説明しようか（藁
0675デフォルトの名無しさん2005/07/20(水) 07:32:40
で、やっぱり、>>616は出張３２なわけだ。
マジでウザイなコイツ。
06766742005/07/20(水) 07:36:53
674 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/20(水) 07:32:09
　↓
675 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/20(水) 07:32:40


・・・夜から朝まで粘着して大変だな、出張。
頭悪いんだからレスつけなくていいのに
0677デフォルトの名無しさん2005/07/20(水) 07:38:11
>>675　お前専用のスレを立てといてやったから、
　　　　　粘着談義はそっちでやってくれ。迷惑だ


　例の頭おかしい粘着が孤独を癒すためのスレ
　http://pc8.2ch.net/test/read.cgi/tech/1121781119/
0678デフォルトの名無しさん2005/07/20(水) 07:48:39
>>677
そうやって気に入らないことがあると
わざわざ新スレ立てて追い出そうとするのも出張３２の特徴らしいｗ
頭おかしいだろ？お前。
0679デフォルトの名無しさん2005/07/20(水) 07:50:11
>>678＝出張、さっさと新スレ逝け。
おまえを必要とする人間は、このスレには居ないんだよ。
0680デフォルトの名無しさん2005/07/20(水) 07:51:18
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
頭が弱い可哀想な人(>>678)が朝から粘着中
生暖かい目で放置しようね
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
0681デフォルトの名無しさん2005/07/20(水) 07:55:05
>>677,679-680
が出張３２ね。
特徴としてわざわざ新スレ立てて追い出そうと試みる。
ってのがヒットする。
0682デフォルトの名無しさん2005/07/20(水) 09:39:12
おまい本当にバカですね。

デザパタスレで喧嘩しかしないし。
0683デフォルトの名無しさん2005/07/20(水) 12:56:52
確かに全然デザパタの話が出てきてないよな〜と

>>631
EXCEL を思い浮かべれば分かりやすい
セルに関数を書いた後、さあどうやって計算するかって話で
06846832005/07/20(水) 13:02:06
悪い。自分でもよく分からなくなった


極端な話、LOGO インタプリタを C で作ろうとして
「んじゃ最初から C で書いたほうが早いよな」
って言ってるようなもんだと思う >>631 は

もちろん、限定的な用途ならば、わざわざインタプリタにする意味がないというのは同意
けど、そこにインタプリタにする何らかのメリットがあれば、(当然のことながら) インタプリタにする価値は出てくる
0685デフォルトの名無しさん2005/07/20(水) 14:17:02
インタプリタと言うからには、単なる値設定だけではなく、
ある程度複雑なデータ構造を定義したり、制御構造を書いたり、手続きや関数を定義して、
要するに複雑な処理を抽象化して簡単に実行できる機能が欲しいところだな。

あと、アプリを後から拡張する手段として使ったり。
0686デフォルトの名無しさん2005/07/20(水) 18:37:39
>>685
拡張する手段なら、DIコンテナ使って後付で刺せるようにしとけばいい。
0687デフォルトの名無しさん2005/07/20(水) 20:53:10
方法は色々ある。好きなのを使えばよろし
0688デフォルトの名無しさん2005/07/20(水) 21:33:10
まぁ>>686には、PlugIn + scriptとか、DLL + scriptというアーキテクチャの存在を示しておけば、
話は足りるだろう。
　・PlugIn手法＝DIパターン
　・script言語＝Interpriterパターン
という組み合わせのアプリは、世の中あちこちにある。
0689デフォルトの名無しさん2005/07/20(水) 21:34:36
J2EE〜EJBでそのパターンを書かれると、センスの悪さに結構ムカつく。
0690テンプレ追加よろしく2005/07/23(土) 10:20:20
サルでもわかる デザインパターン
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html
0691デフォルトの名無しさん2005/07/23(土) 15:34:42
インタプリタパターン使うとScript言語とか
作れちゃったりするんですか？
0692デフォルトの名無しさん2005/07/23(土) 15:36:17
>>691
そのまんまインタプリタ言語だな。
0693デフォルトの名無しさん2005/07/23(土) 18:41:07
インタプリタパターンでまともにScript言語作ったら遅いだろうなぁ
0694デフォルトの名無しさん2005/07/23(土) 20:37:58
おまぃ幼い煽りをしまつねえ。。
あれは再帰下降型パーサに適したパターンだから、ソレ実装するなら全然問題ナッシング。
むしろ、それ以上複雑な事をする場合にもあのパターンで公開インタフェース作れとか
訳判んない事逝ってるGoFを嘲笑うのが、小学生らしい振る舞いでつよ
0695デフォルトの名無しさん2005/07/23(土) 20:53:57
実際にインタプリタパターンを使って作った
Script言語ってあるかな？
0696デフォルトの名無しさん2005/07/24(日) 04:59:21
>>694
そんなこと言ってまた粘着刺激するから
議論レベルがどんどん小学生みたいになっていく・・・。
0697デフォルトの名無しさん2005/07/24(日) 18:12:43
>>691-695
独自の Script 言語を作り、それを組み込む事が Interpreter パターンだ
ぶっちゃけ Script 言語を作ることそのものが Interpreter だ

速い遅いは関係無いですよ？
0698デフォルトの名無しさん2005/07/24(日) 18:19:01
GoFにそう書いてあるの？
0699デフォルトの名無しさん2005/07/24(日) 18:31:31
GoF を始めとしたデザパタ本に書いてあることが全てだと勘違いしてはいけない
アレはぶっちゃけ 『サンプルコード集』 つまりサンプルだ


……と言って見るﾃｽﾂ
0700デフォルトの名無しさん2005/07/24(日) 20:10:27
　　　　 ///////
　　　　///////＿＿＿＿＿＿＿＿＿＿＿_
　　　 /////// ￣￣￣￣￣￣￣￣￣|￣￣
　　　///////　　　　　　　　　　　　　 (~)　ﾁﾘﾝﾁﾘﾝ
　　 ///////　　　　　　　　　　　　　　ﾉ,,
　　///////　　　　 ∧＿∧　　　　　　　　 ／￣￣￣￣￣￣
　 ///////　　　　 （　´∀｀）（ 厨 ） )）　＜　　夏だなあ〜
　/////// 　　　　 （つ　へへ つ　　　　　 ＼＿＿＿＿＿＿
///////　　　//△ ヽλ　 ）　）　旦
//////　　l￣￣￣￣￣￣￣￣￣￣￣l
/////　　　￣| .|￣￣￣￣￣￣￣| .|￣
////　　　　　^＾^　　　　　　　　　 ^＾^

　　　　　　　　　厨房の夏。2chの夏。
0701デフォルトの名無しさん2005/07/24(日) 22:50:00
>>697
なるほどありがとうございます。
いや、デザインパターンってすごいっすね。
0702デフォルトの名無しさん2005/07/24(日) 23:12:39
ttp://internet.watch.impress.co.jp/cda/news/2005/07/22/8522.html
0703デフォルトの名無しさん2005/07/24(日) 23:40:49
>>703
ｸｯｸｯｸｗ
「Winnyを使ってる事が発覚したら懲戒免職」ぐらいに罰則を厳しくしないと
流出事故はなかなか減らないと思うぞ。
0704デフォルトの名無しさん2005/07/24(日) 23:41:54
×>>703
○>>702
自分にレスしてどうする。
0705デフォルトの名無しさん2005/07/25(月) 01:14:58
==============================
キチガイが狂った独り言を書き込み中
==============================
0706デフォルトの名無しさん2005/07/25(月) 01:23:05
ＮＧワード：=============
0707デフォルトの名無しさん2005/07/26(火) 20:02:07
J2EEパターンの話題は駄目ですか？
0708デフォルトの名無しさん2005/07/26(火) 22:16:09
>>707
いいんじゃないですか？
0709テンプレ追加2005/07/31(日) 09:16:28
パターン指向リファクタリング入門〜ソフトウエア設計を改善する27の作法
http://www.amazon.co.jp/exec/obidos/ASIN/4822282384/
0710デフォルトの名無しさん2005/08/14(日) 10:44:37
　 ∧＿∧　　　　 ∧＿∧　
　（　´∀｀）　　 　（・∀・　）　
　（　　　　⊃□　（　　　　）　
　　　|＼
／￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| こんな感じで使ってちょ。
|
| Protuct p = factory.create( "HogeHogeClass" );
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　 ∧＿∧　　　　 ∧＿∧　
　（　´∀｀）　　 　（・∀・　）　
　（　　　　）　 ＝⊂　　　）　
　　　　　　　　　　　　|＼
　　　　　　／￣￣￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　| できたよ。
　　　　　　|
　　　　　　| static final String HOGEHOGECLASS = "HogeHogeClass";
　　　　　　| // これ以降 Factory に指定する全てのクラス名についての同様の記述
　　　　　　|
　　　　　　| Protuct p = factory.create(HOGEHOGECLASS);
　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　 ∧＿∧　　　　 ∧＿∧　
　（； ´∀｀）　　 　（・∀・　）　
　（　　　　）　　　 （　　　　）　
　　　|＼
／￣　　￣￣￣￣
|　・・・・・・・・・
＼＿＿＿＿＿＿
0711デフォルトの名無しさん2005/08/14(日) 18:14:43
product
0712デフォルトの名無しさん2005/08/16(火) 22:24:48
>>710がなぜいけないのか教えてください
0713デフォルトの名無しさん2005/08/26(金) 07:03:43
>>660
えぇーと。
数学者ではない俺にも、
おおよその方向はつかめた。

・代数との関連については、おっしゃる通りらすぃ。
　（ってWikipediaに書いてあったw）
・バイオインフォマティックでは、そのものずばりの名前が付いた手法が広く知られている。
　(そういえばSRA青木導師の仕事もバイオインフォマティック絡みだったっけ)

> 専門家からは相手にされんよ
必死だな（藁
0714デフォルトの名無しさん2005/08/27(土) 02:22:25
>712
Factoryの目的は、ソースコードの記述と生成するオブジェクトの
依存関係を切り離すことだから、（　´∀｀）の例とか（・∀・　）の
実装とかのように使うのはあまりメリットがない。

良く使われそうなのは
Protuct p = factory.create( f() );
// f()は設定ファイルとかからオブジェクト名を切り出す関数
とかかね？詳しくはModern C++ Design読んでくれ。

まあ、（・∀・　）のようにすると（（　´∀｀）の例とは違って）
実行時エラーをコンパイルエラーにすることができるメリットは
あるけどね。　
0715デフォルトの名無しさん2005/08/28(日) 00:02:09
>>714
？↓これはコンパイルエラーにできるのか？

Protuct p = factory.create(HOGEHOGECLASS);

べつに>>710のコードでも生成しているオブジェクトは隠蔽されてるわけで、
どの辺りがダメなのかがよくわからん。
07167142005/08/28(日) 03:10:46
>715
>？↓これはコンパイルエラーにできるのか？
ああ、すまん。HOGEHOGECLASSをtypoしたときの話ね。

>べつに>>710のコードでも生成しているオブジェクトは隠蔽されてるわけで、

隠蔽じゃなくて分離な。
普通インスタンスを作成するときは
Protuct p = new HogeHogeClass;
とかすると思うけど、そうするとその部分では"HogeHogeClass"のインスタンス
しか作れない。つまり、そのソースコードの部分に
『インスタンスを生成する』
『生成するインスタンスを指定する』
という２つの情報が縛りつけられているわけ。
これだと不便なことが多いから、『生成するインスタンスを指定する』というのを
切り離して指定できるようにしたのが factoryなんだけど、
Protuct p = factory.create( "HogeHogeClass" );
とすると結局『インスタンスを生成する』『生成するインスタンスを指定する』の
両方を指定しているので、結局 new とやっていることが変わらなくなる、
つうこと。

＃factoryはFactoryMethodパターンじゃ無いよな？
0717デフォルトの名無しさん2005/08/28(日) 08:50:25
>＃factoryはFactoryMethodパターンじゃ無いよな？
どっちかっつうと Service Locator Pattern かな。
0718デフォルトの名無しさん2005/09/04(日) 19:34:38
質問です。
デザインパターンのInterpreterパターンはLL(1)文法しか
記述出来ないのでしょうか？
LALR(1)文法をInterpreterパターンで実装することは可能でしょうか？
07196682005/09/08(木) 02:33:14
>>672
ははは。７年前（ぷ
実は先週、18年前にソレやった研究者の方にお会いした。
彼は、8年前にオブジェクト指向の静的モデリングと動的モデリング(シーケンス図w)の件もやったそうだ。
で、もう過去の研究です、だって。Webでググるとちゃんとひっかかるはずだよん

今週はdevil様とお会いできる予定。。。
0720デフォルトの名無しさん2005/09/08(木) 02:46:45
でぇ。
いちおうその方に、今その分野に興味を示している方が居る事は伝えておいた。
もしあなたが本当に関心あるのなら、この研究者を御自力で探して連絡とってはいかが？
先方もいろいろな分野のビジネスに強い興味をお持ちのようだ・・・
0721デフォルトの名無しさん2005/09/08(木) 03:16:50
またこの流れかよ…
0722デフォルトの名無しさん2005/09/08(木) 05:17:09
馬鹿ばっかり。。。
0723デフォルトの名無しさん2005/09/08(木) 07:10:57
IPSJソフトウェア工学研究会の例の本紹介するヤシすら居ないのは、
変なのが継続的に粘着荒らししているからだってさっさと気付け。
0724名無しさん＠そうだ選挙に行こう2005/09/10(土) 22:46:50
2ちゃん発とか喜ぶガキが多い中で、
>>721は随分ひねくれたガキだな（藁
0725名無しさん＠そうだ選挙に行こう2005/09/11(日) 07:42:00
数レス読んだだけでキモイのが常駐してることはよくわかった。
0726名無しさん＠そうだ選挙に行こう2005/09/11(日) 08:16:52
はるか昔からこんな感じです。
0727デフォルトの名無しさん2005/09/12(月) 06:25:25
>>725
どのレスがキモイ？
俺、>>719←こいつ生理的に受けつけない。
0728デフォルトの名無しさん2005/09/12(月) 06:40:44
インテリジェンスのある語りの一つも受け入れられずに
デザパタスレに来るとは、悲惨極まりないな。

オマエはHSPスレとかCOBOLスレで不毛な叩き合いしてなさいってこったｗ
0729デフォルトの名無しさん2005/09/12(月) 06:54:37
学部すら出てないようなの相手にムキになってもしょうがないだろう？
0730デフォルトの名無しさん2005/09/12(月) 15:05:21
>>727
同感。
0731デフォルトの名無しさん2005/09/12(月) 15:42:08
719が死ねばこのスレは平和になる気がする
0732デフォルトの名無しさん2005/09/12(月) 20:01:39
相変わらず中身のないキチガイがのたくってるな。
どうせリアルでもネットでも誰にも相手にされていないんだろう？
悲惨極まりないな
0733デフォルトの名無しさん2005/09/12(月) 22:55:21
>>719
てか、何をどうやったかなんて問題じゃない。
こんな金にならない分野の研究なんかに金だしてくれる奴がいることに驚きを隠せ無い。
研究成果とか金になってるの？
2005/09/08で先週とかいってるってことは一応日干しにはなってないんだよね？

マジでこんなくっだらねぇ研究に金出す奴の面が見て見たい。
本なんて半年に一度は信者に買ってもらわなきゃ食ってけ無いだろ。

何？つか、誰？その「devil様？」って知らないのはそいつが極レベルのマイナー研究者じゃなくて、俺が無知だから？
0734デフォルトの名無しさん2005/09/12(月) 23:31:58
>>719
うっひー久々ｷﾓｽｗｗｗ
自ら聞いてもいない事ベラベラしゃべりまくるまさに典型的ヲタ
歯が黄色くて髪は油でベタベタ、シャツはヨレヨレ黒ずんで、パンツは
スラックスで寸足らず。
なのに靴は黒いハイテクスニーカーなんだ！間違いない！
0735デフォルトの名無しさん2005/09/13(火) 00:01:02
>>734
いや、聞いてもいないことをしゃべりだすのはいいんだけど、
>>719は内容がキモ過ぎだよ。

人の手柄を自分のことのように語るのもまあよくいるクズだな。
まだ許せる。
でも、>>719の文章からはそれをも遥かに超越したキモさがあると考える。
なんだろう・・・このキモさは・・・。

もうホント、ガイドライン制作者並（専門家）の分析が必要なレベルだと思う。
0736デフォルトの名無しさん2005/09/13(火) 01:09:08
>>719がｶﾜｲｿｽ・・・。
まあ、>>719の発言は、たしかに電波はいってて怖いのでそう言われてもしょうがないが。

おまいらもおまいらで「キモイキモイ」とかガキみたいに騒ぎすぎだろ。
正直、おまいらもキモイ。器が知れる。

>>733はまともそうだが。
ちなみに俺もdevil様なんて奴はしらない。相当マイナー研究者。
0737デフォルトの名無しさん2005/09/13(火) 01:21:10
これは何というパターンですか？
0738デフォルトの名無しさん2005/09/13(火) 01:27:59
http://pc8.2ch.net/test/read.cgi/tech/1126539231/
このスレから嗅ぎつけた俺がきましたyo！

>>719-720
きんもーっ☆
0739デフォルトの名無しさん2005/09/13(火) 01:42:56
>719は『教えてあげよう』というアンチパターン
http://www.shos.info/develop/oo/dscsnptn.html#teach

そっから後は『マジギレ』かなあ……

おいらは『アンチパターンの指摘』
0740デフォルトの名無しさん2005/09/13(火) 05:52:46
キチガイの一人芝居炸裂だな。誰にも相手にされていない壊れた人間の標本（ぷ
0741デフォルトの名無しさん2005/09/13(火) 06:22:37
頭悪過ぎなキチガイ(約一名)に一応回答してあげよう。
俺ってなんて親切なんだろう（ぷげら

>>727　俺、>>719←こいつ生理的に受けつけない。

　君の粘着っぷりがキモ杉。とっとと精神病院逝け

>>733　こんな金にならない分野の研究なんかに金だしてくれる奴がいることに驚きを隠せ無い。

　それに莫大な投資してたのは、２０年前の通産省(爆笑.
　元ネタは有名な古い方法論者の提案した「名詞句抽出法」。
　現在も、ユースケース記述から人手でオブジェクトを抽出する時に使われてる。
　まあ今年になってから自動でそれやると言い出すのはどーかと思うが。

>>733　何？つか、誰？その「devil様？」って知らないのはそいつが極レベルのマイナー研究者じゃなくて、俺が無知だから？

　その先生は、東大出版会から本出してる人で、
　　　こ　の　ネ　タ　と　ま　る　き　り　無　関　係　 。
　ちなみにその本と、その次の著作は、その分野の開発やってる人ならたいてい知っている本だ（藁

>>734

　よくジャニーズ系と言われますが、何か。

>>737

　「キチガイが孤独を癒すために一人芝居する」パターン


頭悪過ぎ（ぷ
0742デフォルトの名無しさん2005/09/13(火) 06:31:32
> 　まあ今年になってから自動でそれやると言い出すのはどーかと思うが。

これは当然の事ながら、全然別の人ね
0743デフォルトの名無しさん2005/09/13(火) 07:35:49
本当にひどいな。
なんでこんなに嫌味ったらしくなれるのかね。
大体、2ちゃんねるでちょっと煽られたくらいでマジギレしてる時点でまともな人格の持ち主ではない。
0744デフォルトの名無しさん2005/09/13(火) 08:32:11
719=741は
2chをガッコの中にある掲示板と勘違いしてるんじゃないかな
ガッコのお外での遊びかたとを覚えなさい
0745デフォルトの名無しさん2005/09/13(火) 08:36:33
子供なんだろうね。いうに事欠いてジャニ系とは・・・。
0746デフォルトの名無しさん2005/09/13(火) 08:38:31
プライド高い人っていじめると楽しいよね。
0747デフォルトの名無しさん2005/09/13(火) 10:04:59
>>746
傍迷惑だから無闇に刺激するのは止めてくれ
0748デフォルトの名無しさん2005/09/13(火) 12:41:50
あははは
すげー気持ち悪い

なんでこんなに2chに染まりきれるんだ

devil様
http://arn.kyosui.net/arc/devil/
0749デフォルトの名無しさん2005/09/13(火) 12:49:23
>>741
　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／
0750デフォルトの名無しさん2005/09/13(火) 22:49:30
>>719-720
おい！>>719でてこいよ！
お前、どうやったらそんなキモイ発言ができるんだ？
キモ過ぎんだよ。
>>741で一名だと思ってるみたいだけど全然そんなことねーぞｗ
だって>>719-720のレスってかなり稀にみるキモさだぜ。
正直いってすげーよ。
どこまでクズ晒せば気が済むんだとかそういうレベルとっくに超えてるしｗ
0751デフォルトの名無しさん2005/09/13(火) 23:15:54
顧客に迷惑をかける自称アーキテクトデザパタ厨ｗｗｗ
http://www.atmarkit.co.jp/farc/rensai/28it02/28it02.html


「なぜこのアーキテクチャを採用したんですか？」

「いや、なぜって……。いま作るならこれがいま一番はやってるからなんですけど……」

「どうしてこんな設計になっているんだ？」

「このシステム、5年はこのまま改修しながら使い続ける予定なんですけど、もちろんそれは考えてのことですよね!?」

「いや、ちゃんと現場を教育し続ければ可能だと思うんですよ、第一……」

「できる、できないの話じゃないんですよ。じゃあ一体その教育コストと時間は誰が払うんですか？ あなた、払ってくれるんですかね？」

「いや、それは……」

「あなたの趣味で作られたら、運用する側はたまったもんじゃないんですよ。私のいってること、理解できますよね？」

「いえ、そもそもソフトウェアというのはオブジェクト指向に基づいてこう作るべきというのが最近の考え方で……」

「あんたから大学の授業みたいなのを聞きたいんじゃないんだよ、もういい。帰って」
0752デフォルトの名無しさん2005/09/14(水) 00:05:47
>>751
デザインパターン一番の問題はそこだな。
果たしてあの５００ページの本をいかにしてプロジェクトのメンバーに
読ませることができるかということだな。
実績なんていくら挙げたって全く無意味。
0753デフォルトの名無しさん2005/09/14(水) 00:14:59
デザパタ厨の哀れな末路。

「もういい。帰って。」

上司になんて報告すればよいのだろう。

「お前みたいな技術馬鹿はうちには要らない。」
0754デフォルトの名無しさん2005/09/14(水) 00:21:17
つうか、全員がコアアーキテクチャまで完全に理解できなきゃダメ、
とか言い出すとオブジェクト指向設計なんて成り立たん。
(少なくとも、業務システムである程度高度なことやろうと思ったら)
業務コード書く人間は、コアアーキテクチャをほとんど知らなくて
書けるようにするための、デザインパターンだろ。

まあ、>>751 の例はちょっと説明能力なさすぎだけど・・・。
0755デフォルトの名無しさん2005/09/14(水) 00:27:09
>>754
そもそも、その説明から何言ってるのかわからねーんだよ奴等には。
ソース見て、一瞬で「やる気ねー」ってところですでに駄目。
「この本を読んで」ってのは技術者同士では通じても、
ビジネスの話では全く通用しない。
あまりにも時間がかかりすぎる。
リンク先にも書いてあるでしょ？
一般の業務をやってる人間でもプログラムに関わることが多くなった。
って。それはそういうことなんだよ。
0756デフォルトの名無しさん2005/09/14(水) 00:38:50
アナリシスの話と設計の話を同一視して語ってもなんにもならない。
「顧客」と「アナリスト」の関係と、「アナリスト」と「設計者」の関係の共通点を抽出すれば何か発見できるのか？
0757デフォルトの名無しさん2005/09/14(水) 00:46:43
>>756
そんなことは関係ない。
これは実際の現場で実際におきている、もしくはこれからおきる問題だ。
0758デフォルトの名無しさん2005/09/14(水) 00:47:36
>>755
>そもそも、その説明から何言ってるのかわからねーんだよ奴等には。
いや、クライアントに説明するときには、こんな言葉は使わんけど・・・。

>リンク先にも書いてあるでしょ？
というか、リンク先の記事は、デザパタ云々というレベルの話じゃないと思うけど。
組織分析とか、業務分析の問題でしょ。
このレベルの説明でデザインパターンなんて持ち出さないよ。
0759デフォルトの名無しさん2005/09/14(水) 00:49:29
>>757
君にとっては「「顧客」と「アナリスト」の関係」は「実際の現場」じゃないのか？
0760デフォルトの名無しさん2005/09/14(水) 00:51:23
アナリストって何？肛門の穴にやたらと指を突っ込みたい香具師の事か？
0761デフォルトの名無しさん2005/09/14(水) 00:53:24
ここでいう「アーキテクチャ」はデザパタみたいな小さい意味での
アーキテクチャとは違うわな。IT Architect 読んでる奴なら分かると思うけど。
ちょっと的外れな気がする。

>>760
ちょっｗｗｗｗｗｗｗｗｗﾌﾘｽｸ入れてみれｗｗｗｗｗｗｗ
0762デフォルトの名無しさん2005/09/14(水) 00:54:13
>>760
そのとおり。
ちなみにクライアントは性格の暗い蟻のことだ。
0763デフォルトの名無しさん2005/09/14(水) 00:54:16
>>758
いや、モロにデザパタのことでしょ。
これまででた胡散臭い開発手法を一掃しなきゃいけないときがきたってことでしょ？
そもそも、デザパタを導入しなきゃいけない理由を説明できるの？
0764デフォルトの名無しさん2005/09/14(水) 00:56:15
業務分析やアーキテクチャ、運用計画とデザパタの区別がつかんような奴には俺はよう説明せん。
0765デフォルトの名無しさん2005/09/14(水) 00:58:48
>>764
同じなんだよ。
デザパタを導入する＝人にその開発手法を押し付ける
こと自体お金がかかるんだ。
必ず説明責任が発生するんだよ。
いままでの技術者相手に相手の不勉強を理由に自分の正当性を突き通すことは全くできなくなった。
ってことだよ。
頭使え馬鹿。
0766デフォルトの名無しさん2005/09/14(水) 01:03:47
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!
0767デフォルトの名無しさん2005/09/14(水) 01:07:02
デザパタ終わったな。
0768デフォルトの名無しさん2005/09/14(水) 01:08:04
ｷﾀ━━━━デザパタ完全消滅決定━━━━ｯ!!
0769デフォルトの名無しさん2005/09/14(水) 01:09:52
>>764
同じなんだよ。
構造化プログラミングを導入する＝人にその開発手法を押し付ける
こと自体お金がかかるんだ。
必ず説明責任が発生するんだよ。
いままでの技術者相手に相手の不勉強を理由に自分の正当性を突き通すことは全くできなくなった。
ってことだよ。
頭使え馬鹿。
0770デフォルトの名無しさん2005/09/14(水) 01:15:42
>>769
ハイハイ。
その時代には素人が開発には入ってなかったのでまったく意味が通じません。
コピペするにも頭が悪いと効果が薄いですねｗ
0771デフォルトの名無しさん2005/09/14(水) 01:16:53
デザパタって開発手法だったのか
0772デフォルトの名無しさん2005/09/14(水) 01:17:03
>デザパタを導入する＝人にその開発手法を押し付ける
デザパタって開発手法だったんだ

ふつう開発手法というと、WaterFallとかAgileとかXPとか開発プロセスの
話になるかと思うんだけど？

デザパタは単に（建築）工法とか（建築物の）様式ぐらいの話じゃない？
0773デフォルトの名無しさん2005/09/14(水) 01:23:44
食いつきすぎ
0774デフォルトの名無しさん2005/09/14(水) 01:28:06
>752
形を真似て形に入り
形を極めて形から自由になる

デザパタに囚われちゃいかんよ。
システムにフィットさせるために修正・改変するのは当然のことですな。

システム（問題領域）にとって最適な形だったら、ちょっとぐらいむずかしくても
理解しやすいだろうし。
＃お客はその問題領域のプロ（のはず）なんだからね……
0775デフォルトの名無しさん2005/09/14(水) 01:39:04
だから、この段階ではデザパタなんて元々出てこねぇって。
0776デフォルトの名無しさん2005/09/14(水) 01:55:11
客が実装に関わる事はない。
なんでデザパタと結びつくと思ったんだ？的外れすぎて（ ﾟдﾟ）ﾎﾟｶｰﾝ

てか、ここはDIコンテナで実装して代替性を確保して下さいね
とか言ってきたら怖いっての、色んな意味でｗ
0777デフォルトの名無しさん2005/09/14(水) 01:57:24
デザパタ信者必死過ぎｗ
0778デフォルトの名無しさん2005/09/14(水) 02:00:59
ハイハイ、全然的外れな問題にすりかえないでね。
対象が客なんて誰も言ってないよ。
0779デフォルトの名無しさん2005/09/14(水) 02:05:33
対象は素人なの？うちの職場に素人は居ません。てか、要りませんｗ
0780デフォルトの名無しさん2005/09/14(水) 04:18:06
>>779
君は馬鹿だからレスしないでねｗ
0781デフォルトの名無しさん2005/09/14(水) 04:36:07
デザパタ終了！残念！
0782デフォルトの名無しさん2005/09/14(水) 05:16:55
そ、それはひょっとしてｷﾞｬｸﾞで言ってるのか…？
0783デフォルトの名無しさん2005/09/14(水) 06:41:57
キチガイの一人芝居乙
0784デフォルトの名無しさん2005/09/14(水) 06:44:18
まあ、デザパタ批判はあっていいけど、
関係ない記事を引用して我田引水な論理を展開されてもなぁ。
やるなら、もうすこし議論のしがいのある内実を伴った批判を
してほしいもんだ。電波いじりも面白くないわけじゃないがそろそろ飽きた。
0785デフォルトの名無しさん2005/09/14(水) 06:44:29
Gag of Four
0786デフォルトの名無しさん2005/09/14(水) 09:01:58
ポリシー無くただ流行っているというだけで
過去に無かった設計技術を導入するのもどうかと思うけど、
http://www.atmarkit.co.jp/farc/rensai/28it02/28it02.html
を書いた人の会社 豆蔵 のページ(※)を見てみると、
デザインパターンそのものを否定したくって
この記事を書いているようにも思えないんだけど？
つか@ITの記事にデザインパターンなんて言葉でてないし・・・

※
【ホームページ】 http://www.mamezou.com/
【技術情報】 http://www.mamezou.net/
0787デフォルトの名無しさん2005/09/14(水) 09:34:50
>>748
相変わらずバカだな。

こっちが書いたまんまググってんじゃねぇ〜よボケナスが。
キチガイはどこまでいってもキチガイだな
0788デフォルトの名無しさん2005/09/14(水) 09:48:09
devil様降臨age
0789デフォルトの名無しさん2005/09/14(水) 11:23:30
おー
釣れてるしー

その貧困なボキャブラリで

>1.品詞抽出法： 名詞ならオブジェクト、動詞なら(動作主体となるオブジェクトの)メソッドにする(詳細ばっさり略)
>1.の拡張1：　　　それでは接続詞は？連体修飾語は？
>　　　　　　　　　　動詞の解釈はホントそれでいいの？
>　　　　　　　　　　だいたい仕様書の字面が、本当に意味する事を正確に表しているわけじゃないよね？

こんなのできるわけないじゃん...

どんだけIQ低いんだよ
お前IQいくつだ？
0790デフォルトの名無しさん2005/09/14(水) 11:36:43
　∞
8 ※ 8 ここまでよんだ。 平成17年9月14日(水)
∞
0791デフォルトの名無しさん2005/09/14(水) 11:47:09
ICQってまだあるの?
0792デフォルトの名無しさん2005/09/14(水) 12:02:28
変態じゃ、変態の仕業じゃ
0793デフォルトの名無しさん2005/09/14(水) 12:07:33
http://www.iqtest.dk/main.swf
さぁ、お前らのIQを晒しなさい。スクリーンショットも撮っとけよｗ

ちなみに、俺は107だった。世の中に俺よりIQ低い奴が30億人
くらい居ると思うと人生に希望が持てたよ（ ´,_ゝ｀）ﾌﾟｯ
0794デフォルトの名無しさん2005/09/14(水) 13:18:39
お、122だ、嘘くせーテストだなｗ
30億人とかはどこに出るんだい？答えもみたいなぁ
0795デフォルトの名無しさん2005/09/14(水) 13:25:41
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
ココは子供が多いスレですね
0796デフォルトの名無しさん2005/09/14(水) 13:27:23
19だからｷﾞﾘｷﾞﾘOKなのか？
0797デフォルトの名無しさん2005/09/14(水) 14:09:00
デザインパターンの本読んでみたけど
「ふーん、こんなの普通に使ってるよ」ていうような手法が多かったな。

でも読む価値はある本だ。
0798デフォルトの名無しさん2005/09/14(水) 14:20:52
ゲームに役立つパターンってありますか？
0799デフォルトの名無しさん2005/09/14(水) 14:21:37
ビットパターン
0800デフォルトの名無しさん2005/09/14(水) 14:24:21
切り番ゲットパターン
0801デフォルトの名無しさん2005/09/14(水) 15:49:26
>>793
これスピード関係ねーのかな？
めっちゃくちゃ遅くても１３０とか出たぞ。
0802デフォルトの名無しさん2005/09/14(水) 15:57:23
>>793
107ってめちゃ低いんじゃんひょっとしてw
0803デフォルトの名無しさん2005/09/14(水) 16:05:03
>>802
100くらいが平均だと聞いたが。
0804デフォルトの名無しさん2005/09/14(水) 20:13:33
>>798
ステートパターン
タイトル画面とかの状態をごちゃごちゃ入れ替えると楽
0805デフォルトの名無しさん2005/09/14(水) 20:19:00
>>802
本来のIQテストは125を越えると天才で1300でルチ将軍と言われてる。
0806デフォルトの名無しさん2005/09/14(水) 20:53:49
>>798
シングルトン一択。
>>804←馬鹿
0807デフォルトの名無しさん2005/09/14(水) 20:57:22
そ、それはひょっとしてｷﾞｬｸﾞで言ってるのか…？
0808デフォルトの名無しさん2005/09/14(水) 22:24:32
ギレン・ザビは180、だと思った。
0809デフォルトの名無しさん2005/09/14(水) 23:49:15
その割にはアサーリ嵌められて氏んだなｗ
0810デフォルトの名無しさん2005/09/14(水) 23:59:13
デザインパターンって「あるある」って思うパターンに名前付けただけだよね。
いろんな本にも書いてあるけど。
0811デフォルトの名無しさん2005/09/15(木) 00:06:11
クラスを挟んでくっ付ける。ハイッ、ハイッ、ハイハイハイ？
0812デフォルトの名無しさん2005/09/15(木) 00:09:37
>810
デザインパターンは「あるある」って思うパターンを名前付けて『整理した』ものです。
指南書ですな。
0813デフォルトの名無しさん2005/09/15(木) 00:26:25
しかし、本を読まなければ「○○パターンですよ」とか言われても、書かれてもさっぱりですな。
0814デフォルトの名無しさん2005/09/15(木) 00:41:15
なんだ、就業時間中から暇持てあましてるとは、
非就業者か社内失業者か、はたまた開店休業状態の会社の社員か？
ここに常駐している約一名の困ったチャンわ(w

>>798
> 品詞抽出法 (略) 動詞の解釈
ｼﾗﾈ〜ﾖ、そんなﾉｰﾀﾘﾝ方法論の詳細は。
不安だったら自分で調べたらどう？
ＤＢﾃﾞｰﾀの画面編集ｼｽﾃﾑに何十億もかけてる現場に行けば、
DOAの一環で名詞句抽出法業務辞書を作って、ﾃﾞｰﾀ項目候補にしているから、
そこで動詞の扱い聞いて来い(ﾜﾗ

(つづく)
0815デフォルトの名無しさん2005/09/15(木) 00:44:00
Gag of Four ← ﾜﾛﾀ
08168142005/09/15(木) 01:20:19
>>798
> 仕様書に全て(の要求が)書かれているわけない

そこまで素人じみた考えする奴ぁ滅多に居ね〜よ。20年前の通産省のお役人ならいざ知らず(ｗ

ユースケース・シナリオを使ったユースケース分析の本でも読んで
機能要求文の名詞や動詞が､分析モデル(分析レベルのオブジェクト)のどんな要素に対応するか
そのﾉｰﾀﾘﾝ頭で考えれ(ｗ
話を即座に設計モデル〜実装に結びつけない慎重さが肝心だ(ﾜﾗ

> IQいくつ？
１８０

つか､素人がよく勘違いして騙されてるから警告のﾈﾀ振り
0817デフォルトの名無しさん2005/09/15(木) 01:43:58
>>814を読んで、VC/Aliance先向け事業説明資料を書き直しているのが約一名

そーいえばakonて一体どーなったの？
0818デフォルトの名無しさん2005/09/15(木) 01:52:06
>>816
それはひょっとしてｷﾞｬｸﾞで（ｒｙ
0819デフォルトの名無しさん2005/09/15(木) 01:56:21
キチガイはさっさと氏ね
08207982005/09/15(木) 02:09:57
いやいやお兄さん

>（あなたの）その貧困なボキャブラリで(>>787を参照）
>こんなの（機能要求の分析）できるわけないじゃん...

っていう煽りなのよ>>798は
この程度の煽りは意図通り解釈して欲しかったなあ

なんか空回っちゃって周囲の人大変そうだな
0821798→7892005/09/15(木) 02:13:05
まちがった
0822デフォルトの名無しさん2005/09/15(木) 02:13:52
>>820
あえて釣られてやろう。お前最低だな。
0823デフォルトの名無しさん2005/09/15(木) 03:17:38
相変わらず話の隅っこ突いて喜んでる幼い奴だなあ。

ここまでトロくて厚顔無知だと、周りの人達は大迷惑だよな(ぷ
akonもこんなにトロいのか？
0824デフォルトの名無しさん2005/09/15(木) 22:59:59
Chain Of Responsibilityってどんな時に使うのか教えて下さい！
0825デフォルトの名無しさん2005/09/15(木) 23:05:17
>>824
わかんねーもんわざわざ使おうとすんな！
馬鹿が！すっこんでろ！カス！クズ！ボケ！アホ！
0826デフォルトの名無しさん2005/09/15(木) 23:12:42
このように直接回答することを避け、返答する人が見つかるまで繋げていく場合に使います。
詳しい話は更に↓で。
0827デフォルトの名無しさん2005/09/15(木) 23:17:08
null
0828デフォルトの名無しさん2005/09/15(木) 23:17:09
つーか、Chain Of Responsibilityで成功（？）した時に
値を返したい時ってどうすればいいの？
0829デフォルトの名無しさん2005/09/15(木) 23:32:25
Escape from Responsibility
0830デフォルトの名無しさん2005/09/15(木) 23:48:06
>828
というよりも、自分で処理できない時に、return中で委譲する関数を
呼出す（＝委譲する関数の返す値を返す）のが肝だと思うけど。

C++でも継続を扱えりゃあなぁ……
0831デフォルトの名無しさん2005/09/15(木) 23:53:42
>>830
つ[longjump]
0832デフォルトの名無しさん2005/09/16(金) 00:03:14
>>828
Commonsの実装ではChainに登録するCommandのインターフェイスは
こう定義されてる。

public interface Command {
　public boolean execute(Context context) throws Exception;
}

だから、Command間で共有したい値から、最後のCommandを実行した
後の返り値まで、全部Contextで盥(たらいってこんな字なの？初めて
知った（ ﾟдﾟ）ﾎﾟｶｰﾝ)回す。
成功と同時に以降のCommand実行を省略したいなら、executeメソッド
の返り値にtrueを投げてやればいい。
てか、教科書的な実装なんで、別にCommonsだからってわけでもないな。
0833デフォルトの名無しさん2005/09/16(金) 04:07:45
>>830
>>832
成功したかしないかはture/falseで判断させて
それを最後まで返したい場合はバケツリレーでreturnしまくる
ということでしょうか？
他に返したいデータはContextの中に入れてやるのかな？
0834デフォルトの名無しさん2005/09/16(金) 13:01:21
>>833
質問の主旨をイマイチ読み切れてないんだが、多分違う。
Commandが返すbooleanはChainに対するフラグでしかない。Chainの呼び出し元に何らかの
値を返したければ、それらは全てContextを用いて返す。Commandの実行が成功したか否か
で処理を変えたければ、Commandの代わりにFilterを使う。

public interface Filter extends Command {
　boolean postprocess(Context context, Exception exception);
}

Filter#postprocessは全てのFilter#executeが実行された後、その逆順で呼び出される。
同メソッドの引数Exceptionには、Filter#executeで発生した例外がセットされ、返値boolean
にはその例外を同メソッド内で処理したか否かをセットする。
引数Exceptionに例外オブジェクトがセットされており、返値booleanがfalseの時、Chainは
自身の呼び出し元へFilter#postprocessの引数Exceptionをスルーする。

http://cvs.apache.org/builds/jakarta-commons/nightly/commons-chain/
ここにソースがあるから、これ読んでみて。テストも付いてるから、テストケースを書いてみ
る方が楽かな？
まぁ、Commonsの場合はソース読む方が手っ取り早いよな。なにせCommonsだからねｗ
0835デフォルトの名無しさん2005/09/16(金) 23:01:22
ﾉｰﾀﾘﾝ >>789はまた煽り逃げか。
つくづく情け無い奴だな。
18年前にそれやってた先生も「もう過去の仕事です」だって（ぷぷぷ
0836デフォルトの名無しさん2005/09/16(金) 23:11:10
もしかして、>>719を召喚してる？
途中参加だから、内容はよく知らんけどｗ
>>719-720は何度読み返しても歴史に残るキモさだなｗ
0837デフォルトの名無しさん2005/09/16(金) 23:14:57
おまえらｿﾝﾅにｷﾓｽｷﾓﾇ言って首つったらどうするんだよ！！

まぁ、別に構わないけど。
0838デフォルトの名無しさん2005/09/16(金) 23:31:57
下手な煽りだな。。。
そんなまずそうなエサに食いつくやついんのか？
0839デフォルトの名無しさん2005/09/16(金) 23:33:11
>>837
俺も構わないぜｗ
0840デフォルトの名無しさん2005/09/17(土) 07:49:37
>>834
＞Commandが返すbooleanはChainに対するフラグでしかない。Chainの呼び出し元に何らかの
＞値を返したければ、それらは全てContextを用いて返す。

ここまでは良く分かりました。

＞Commandの実行が成功したか否か
＞で処理を変えたければ、Commandの代わりにFilterを使う。

Commandの実行が成功したか否かで処理を変えたいというよりも
どこかのCommandで発生した例外をChainの呼び出し元でキャッチしたいだけです。

Commandの実行が成功しなくてまだ次のCommandがある場合
→次のコマンドを実行、例外が発生してたらスルー

Commandの実行が成功しなくてChainが終了した場合
→例外を発生させる。

という感じのバケツリレーなのですがこんな感じじゃだめですかね？
08418402005/09/17(土) 07:53:05
すいません。>>840を一部訂正します。

×
Commandの実行が成功したか否かで処理を変えたいというよりも
どこかのCommandで発生した例外をChainの呼び出し元でキャッチしたいだけです。

○
Commandの実行が成功したか否かで処理を変えたいというよりも
Commandの実行が成功しなくてChainが終了した場合に発生した例外を
Chainの呼び出し元でキャッチしたいだけです。
0842デフォルトの名無しさん2005/09/17(土) 09:13:03
bool の true, false じゃなくて、独自の列挙型を定義して TRUE, FALSE, ERROR を使えばいいじゃない
0843デフォルトの名無しさん2005/09/17(土) 09:53:13
>>842
デザパタと関係ないけど、個人的にはboolの方がいいと思う。
ただ、ＭＳみたいにfalseのときはクラスのメンバ関数から直前のエラーの詳細を取得できるようにしたらどうだろうか？
0844デフォルトの名無しさん2005/09/17(土) 10:15:50
まだ朝だね。もしかして仕事中？とりあえず、おはよｗ

>>841
Filter#postprocessでfalseを返せばChainがその例外をスローしてくれるから
呼出元でこれをキャッチすればいい。

もう少し詳しく説明すると、Filter1→Filter2→Filter3→Filter4とあったとする。
Filter3#executeでホゲ例外が発生すると、以降のFilter#executeは実行をキ
ャンセルされ、Filter3#postprocessへと処理が移る。
ここで、Filter3#postprocessからreturn false;すると、ChainはFilter2→Filter1
のpostprocessを実行した後で、ホゲ例外を再スローする。

とりあえず、こんな感じだけど、上手く説明できてるかなorz
0845デフォルトの名無しさん2005/09/17(土) 10:47:10
とりあえず流れを読みました
一番感動したのは『バケツリレー』という表現
あ〜そういう言い方すればよかったのねという気持ちになりました
0846デフォルトの名無しさん2005/09/17(土) 10:52:37
GoFの話題ばっかで、つまんねえスレだな。
とても21世紀に書かれたスレとは思えない
0847デフォルトの名無しさん2005/09/17(土) 11:05:48
じゃあ、比較的最近の話題。
Rafactoring to Patterns の翻訳が出ているぞ。
とっとと読め。

『パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法』
ttp://www.amazon.co.jp/exec/obidos/ASIN/4822282384
0848デフォルトの名無しさん2005/09/17(土) 11:16:31
>>846
お前はこのスレに何をしに来たのかとｗ
0849デフォルトの名無しさん2005/09/19(月) 00:55:17
パターンそのものが重複と言われてちょっと目が覚めた気がしました。
パターンが蔓延るのはJavaがまだ駄目な証か。皮肉ですな
0850デフォルトの名無しさん2005/09/19(月) 01:06:17
＞パターンが蔓延るのはJavaがまだ駄目な証

パターンが要らないパラダイムってなんだろう
そういや goto 乱立時代にもパターンは要らなかったんだろうね
0851デフォルトの名無しさん2005/09/19(月) 01:31:46
Javaのコード書いててTemplateとかBridgeとかなるべく処理を正規化してるつもりでも
毎回似たようなコードを書いてる気になるのは己の技術不足なんだろうけど、
でもそれだけじゃなく、言語の性質もなんだろうなと。
たとえばCommandやCompositeなんかはFunctor使えば
スケルトンのような定型コードを書かなくても済むけど、もともと言語としての機能ではないから
なんだか大げさ感があるし、FactoryもDIコンテナがないときの苦肉な策みたいな。
膨大なライブラリとかEclipseなどのツールに助けられてなんとかなってるけどやっぱりJava不便だなって感じる
0852ﾉｰﾀﾘﾝ>>789へ2005/09/19(月) 08:32:33
ﾉｰﾀﾘﾝ >>789はまた煽り逃げか。
つくづく情け無い奴だな。
18年前にそれやってた先生も「もう過去の仕事です」だって（ぷぷぷ
0853デフォルトの名無しさん2005/09/19(月) 09:17:55
>>852
鏡見ろ
0854デフォルトの名無しさん2005/09/19(月) 09:36:01
>>851
>なんだか大げさ感があるし、FactoryもDIコンテナがないときの苦肉な策みたいな。

つうか、何をどう DI するかって問題でないの。
DI は Factory を無くすわけじゃなくて、隠蔽するだけだし。
0855デフォルトの名無しさん2005/09/19(月) 10:18:04
>>851
DIコンテナとFactoryは大袈裟さが違う。
・前提 ： ソースコードを単純に保つ事は、可能性のうちの一つでしかない特定の
　　　　　 拡張より優先する。

ＡとＢを処理するメソッドがあったとして
public search(target) {
　if (target = A) { //処理 } elseif (target = B) {//処理}
}
ふむ、targetの増加に対する修正と、target毎の処理に対する修正が混在してる
ね。では、抽出しよう。処理を共通化できるか？多分、否だろうね。では、処理の
方を抽出しよう。
private void Aproc() {//処理}
private void Bproc() {//処理}
これで修正に対する混在は回避できた。テストも問題なく通るだろうね。なにせ
殆ど変えてないんだからｗ ここで一旦終了。また会う日まで('A`)/~

これでいいわけだよ。ここでFactoryを書くんじゃない！と、ましてやDIコンテナ？
頭おかしいんじゃねぇの？無駄に複雑化するな。その時が来たら書け。そして
＊今は＊その時じゃない。
0856デフォルトの名無しさん2005/09/19(月) 10:38:56
>>855
>DIコンテナとFactoryは大袈裟さが違う。
〜
>これでいいわけだよ。ここでFactoryを書くんじゃない！と、ましてやDIコンテナ？

なんか何がいいたいのかよくわからん。
「Factory なんか使わなくても DI でいいじゃん」じゃなくて、
「Factory も DI もいらないじゃん」といってるのか？

0857デフォルトの名無しさん2005/09/19(月) 11:20:36
>>856
必要な時に使う。必要もないのに使うなってこと。
例えば>>855の場合、ターゲットが一つ追加されるだけなら、if文を追加するの
が最も簡素で最も早い解決法になる。
Factoryの導入を考えるのは、ターゲットに対するディスパッチが複雑になって
きたとか、ターゲットに対する処理が複雑になってきたとか、その段階に入って
からでいい。
DIコンテナの導入を考えるのは、対象とするターゲットの変化(種類や数)がよ
めない時。Factoryで済むなら済ませとけばいい。
0858デフォルトの名無しさん2005/09/19(月) 11:21:27
>>855
>public search(target) {
>　if (target = A) { //処理 } elseif (target = B) {//処理}
>}

>private void Aproc() {//処理}
>private void Bproc() {//処理}

これって、search() が、
　if (target = A) { Aproc(): } elseif (target = B) { Bproc(); }
に変わるだけなんでないの。

ちなみにこれを「オブジェクト指向」で書きなおすと。
publoc abstract Target { public abstract void search(); }
public class A extends Target { public void search() { // 処理 } }
public class B extends Target { public void search() { // 処理 } }

呼び出し元では例えば

Target target;
if ( Aが選ばれる条件 ) { target = new A() } else if ( Bが選ばれる条件 ){ target = new B() }; // (1)
target.search();

となる。
このやり方のメリットってのはオブジェクト指向を理解している奴には説明する必要ないよな？
一つの例を挙げるなら、search()　を使うたびに if を書かなきゃなんないか、
書かなくていいかの違い。


08597892005/09/19(月) 11:21:54
あはは

よっぽどなにか敏感なとこに触れちゃったみたいだなー
どれが触れたんだろう（多分IQなんだろうな　「空回り」かもしれない　「周りは大変」かな）
そうやってるうちに支配されてしまうよ　君には無理無理
0860デフォルトの名無しさん2005/09/19(月) 11:24:04
>855の言わんとしている事はわかるが、
>851へのレスとしてはどうかと思う。

>851がどんな処理をコーディングしようとしてるのか具体的にしていないのに、
何で「＊今は＊その時じゃない」なんて言えるんだ？
本当に必要かもしれないじゃないか。
0861デフォルトの名無しさん2005/09/19(月) 11:27:58
>>857
>必要な時に使う。必要もないのに使うなってこと。
>例えば>>855の場合、ターゲットが一つ追加されるだけなら、if文を追加するの
>が最も簡素で最も早い解決法になる。

まあ、 search() の呼び出しが、全体で一箇所だけとかなら、
それでいいんじゃないの。
つまり、 Factory や DI　は「そうじゃない場合」の解決策ということだ。

>Factoryの導入を考えるのは、ターゲットに対するディスパッチが複雑になって
まあ、最初からある程度複雑になることが予期される場合は、
その時点では必要なくても最初から Factory にしたりするけど。

>DIコンテナの導入を考えるのは、対象とするターゲットの変化(種類や数)がよ
>めない時。Factoryで済むなら済ませとけばいい。
それもそのとおり。
でも、それって、
>なんだか大げさ感があるし、FactoryもDIコンテナがないときの苦肉な策みたいな。
といってることが逆じゃん。
0862デフォルトの名無しさん2005/09/19(月) 11:48:33
>>858
例が悪かったのは謝るが、そこを弄っては話が変ってしまう。
>public search(target) {
>　if (target = A) { //処理 } elseif (target = B) {//処理}
>}
　　　　　↓変化
>if (target = A) { Aproc(): } elseif (target = B) { Bproc(); }
この例は、(targetに対する)ディスパッチと、(targetに対する)処理がメソッド内に
混在してる状態から、最も単純なリファクタリングを用いて分離するという事をリ
ファクタリングという言葉を使わずに表現したかった。

んで、ここから本題。
分離する為に処理側をメソッドにした。更に複雑化すればクラスになるだろう。
ディスッパチ側でも同じ事が起こる。そして、ディスパッチ側がクラスへと抽出さ
れた形がFactoryなわけ。だから、Factoryの導入はその段階に至ってから考え
ればいい！と、こういうシナリオだったんだが・・・・・・
0863デフォルトの名無しさん2005/09/19(月) 11:50:41
>>861
？851と俺(857)は別人だぞ？
俺は、FactoryはDIコンテナがない時の苦肉の策じゃないよと言ってる。
0864856,858,8612005/09/19(月) 12:01:33
>>862
>>863
　 i. ﾞ､ iヽ　　　　　　　　　　／　 /　　/　ヽ　　　　　　　　　　　　│
.　 ｌヽﾐ ゝ`‐､_　　　＿_,. ‐´　 ／　 ,.ｲ　　 ＼　ヽ　　　 　 　 　 　 |
　　`‐､ヽ.ゝ、_　　　　＿,,.. ‐'´　 ／/l , ‐'´, ‐'`‐､＼　　　　　　　 |
　　ヽ､.三 ﾐﾆ､＿ ＿＿＿ _,. ‐'´／/-─==＝＝=-､ヾ 　 　 　 ／ヽ
　　　　　　　 ,.‐'´　`''‐- ､._ヽ 　 /.i　∠,. -─;==:- ､ゝ‐;----//　ヾ.､
　　　　　　　[　|､!　 /'￣r'bゝ}二. {`´ '´＿_ （_Y_）,. |.r-'‐┬‐l l⌒　| }
　　　　　　　 ﾞl |｀}　..:ヽ--ﾞ‐´ﾘ￣ヽd､　''''　 ￣￣　 |l　　　!ﾆ! !⌒ //
.　　　　　　 　 i.! l .:::::　　 　 ｿ;;:..　 ヽ､._　　　　　_,ノ'　　　　　ゞ）ノ./
　　　　　　　　 ｀ ｰ＝=--‐'´(__,. 　 ..、　￣￣￣　　　　　　i／‐'／
　　　　　　　　　 i　　　　 　 .:::ﾄ､ ￣ ´　　　　　　　　　　　 l､_／::|
　　　　　　　　　　!　　　　　　　　　　 　 　 　 　 　 　 　 　 |:　 　 |
　　　　 　 　 　 　 ヽ　　　　　ｰ‐==:ﾆﾆﾆ⊃　　　　　 　 　 !::　　　ト､
　　　　　　　　　　　 ヽ　　　　　､＿＿,,.. 　 　 　 　 　 　 /:;;:　　　.!; ＼
　　　　　　　　　　　　 ヽ　　　　　 ::::::::::: 　 　 　 　 　 ／:::;;::　　／　　
　　　どうやら俺はとんでもない思い違いをしていたようだ・・・ごめん。
0865デフォルトの名無しさん2005/09/19(月) 13:11:23
レベル低いなここ
0866デフォルトの名無しさん2005/09/19(月) 14:20:36
では、レベルの高い話をお願いします。
0867デフォルトの名無しさん2005/09/19(月) 14:50:17
ザクとは違うのだザクとは
0868デフォルトの名無しさん2005/09/19(月) 14:59:45
足なんて飾りじゃないのよ涙は
0869デフォルトの名無しさん2005/09/19(月) 15:44:05
ハッハー
0870デフォルトの名無しさん2005/09/19(月) 15:45:30
>>866
>>719-720
0871デフォルトの名無しさん2005/09/19(月) 16:09:18
>>870
それはレベル高い話じゃなくて
キモイ会話
0872デフォルトの名無しさん2005/09/19(月) 16:14:24
ttp://blog.nikkeibp.co.jp/itpro/java/archives/2005/08/lldnjava.html
これをみて思ったけど、Javaに求められてるのって言語としての合理性じゃなく
大人数の開発に耐えうる平易性なんだろうな。
ただ、Pugsの例みたいに大人数の凡人＋平易な言語に
少数の天才＋合理的な言語が圧倒的に勝ってしまう例をみると
我々凡人についても平易な言語を使うパターンを学ぶよりも合理的な言語を天才が使うパターンを
学ぶほうがより有益なんじゃないだろうかと思う。

ttp://www.cmagazine.jp/bookreview/19990203.html
ここに
「関数型(入出力駆動型)の手法を使っていけば，
必然的にデザインパターンにたどり着くとまで書いてある。」
ってあるんだけど、これを
関数型 ≒ Java＋デザインパターン
と強引に解釈すれば
デザインパターンなんていってないで関数型使えばいいじゃんってなる。
0873デフォルトの名無しさん2005/09/19(月) 16:15:06
>>871
だから、キモさのレベルが半端無いだろｗ
0874デフォルトの名無しさん2005/09/19(月) 16:20:13
>>872
君の話を受けて言いたいのだが
（君に向けて言う訳ではない）

デザインパターンとオブジェクト指向は関係ない
デザインパターン適用可能な言語はオブジェクト指向である必要はない

通常、デザインパターン以前にイディオムという言葉を思い浮かべる


0875デフォルトの名無しさん2005/09/19(月) 16:21:03
>>872
上のリンク先、キモイ文章だな。
そもそも、考え方の根本に大きな間違いがある。
天才級のプログラマなんて想定するだけ無駄だってことも
理解できてないライターは死んどけって感じ。
0876デフォルトの名無しさん2005/09/19(月) 17:30:54
>>875
872じゃ無いけどキモイか？

>大規模企業システムを作るさい，少数派のハッカーしか使いこなせない言語は適用できません。

と書いてあるし、天才を想定してるっていってもPugsなどの*実*例*から、

>天才級のプログラマが自分でプログラムを作る場合，
>関数型言語のような言語システムを使った方が高い生産性を発揮するということはありそうです。

って書いてあるだけじゃないか。
そんなに偏った内容では無いと思うんだけど？
0877デフォルトの名無しさん2005/09/19(月) 18:27:15
>>876
文章よめねぇのかお前。
普通にキモイだろ。
そのページの９５％が誰かの称賛で占められてんだぞ。
さらに言語に特徴なんていらないだろ。
実作業において、オブジェクト指向型か関数型かの違いより大きな違いなんて絶対に無いんだから。
で、それぞれの派生言語作った程度のアホを天才と称して祭りあげてる姿はもうキモイとしか表現のしようがない。
0878デフォルトの名無しさん2005/09/19(月) 19:02:28
基本的にLLDN(Lightweight Language Day and Night)に関するレポートでしょ。
何かを大げさに褒め称えているとも感じなかったよ。

そもそも、誰かを称賛することが何故キモイことなんだ？
0879デフォルトの名無しさん2005/09/19(月) 19:07:36
>>872のリンクが誰かを賞賛しているかどうかはともかくとして、天才って大抵は賞賛に値するけどな。
0880デフォルトの名無しさん2005/09/19(月) 19:10:49
俺も読んでみたが、なんだか、生理的にｷﾓｲと感じた。幼いというか…
0881デフォルトの名無しさん2005/09/19(月) 19:15:43
俺もキモく感じたが、それ以上に>>877の思考回路がキモいと思った
0882デフォルトの名無しさん2005/09/19(月) 19:18:32
>>878
じゃあ、実用化不可能な言語作った奴に堂々と「死ね」って言えるような記事書くようにいっとけ。
0883デフォルトの名無しさん2005/09/19(月) 20:19:37
凡人な私は関数型言語を仕事で使ったことないし、これからも関数型言語を使う仕事が発生するとも思えません。

しかし、HaskellによるPerl6実装であるPugsなどの事例を考えると、多くの人にとって実用的でないからといって
言語としての存在意義がゼロということではないのだなぁと思いました。
0884デフォルトの名無しさん2005/09/19(月) 20:22:33
>>882
> じゃあ、実用化不可能な言語作った奴に堂々と「死ね」って言えるような記事書くようにいっとけ。

本当にこんな記事書いたら間違いなくクビだよね・・・
0885デフォルトの名無しさん2005/09/19(月) 21:05:54
>>884
だからってマンセーばっかりでいいと思っているのか？
http://amanoudume.s41.xrea.com/cgi-bin/mt/archives/000415.html
俺はね。この人がいうように

「誰もが素直に感じたこと」をかけないメディア、そんなものは誰も信じない

ってのは正しいと思うよ。
正直、色々と派生言語とか派生パターンみたいの作って
業界食い荒らしてるのがいるみたいだけどいい加減に誰かが

「この嘘吐き！前にお前が提唱した方法論なんて全く流行らないで終わったじゃ無いか！？
一体この責任をどうとるつもりなんだ！」

こういうこと↑をいっていかないと、誰も見向きもしなくなると思うよ。
現にほとんどの開発者がこういう話題はもはやスルーが常識とまでなってるし。
0886デフォルトの名無しさん2005/09/19(月) 21:19:05
>>885
>「この嘘吐き！前にお前が提唱した方法論なんて全く流行らないで終わったじゃ無いか！？
>一体この責任をどうとるつもりなんだ！」

もし、言語や開発手法がマジョリティーを得なければ、その開発者が責任を負わされるのが当然の世の中になったなら、
新しい言語・開発手法は生まれてこないでしょうね。
0887デフォルトの名無しさん2005/09/19(月) 21:25:25
>>886
しかし、世に出た言語や方法論のほとんどが実際はゴミ。
発案者にもある程度の責任を付加できればいいのだが。
今のこの状態は酷いな。
ほとんど糞の垂れ流しだ。
0888デフォルトの名無しさん2005/09/19(月) 21:54:10
うん、関数型言語は最強だね。最強。
0889デフォルトの名無しさん2005/09/19(月) 21:58:02
またOO == OOP で議論してるの？
0890デフォルトの名無しさん2005/09/19(月) 22:43:36
>>885
上のライターさんの文章が素直に思ったことを書いてないといえるのか？
流行る方法論、言語が優れているとでも思ってるのか？
例えばJavaが流行ってるのは言語のポテンシャル以上に企業のﾊﾞｯｸｱｯﾌﾟが大きいのでは？
開発者に責任を負えっていうの的外れだし。

> 世に出た言語や方法論のほとんどが実際はゴミ。
たとえばどういうのがゴミで、なにがゴミじゃなかったの？
0891デフォルトの名無しさん2005/09/19(月) 23:08:39
>>890
そうやって逃げる分には何でもいいわけできちゃうんだよね。
確かに提唱した方法論を提唱者に責任をとれとは言えないな、現状じゃ。
でも、それを逆手にとってあまりにも糞ばっかり出すぎ。
それのおかげでみんなこういう開発方法論に目も向けなくなっちゃった。
一部の奴等が業界食い散らかして、糞ばかりにしてしまった現実だけがある。
この事実が無いと言える人間は少数だろう。
0892891続き2005/09/19(月) 23:17:33
このスレでもマンセー記事ばっかりはリンクに貼る奴がいるが、批判の類のリンクは一切貼らない。
デザパタをマンセーする奴ってのは一律でこういう奴が多い。
また、批判記事を見つけることの方が大変だ。
俺はこういうつり合いの取れない方法論ってのはほぼ死んでると見ている。
0893デフォルトの名無しさん2005/09/20(火) 00:14:00
> このスレでもマンセー記事ばっかりはリンクに貼る奴がいるが、批判の類のリンクは一切貼らない。

批判の類のリンクがあれば貼ってくれていいよ。
個人的にはデザインパターン使って開発してるけど、別に義理で使ってるわけじゃない。
より短期間で開発できる手法、より再利用性に優れた手法などがあればそれを使いたい。
0894デフォルトの名無しさん2005/09/20(火) 00:40:58
>>893
ちゃんと最後まで読もうよ。
批判記事が全く無いこと自体おかしいでしょ？
って話だよ。
0895デフォルトの名無しさん2005/09/20(火) 01:01:31
>>893
関数型
0896デフォルトの名無しさん2005/09/20(火) 01:17:33
>>894
>批判記事が全く無いこと自体おかしいでしょ？
>って話だよ。

へ？

>>892
>また、批判記事を見つけることの方が大変だ。

って探すのが大変なだけで、あることにはあるという意味じゃ無かったのか・・・

>>895
うーん言語を変えろといってるのか・・・
それはちょっとドラスティックすぎてすぐには採用できないな。
0897デフォルトの名無しさん2005/09/20(火) 01:49:23
>>896
結局、こういう逸らし方をするから、
ただのキモイ集団になっちゃってるってのがまるでわかってないね。
そうやっていつまでも小さい世界に閉じこもってればいいんじゃない？
正直、ソフトウェアの開発手法なんかじゃ、いまどき飯なんて食っていけないからどうでもいいけどさｗ
0898デフォルトの名無しさん2005/09/20(火) 02:12:57
そらす？ああ
>批判記事が全く無いこと自体おかしいでしょ？
に答えろって言ってのね。

技術系の世界だと、「○○は××より劣っている」的な文書はあるけど、
「○○はダメだ」で終わっちゃう文書ってあんまり無いんじゃない？

無理にデザインパターン（別にデザインパターンに限ったことではないけど）を叩かなくても、
より優れた手法が出てくればデザインパターンを用いた開発方法は自然に淘汰されるでしょ。
0899デフォルトの名無しさん2005/09/20(火) 02:19:59
>>898
だから淘汰されないデザパタは絶対に正しい方へ向っているとでも？
0900デフォルトの名無しさん2005/09/20(火) 02:21:18
つーか、もう、更新は止まってるかｗ
0901デフォルトの名無しさん2005/09/20(火) 02:37:54
（より優れた）代替案が無ければ、現行の手法を採択するってのはそれほど奇異ではないと思うけど？
0902デフォルトの名無しさん2005/09/20(火) 02:41:40
>>901
つか、デザパタでしか組めないの？
0903デフォルトの名無しさん2005/09/20(火) 02:43:31
>>902
何故そういう極論に走る？
0904デフォルトの名無しさん2005/09/20(火) 02:43:41
>>901
デザパタ使わないで普通に組んだら？
ってか、アホだから普通ってわからないでしょ？
デザパタが絶対正しいと妄信してるから。
0905デフォルトの名無しさん2005/09/20(火) 02:44:19
>>903
極論じゃないでしょ。
まず、デザパタを使う、使わないって選択肢があるんだから。
0906デフォルトの名無しさん2005/09/20(火) 02:46:27
開発がデザインパターンだけで済むんだったら楽だろうけど、
実際にはクラスの設計の際に参考にする程度だよ。
「なにが何でも○○パターンを使うんだ！」とかそういうことじゃない。
0907デフォルトの名無しさん2005/09/20(火) 02:49:23
>>906
あ、そう、もう、いいや。
なんか今日食い付き悪いし。
もう、今後レスつけたらすべて君の言うとおりでいいよ。
0908デフォルトの名無しさん2005/09/20(火) 02:52:31
>>907みたいな香具師は議論する資格ないぜ…
0909デフォルトの名無しさん2005/09/20(火) 02:53:56
>>908
ゴメン・・・ホントは>>719-720を友だちにみせたかったんだ・・・
0910デフォルトの名無しさん2005/09/20(火) 04:29:04
暇つぶし煽り厨また来てんのか。どっか行ってくんねーかな。
0911デフォルトの名無しさん2005/09/20(火) 04:33:10
>>907
キャッチアンドリリースかよｗ
0912デフォルトの名無しさん2005/09/20(火) 09:32:47
今までデザパタってのは
「こういう機能を実現するにはどのような設計にすればいいんだろう」
　→カタログに載っているこのパターンを使おう
という手法全般のことだと思っていたけど違うんですか？

なんかここ読んでると「デザパタでしか組めない」とか謎なことを言ってる人がいるし。

>>906
>　開発がデザインパターンだけで済むんだったら楽だろうけど、
>　実際にはクラスの設計の際に参考にする程度だよ。
>　「なにが何でも○○パターンを使うんだ！」とかそういうことじゃない。
というか、それがデザインパターンのまっとうな使い方じゃないの？
それとも世の中には「カタログに載ってるパターンのみ使って設計する」という定義の「デザインパターン」なるものが存在するんですか？
0913デフォルトの名無しさん2005/09/20(火) 09:36:47
>>906
yes。また、クラス設計したあとで
「ああこれは○○パターンに似ているな」と気が付く場合もあったりｗ
0914デフォルトの名無しさん2005/09/20(火) 19:14:27
OOPで必要に応じてオブジェクトを生成することをなんていいましたっけ
RAAだかROAAだかそんな感じの用語だったと思うのですが
0915デフォルトの名無しさん2005/09/20(火) 19:24:06
>>859
> そうやってるうちに支配されてしまうよ　君には無理無理

強烈なデムパが発生しました

つか、>>910　正解。
とにかく見当違いにレベルの低い発言はスルーしる。
例えば「食い付き」「友だち」あたりのキーワードをNGワードに入れとけば、
ずいぶんまともなスレになる。
0916デフォルトの名無しさん2005/09/20(火) 19:25:27
RAA + Object で検索すると Ruby Application Archive しか出てこないな

>>914
GoF のパターンの中だと、必要になるまでインスタンス生成を遅らせるのは Proxy パターン
それともちがうか？
0917デフォルトの名無しさん2005/09/20(火) 20:39:24
ストラテジーパターンってポリモフィズムそのままですよね？
0918デフォルトの名無しさん2005/09/20(火) 20:48:32
もちろんそのままだよ。ポリモフィズムを 「アルゴリズムを切り替えるため」 に使用した例だ
0919デフォルトの名無しさん2005/09/20(火) 20:54:47
紛らわしいからポリモフィズムって言うなよ。
OOPの中じゃあ継承によるオーバーライドのことだけを指すのが一般的じゃまいか。
09209182005/09/20(火) 21:12:43
失礼失礼。Inclusion ポリモーフィズムか Runtime ポリモーフィズムなら分かるでしょうか
0921デフォルトの名無しさん2005/09/20(火) 23:49:01
RIAAじゃね？
0922デフォルトの名無しさん2005/09/20(火) 23:53:49
RIAA でぐぐっても米国レコード工業会しかでてこない…… orz
0923デフォルトの名無しさん2005/09/20(火) 23:56:19
RAIIじゃなくて？
0924デフォルトの名無しさん2005/09/21(水) 04:51:07
このスレのレベルが分かる展開で笑えてきた。
0925デフォルトの名無しさん2005/09/21(水) 21:57:03
いやRAIIでFAだろ
0926デフォルトの名無しさん2005/10/08(土) 17:10:47
Boost.Interfaces最高だよね？
0927デフォルトの名無しさん2005/10/13(木) 23:57:00
シングルトンでクラスを実装しようとしています。
環境はWinXP + VC++2003です。
以下のようにプログラムを作成したところ、未解決の外部シンボル、というエラーが出ます。

＜hoge.h＞
class hoge{
public:
　virtual ~Hoge();
　static Hoge* GetInstance();
private:
　Hoge();
　static Hoge* m_pInstance;
　Hoge(Hoge& dummy);
　Hoge& operator=(Hoge& dummy);
};

＜Hoge.cpp＞
Hoge* Hoge:GetInstance(){
　if(m_pInstance == NULL){
　　m_pInstance = new Hoge();
　}
　return m_pInstance;
}
Hoge::~Hoge(){
　if(m_pInstance != NULL){
　　delete m_pInstance;
　　m_pInstance = NULL;
　}
}

なんか単純な間違いを犯してるような気がするのですが・・・識者の方、よろしくお願いします。
0928デフォルトの名無しさん2005/10/14(金) 00:11:53
ｈoge.cppの最初に、

Hoge* Hoge::m_pInstance = 0;

が無いからとか。
09299272005/10/14(金) 00:20:07
ありがとうございます。
指摘の通り、追加してみたところ、エラーが1個減りました。

しかし、まだ「未解決の外部シンボル "private: __thiscall Hoge::Hoge(void)" (??0Hoge@@AAE@XZ) が関数 "public: static class Hoge * __cdecl Hoge::GetInstance(void)" (?GetInstance@Hoge@@SAPAV1@XZ) で参照されました。」というエラーが残っています。
この原因は分かりますか？
0930デフォルトの名無しさん2005/10/14(金) 00:24:14
コンストラクタの実体がないから。
0931デフォルトの名無しさん2005/10/14(金) 00:59:18
大人しくLoki::SingletonHolderでも使っとけ
0932デフォルトの名無しさん2005/10/14(金) 01:27:55
デフォルト・コンストラクタがないね（・∀・）
0933デフォルトの名無しさん2005/10/14(金) 03:03:30
ちなみに


＜Hoge.cpp＞
Hoge& Hoge:GetInstance(){
　　static Hoge m_pInstance;
　　return m_pInstance;
}
の方がスマートらしい
0934デフォルトの名無しさん2005/10/14(金) 03:34:16
そうかそうか、よーくわかったぞ。
0935デフォルトの名無しさん2005/10/14(金) 10:17:31
>>933
これって、クラスで唯一のインスタンスになってくれるの？

ってなってくれそうだね。
確かにスマートだ。
0936デフォルトの名無しさん2005/10/14(金) 11:35:47
>>927
ってデストラクタ内のdeleteでデストラクタが呼ばれて愉快なことにならないか?

0937デフォルトの名無しさん2005/10/14(金) 12:19:48
思いっきり楽しいことにぬるぽ。
09389272005/10/15(土) 00:22:15
皆様ありがとうございます。解決しました。

>>927さんのいうとおり、確かに愉快なことになってます。
いろいろとWebで調べたら実際にこのようにプログラミングしていました。

実際はどのようにインスタンスを解放したらいいのでしょうか？
0939デフォルトの名無しさん2005/10/15(土) 05:06:55
>>938
PCをリセットしたまえ。
0940デフォルトの名無しさん2005/10/15(土) 09:44:57
これだけ言わせてくれ

　自　分　に　さ　ん　付　け　す　る　な
0941デフォルトの名無しさん2005/10/15(土) 12:42:00
水木しげるみたいだ。
09429272005/10/15(土) 18:58:06
すみません、アンカー間違えました。
よく考えたら、確かにdeleteでさらに同じデストラクタを呼びますが、
if文の判定で回避可能ではないでしょうか。

実際に実行してみると、約50%ぐらいの確率でデバッガ(VisualStudio)がメモリリークを検出します。
再現性に乏しくて大変困るのですが、何が原因かわかりますか？
0943デフォルトの名無しさん2005/10/15(土) 19:46:44
なんていうか、デザパタ以前にC++初歩の問題だな。
0944デフォルトの名無しさん2005/10/15(土) 21:25:58
>>942
if文うんぬんより、デストラクタ→デストラクタ→デストラクタ→・・・
の無限再帰ループでスタックオーバーフローしそうなんだけどどうなんだろ。

まあ、もう既にデザパタの話しでなくなってるので他スレにでもいってら。
0945デフォルトの名無しさん2005/10/15(土) 22:27:33
デザインパターンで画用紙メモリってどんなん？
09469272005/10/15(土) 23:33:10
お騒がせしました。

結局auto_ptrを使用して回避することにしました。
0947デフォルトの名無しさん2005/10/16(日) 00:09:30
auto_ptrを使うことは構わないが、
結局問題の原因がわかってなければまた同じ問題を起こすわけで。
0948デフォルトの名無しさん2005/10/16(日) 00:15:24
なんかもう凄く>>943なのでC++1から勉強し直した方が身のため
0949デフォルトの名無しさん2005/10/18(火) 01:11:22
>927
とりあえずLokiのSingletonで我慢しときなさい。
そういや、BoostのSingletonてどうなったんだろう？
0950デフォルトの名無しさん2005/10/18(火) 10:45:59
(^^;
0951デフォルトの名無しさん2005/10/18(火) 10:47:07










(^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^;

　(^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^;

(^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^; (^^;
0952デフォルトの名無しさん2005/10/18(火) 10:49:39



　　　　　(^-^;) (^ ^;) (^ω^) (^_^;)


0953デフォルトの名無しさん2005/10/18(火) 15:35:38
おでかけレスター
0954デフォルトの名無しさん2005/10/19(水) 20:35:37
れれれのれ（＾＾；
0955デフォルトの名無しさん2005/10/19(水) 23:59:13
「憂鬱本」読んだりして何とかオブジェクト指向については
わかってきた感じ。
でもデザインパターンについてはさっぱりだ。
デザパタの勉強するのにC++よりJavaの方がいいんでしょうか？
GoF見てわからない人は読むべしって本もJavaの本でしたし…
もしかしたらスレ違いかもしれませんが、よかったらアドバイス
お願いします。

元々コボラーな俺だけど、最近はSQLとかC、Perlなんかも少しづつ覚
えてきたよ。もうちょっとPerlは勉強したい。
本当はC++を勉強したい気持ちがあるんだが、デザパタ習得する近道
がJavaにあるならやってみたい。
0956デフォルトの名無しさん2005/10/20(木) 23:58:24
>>955
コボルでやればいいんじゃない？
0957デフォルトの名無しさん2005/10/21(金) 00:20:34
(^ω^) Javaのほうがいいよ (^ω^)
09589552005/10/21(金) 05:22:23
>>956
さすがにCOBOLでデザパタはないですよｗ

>>957
なんとなっくオブジェクト指向にしろデザインパターンにしろC++より
Javaのほうが入りやすいのかなぁと思ってます。
やっぱりJavaで勉強していくほうを検討してみます。ありがとうござい
ました。
0959デフォルトの名無しさん2005/10/21(金) 08:25:04
デザパタがわかるとかデザパタを勉強するとか言う言葉に猛烈な違和感を覚える。
0960デフォルトの名無しさん2005/10/21(金) 12:30:02
>>959　同意
「GoFが××パターンと呼ぶ設計です」
なら違和感はないけどね
0961デフォルトの名無しさん2005/10/22(土) 16:40:04
>>959
たとえばGoFについてはOOPのイディオム的な部分じゃない？
「わかる」・・・その局面に適用する理由がわかる
「勉強する」・・・知識としてしっておく
OOPを習得する近道として違和感のある言葉じゃないと思う
0962デフォルトの名無しさん2005/10/22(土) 18:48:52
>>961
なるほどなるほど。君の言いたい事は、痛いほどわかったぞ。
0963デフォルトの名無しさん 2005/10/23(日) 05:24:44
>>958
Javaの方が良い
C++だと余分な煩雑な言語仕様が多過ぎる
後、継承とインターフェースの分離・違いが解り易い
極端な話、インターフェース中心に考えると、デザパタに帰着する
0964デフォルトの名無しさん2005/10/23(日) 09:51:20
>>963
実装継承できないのが('A`)ﾏﾝﾄﾞｸｾ
実装継承分の委譲コード、コード自動生成してくれるツールでもあればいいのに･･･
0965デフォルトの名無しさん2005/10/23(日) 09:53:34
>964
Eclipseは？
09669552005/10/24(月) 06:12:20
>>956 >>957 >>959-963
アドバイスありがとうございました。
もう少しPerl勉強したらJAVAにやってみようかと思います。
とりあえず、Eclipse入れて@ITにある入門はやってみました。

>>959 >>960
まず、デザパタとはなんぞやってところからわかってないので、おかしな
質問すみませんでした。

コボラーの私ですが、好きでやってるものですから、何とか新しいものに
はなされないようにがんばってみようと思います。

本当にありがとうございました。
0967デフォルトの名無しさん2005/10/28(金) 16:17:01
的外れなことを書いていたらすみません。Factory Methodパターンの質問です。
以下のように生成されるクラスの実行結果によって
次に処理を行うクラスが決定される場合、
（xClass内でxxBean.setNextClassNameメソッドにより次の生成クラスを決定）

while(xxBean.getEndflag){
　　switch(xxBean.getNextClassName()){
　　　　case Aclass:
　　　　　　Aclass a = new Aclass();
　　　　　　a.execute(xxBean);
　　　　　　break;
　　　　case Bclass:
　　　　　　Bclass b = new Bclass();
　　　　　　b.execute(xxBean);
　　　　　　break;
　　　　case Zclass:
　　　　　　Zclass z = new Zclass();
　　　　　　z.execute(xxBean);
　　　　　　xxBean.setEndflag(false);
　　　　　　break;
　　}
}
09689672005/10/28(金) 16:18:24
Factory Methodパターンを適用すると

while(xxBean.getEndflag){
　　switch(xxBean.getNextClassName){
　　　　case Aclass:
　　　　　　Factory aFactory = new Factory();
　　　　　　AProduct aProduct = aFactory.create();
　　　　　　aProduct.execute(xxBean);
　　　　　　break;
　　　　case Bclass:
　　　　　　Factory bFactory = new Factory();
　　　　　　BProduct bProduct = bFactory.create();
　　　　　　bProduct.execute(xxBean);
　　　　　　break;
　　　　case Zclass:
　　　　　　Factory aFactory = new Factory();
　　　　　　ZProduct zProduct = zFactory.create();
　　　　　　zProduct.execute(xxBean);
　　　　　　xxBean.setEndflag(false);
　　　　　　break;
　　}
}
のように、生成されるクラス毎にFACTORYとPRODUCTの実装クラスを
定義する必要があるのでしょうか？なんだかクラスがいっぱいできてメンテナンスが大変そう
なんですがそういうものなんですよね？認識があっているか不安です。
0969デフォルトの名無しさん2005/10/28(金) 18:13:32
これ FactoryMethod つかう必要が無くないか？
09709692005/10/28(金) 18:28:32
うん。っていうか FactoryMethod じゃなくて、むしろ AbstractFactory だなコレは。
AbstractFactory で考えるけど、
　・AProduct, BProduct, CProduct を abstract class Product から継承し、インターフェイスを共通化する
　・↑の製品を作る AFactory, BFactory, CFactory を abstract class Factory から継承し、インターフェイスを共通化する
んでついでに xxBean.getNextClassName() じゃなくて xxBean.getNextFactory() にすると

while(xxBean.getEndflag){
    Factory factory = xxBean.getNextFactory();
    Product product = factory.create();
    product.execute(xxBean);
}

となるので見た目はスッキリ。
しわ寄せがどこかに行くから、ちゃんと使いどころを見定めてな。


ちなみに、生成されるクラスごとに Factory と Product を作らなきゃいけないのは合ってる。
ただ、幾ら作っても Factory と Product の扱い方を知ってるだけで良い、というのが Factory 系パターンの利点。
09719672005/10/28(金) 18:45:48
>>968,>>969さん
どうもありがとうございます。
factoryパターンを適用するとswitch文のネストを使わないで、
オブジェクト指向的に生成するクラスを変化できると聞いてやってみるも、
いまいちメリットが納得できませんでした。さらにclassForNameを追加して、
switch文のネストをなくそうともしてましたが、本末転倒ですね。

AbstractFactoryなんですね・・・。
そして、自分の書いたソースがなんとカッコ悪いこと。
ありがとうございます。
09729672005/10/28(金) 20:01:43
すみません再度質問です。聞いてばかりですみません。

各々xProductの実装クラスの中で、xxBean.setNextFactory(new xFactory());
を実行し、次の実行クラスを設定すると思います。

この際、xxBean.getNextFactoryメソッドの引数となるxFactoryのインスタンスは
動的に設定しようとした場合、リフレクションになってしまうんですよね？

実行速度を求めた場合、xProductは複数存在するのでユーティリティクラスを作成し、
その中でswich文を使用し、xFactoryの種類を判断/インスタンスの返却をするのが良いのかな・・
09739672005/10/28(金) 20:03:12
誤記があったので訂正します。
誤：この際、xxBean.getNextFactoryメソッドの引数となる
正：この際、xxBean.setNextFactoryメソッドの引数となる
0974デフォルトの名無しさん2005/10/28(金) 20:26:21
う〜ん……。Factory 系が良くわかって無い予感。

    public void setNextFactory(Factory f) { }

として setNextFactory を定義。

    public abstract class Factory {
        public abstract Product create();
    }
    public class AFactory extends Factory {
        public Product create() { return new AProduct(); }
    }
    public class BFactory extends Factory {
        public Product create() { return new AProduct(); }
    }
    public class CFactory extends Factory {
        public Product create() { return new AProduct(); }
    }

とやっておけば、setNextFactory する側が

    setNextFactory(new AFactory());
    setNextFactory(new BFactory());
    setNextFactory(new CFactory());

という風に、どの Factory をセットするか選ぶだけで良い。
0975デフォルトの名無しさん2005/10/28(金) 20:31:17
逆に言うと、

    class AFactory extends Factory
    class BFactory extends Factory
    class CFactory extends Factory

    class AProduct extends Product
    class BProduct extends Product
    class CProduct extends Product

と定義 "できない" 場合、
または各インスタンスを Factory と Product として統一的に扱うことが "できない" 場合には
AbstractFactory は "使わないほうが" 良い。


あと、setNextFactory で Factory を入れるくらいなら、最初から Product をセットするべきかもと思った。
0976デフォルトの名無しさん2005/10/28(金) 20:39:36
ごめん。>>974 だと BFactory も CFactory も AProduct 作ってたわ。
09779672005/10/28(金) 20:57:15
>>974,>>975,>>976さん
説明が下手でごめんなさい。

>とやっておけば、setNextFactory する側が
>
> setNextFactory(new AFactory());
> setNextFactory(new BFactory());
> setNextFactory(new CFactory());
>
>という風に、どの Factory をセットするか選ぶだけで良い。

この部分でのどの Factory をセットするかの実装方法について再度
お聞きした感じです。xProductを利用する側はAbstruct Factoryの導入で
インスタンスの生成を動的に行えますが、setNextFactoryも同じように
楽に（switch文ネストで候補をずらずらかかない感じに）できないのかなと思いまして。
0978デフォルトの名無しさん2005/10/28(金) 21:06:04
>>967 の例と比較するけど、プログラム上で行う場合には

setNextClassName("Aclass");
setNextClassName("Bclass");
setNextClassName("Zclass");

setNextFactory(new AFactory());
setNextFactory(new BFactory());
setNextFactory(new ZFactory());

これらに差があるとも思えない。


もし、ユーザ側からクラス名を受け取り、そのインスタンスを作成したいのならば
リフレクションまたは switch 文が確実。
09799672005/10/28(金) 21:28:20
>もし、ユーザ側からクラス名を受け取り、そのインスタンスを作成したいのならば
>リフレクションまたは switch 文が確実。

その言葉、重いです・・・。
setNextClassName("Aclass");
setNextFactory(new AFactory());
に差がないのならば、メンテナンス性を考えると
GOF適用しないほうが良いのかな・・・。悩んできた。
0980デフォルトの名無しさん2005/10/28(金) 22:16:28
いまさらだけど、ハッシュテーブルという便利なものを思い出した。
クラス名を表す文字列をキーに、Factory クラスやら目的クラスのインスタンスを入れておいて、
そこから引っ張り出して使うとか。
0981デフォルトの名無しさん2005/10/29(土) 04:32:41
>>980
DI
レス数が950を超えています。1000を超えると書き込みができなくなります。