07/04/01 09:44:28
>>397
ﾅﾆｺﾚｗｗ
勝手に誤爆にするなよｗｗｗ
>>397-398
おまいウザイから別にスレ立て手やれよ
401:デフォルトの名無しさん
07/04/01 09:52:28
あとそんなに自分の主張に自信があるなら
コテつけてレスしろ
402:デフォルトの名無しさん
07/04/01 10:38:41
>>400-401 またスレ荒しか
403:デフォルトの名無しさん
07/04/01 10:40:13
おまぃはバカなんだから黙っとけ
404:デフォルトの名無しさん
07/04/01 16:38:31
いやさ、例の「精神性疾患の俗称連呼」の人、
別スレで暴れまくっててえらい騒ぎになってるわ。
どうも東京都在住の４４歳の人物らしい。
４４歳にもなって２ちゃん三昧とは幼いね。
405:デフォルトの名無しさん
07/04/01 16:50:51
リアルワールドが悲惨なんだよ、きっと
406:デフォルトの名無しさん
07/04/01 17:02:21
よしよし
407:デフォルトの名無しさん
07/04/01 18:05:17
NGワード推奨：キチガイ
408:デフォルトの名無しさん
07/04/01 19:09:37
某スレで、コーディング能力も設計能力も疑わしい４４歳の人が
「擬似コードを元にした議論はよくねぇ～」とか叫んでて笑えた。
「print文入れて動作を見ればいい」ってそれなんて名前のBASIC言語？ｗ
409:デフォルトの名無しさん
07/04/01 20:54:04
なんと言う春休み。
思わず読み飛ばしてしまった。
このスレはしばらく伸びる。
410:デフォルトの名無しさん
07/04/01 21:05:50
>>409
荒しに来たのなら、帰ってくれ。
411:デフォルトの名無しさん
07/04/04 02:42:25
こっちが平和になったと思ったら
今度はあっちで暴れてたんだな
ｽﾚﾘﾝｸ(tech板)
412:デフォルトの名無しさん
07/04/04 14:16:56
>>407
自分がそれだから、そうやって相手を封じたい訳ね。
ま、相手なんてお前の脳内にしか居ないんだけど（藁
413:デフォルトの名無しさん
07/04/04 14:25:05
誤爆？
414:デフォルトの名無しさん
07/04/05 14:50:04
>>412
おまえが自己の行動に無自覚な精神障害者である事はよくわかった。
415:デフォルトの名無しさん
07/04/06 14:56:12
ここのスレ主はそろそろ鉄格子付き個室病棟の中か。
頭も性格も悪いスレ主に意見すると
ひたすら泥沼に引きずり込もうとあがくから
始末が悪い。
416:デフォルトの名無しさん
07/04/06 15:56:32
スレ主は、ＯＯやデザパタに対して、狂信的な宗教感情を持っている。
その信仰はあまりにも愚かで盲目的であり、
自身の独自解釈とは異なる意見を持つ者に対して
狂信的信者の狂ったな正義感を持って攻撃と排除を試みる。
しかし、世の中に広く受け入れられる技術ノウハウというものは、
そのようなカルト的宗教活動とは一切無縁のものである。
417:デフォルトの名無しさん
07/04/06 16:08:13
個人的な技術ノウハウの蓄積は、
・日々の実践と経験を通じた、メンタルモデルの形成
・合理的思考による、メンタルモデルの検討と洗練
・明確な目的意識に基づく、合目的なノウハウの抽出と洗練
を通じて行われる。
そして世の中に広く受け入れられる技術ノウハウというものは、
個々人のノウハウを、他の専門家を交えた健全な議論に晒し、
目的と手段の合理性を詳細に検討し、
その過程で多くの人々が同意し共感する事を通じて、
初めて成立するものである。
418:デフォルトの名無しさん
07/04/06 16:28:04
注： 誤解のないように注記しておく。
ここでスレ主とは、今回のスレを立てた人物の事ではなく
関連スレのど真ん中に居座り、罵詈雑言を撒き散らしては議論妨害を繰り返す、
牢名主のような人物の事である。
419:デフォルトの名無しさん
07/04/06 19:28:31
GoFってなんて呼べばいいの？
個人的にはゴフって読んでるんだけど、公の場で使ったら笑われたりする？
420:デフォルトの名無しさん
07/04/06 19:37:48
>>419
情報処理用語の読み方を確認するスレ
ｽﾚﾘﾝｸ(tech板:670番)
670 ：デフォルトの名無しさん ：2005/05/16(月) 20:02:16
GOFはともかくGoFはゴフと読んでる。
421:デフォルトの名無しさん
07/04/06 20:33:32
ｺﾞﾌｺﾞﾌ
422:デフォルトの名無しさん
07/04/06 22:39:06
護符としての効能はあるんだろうか？
423:デフォルトの名無しさん
07/04/07 01:00:50
__
i＜´ }＼ , - 、
ヽ.._＼./ .ﾝく r-兮、 ＿_
∠｀ヽ.! / ヾﾆEｦぐ ,ゝ-＞ さすがGoFだ。
/＿｀ｼ'Ｋ-──‐-､l∠ イ ﾃﾞｽﾏくらっても
l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤ 何ともないぜ。
. l'___|⌒ヾ''ｰ＝=､ｰr='ｲ ｉ二|
/ .｣ i /./7r‐く lー!
. ｆ. ヽ‐ｉ人.∠'＜ ＿i. l,.-ゝ.
ﾄiﾍﾍ｢ﾄ〈 ｀X ﾄﾚi7__|
〉ﾄ:ﾄﾊj｀! i. / ﾄｰ┤lﾙj,ﾘ
/‐+----+‐l iｰ--i---ヾ'〃
. ｌ＿i＿＿__i__| |＿__i,＿＿i_|
424:デフォルトの名無しさん
07/04/07 01:57:18
荒らしは帰ってくれ
425:デフォルトの名無しさん
07/04/07 20:59:35
あっちの隔離スレ、すげぇ荒れようだな。
こっちであんまﾍﾀﾚな擬似コード出してくるから
ちょっとからかってやったらすぐキレ出して、
改めて問題点を７レス分ほど指摘しただけで
延々と一週間もこの騒ぎだ。
狂信者って本当に怖いね。
426:デフォルトの名無しさん
07/04/08 00:52:40
ｲﾀｲ････
427:デフォルトの名無しさん
07/04/08 00:56:10
ｽﾚﾘﾝｸ(tech板)
428:デフォルトの名無しさん
07/04/21 09:39:44
State パターンで相談です。各 State クラス間でコンテキストを共有したい
場合に、相互の依存度を下げるにはどういったイディオムが使えますか?
例えば、ウィザード形式のインストーラの画面を State と見なすと、
A 画面で設定した内容を次の B 画面でも使いたいとか、最終的には、
全ての画面で設定した内容をもとに処理を行いたい、など。
Context を各 State のコンストラクタに渡してあげれば目的は達成できる
のですが、各 State が興味があるのは Context の限られた一部分であり、
Context 全体を渡すのは不釣り合いな気がしています。
もう一つの悩みは、Context が受動的な「共有データクラス」の役割を
演じることになるというものです。どうもこの構造がしっくりこない
というか、オブジェクト指向っぽくないと思うのです。
あるいは、こういう場合にはそもそも State パターンは使わないとか、
そういった指摘でもかまいませんので、よろしくお願いします。
429:デフォルトの名無しさん
07/04/21 09:47:55
その前にStateパターンのクラスズをよく見て依存関係を
シッカリ把握しなさい
430:428
07/04/21 10:02:23
>>429
問題にしているのは以下のような依存関係です。
Controller has a State
Controller has a Context
StateA is a State
StateB is a State
431:デフォルトの名無しさん
07/04/21 10:13:33
>>430
私が問題にしているのは
＞各 State が興味があるのは Context の限られた一部分であり
です。
StateはContextに興味はありません。
432:デフォルトの名無しさん
07/04/21 10:26:13
ハッタリ業務コンサルのデザインパターン解釈はダメダメだな
433:デフォルトの名無しさん
07/04/21 10:42:32
まー独自解釈して苦しんでしまう事は初心者にはよくあることだから気にする必要は無いｗ
434:428
07/04/21 10:44:02
>>431
Context という言葉を使ったのがまずかったですね。ごめんなさい。
GoF では Context が State に処理を移譲することになっていたかと
思いますが、ここでは「共有データ」の意味で Context を使ってます。
つまり、Controller が State に処理を移譲していて、各 State は
Context を参照・更新するという構造です。
State が Controller に無関心だと言う点についてはもちろん同意です。
今回の悩みどころは、各 State の「成果物」を共有する時のうまい手段は
ないものか、というものです。
GoF に従うなら、
Context has a State
Context has a SharedData
StateA is a State
StateB is a State
で、StateA や StateB が SharedData を参照更新する、という感じです。
435:デフォルトの名無しさん
07/04/21 10:48:50
ContextがMediatorになるんじゃないの?
436:デフォルトの名無しさん
07/04/21 10:52:17
WebApplicationやStrutsと同じジャマイカ
437:デフォルトの名無しさん
07/04/21 11:07:11
扱うデータの型や処理の型を問題にせずSharedDataでひとくくりにするから
概要設計レベルではContextで解決したつもりになっていても
詳細設計レベルで一気に破綻するんだろ。
ハッタリコンサル(初心者)の典型だな
438:デフォルトの名無しさん
07/04/21 11:12:12
>>435
Mediatorで相互依存性を弱めるというのは正しい方向だが
それをContextと呼び続けるのは病気だ。
今ならDIだろ。
439:デフォルトの名無しさん
07/04/21 11:15:19
いまどき概要設計/詳細設計かよ
440:デフォルトの名無しさん
07/04/21 11:17:17
ハッタリコンサルはメーカ毎の工程名の相違に鈍感
OMGの工程名対応表でも見とけクズ
441:デフォルトの名無しさん
07/04/21 11:22:56
いまどき工程かよｗ
442:デフォルトの名無しさん
07/04/21 11:27:07
ハッタリが話題ずらしに必死だな
上空レベル、海面レベルとでも読み替えておけクズ
443:デフォルトの名無しさん
07/04/21 11:28:25
>>435
> ContextがMediatorになるんじゃないの?
ContextではなくMediatorだろうな、
古臭いデザパタ厨房の妄想に合わせてやれば
444:デフォルトの名無しさん
07/04/21 11:29:48
>>442
そりゃユースケースの話だろｗバーカｗ
445:デフォルトの名無しさん
07/04/21 11:31:11
ハッタリ必死すぎるぞ
カプサイシン摂取過多でそろそろ拳銃乱射事件かｗ
446:デフォルトの名無しさん
07/04/21 11:33:12
ハッタリコンサルの仕事：
奴隷コーダに一画面分のコードを書かせ、
それが複数画面で使いまわせると信じ込んで
詳細設計の雛形にする
447:デフォルトの名無しさん
07/04/21 11:35:53
ハッタリコンサルの仕事２：概要設計
一画面分のコードで、データ類がContextにまとめられているのを見て、
Contextというクラスを作れば複数画面にも対応できるとはずだ
という妄想設計をすること。
448:デフォルトの名無しさん
07/04/21 11:37:09
>>446
お、宗旨替えか？
そうだよSE/コンサルはコーダ以下なんだよｗやっと気づいたか
449:デフォルトの名無しさん
07/04/21 11:44:03
>>448
はぁ？
お前がダメ人間だからといって、
他もダメ扱いすんな。
中小企業のダメコンサルに比べたら
大企業のSEには中にはまともなのが居るよ。
例えば俺。
コーディングもできるし(あたりまえ)、
科学技術にも口出しできるし、
ダメコンサルを叩いて再起不能にする事もできる。
お前を今叩いているようにな
450:デフォルトの名無しさん
07/04/21 11:45:54
ここで叩かれてボロボロになってるハッタリコンサルって、誰なの？
451:デフォルトの名無しさん
07/04/21 11:50:20
＞コーディングもできるし(あたりまえ)
コンプまるだしｗ
452:デフォルトの名無しさん
07/04/21 11:53:19
＞例えば俺。
日中カキコしまくりのヒキコモリが大企業のSE？ｗ
453:デフォルトの名無しさん
07/04/21 11:54:03
>>450
各種情報を総合すると、こいつが本人らしい。
URLﾘﾝｸ(megalodon.jp)ｽﾚﾘﾝｸ(tech板:626番)&date=20070410182152
454:デフォルトの名無しさん
07/04/21 11:56:16
>>453
みっともねぇ～ないい歳こいた親父が
２ちゃんごときで必死になっちゃってｗ
仕事場でオナニー三昧２ちゃん三昧って
それなんていう引き篭もり部屋？
455:428
07/04/21 12:00:16
うーん。Mediator だとクラスの数が増えてしまうので、ちょっとおおげさ
かなという気がします。コストとメリットがバランスしないというか。
問題をうまく処理できることはもちろん大切なんですが、「やり過ぎ」も
避けたいなと。
データ共有型 State パターンは割とありがちなことかと思ったのですが、
検索してもあんまりピンとくるものがないんですよね。まあ、探し方が
悪い気もしますが、どちらかと言うと状態遷移の問題に着目したものが
多かった気がします。
C++ だし参照渡しでお茶を濁そうかなと思ったり。
456:デフォルトの名無しさん
07/04/21 12:06:18
>>454
おめえは気の利いたこといってるつもりなんだと思うけど、
とにかくセンスが無さすぎる
457:デフォルトの名無しさん
07/04/21 12:06:31
妄想に基づく独自解釈をGoogleで探しても、適切な例が出てくるわけない。
StateパターンにおけるContextクラスの役割は約一ヶ月前に書いた通り。
お前の負けだ。観念しろ
458:デフォルトの名無しさん
07/04/21 12:08:07
>>456
キチガイのセンスに合わせるのは難しいな
四流大学出はそういう会話が得意なんだろうけど。
459:デフォルトの名無しさん
07/04/21 13:21:07
>>446
手足として使った奴隷コーダに強烈な恨みを買っているのが
ハッタリコンサルのダメダメな所。
「勝手に引き抜いて、変な仕事ばかり回してきて
あのバカは一体何様のつもりだ？」
って泣いてたぜ、奴隷コーダちゃん
460:デフォルトの名無しさん
07/04/21 13:24:16
>>459
そうそうｗ
そういえばあのコーダも使えなかったよなｗ
Javaのクラスはオブジェクトじゃない！とかわけのわからないこといってたしｗ
461:デフォルトの名無しさん
07/04/21 13:25:40
>>460
そういえばあいつ、頭おかしくなって会社やめちゃったってなｗ
ヒキって２ｃｈばっかやってるらしい。
版画とかよばれてるしｗ
462:デフォルトの名無しさん
07/04/21 13:33:03
>>461
ああ、あのゴミか
ほんと死ねばいいのにな
463:デフォルトの名無しさん
07/04/21 13:34:23
>>462
同意ｗ
おれがあいつならとっくに吊ってるｗ
464:デフォルトの名無しさん
07/04/21 13:34:37
>>460
バカが発振し始めたな
デブのことだよハッタリ高弘ちゃん
465:デフォルトの名無しさん
07/04/21 13:36:25
>>464
版画ﾊｹｰﾝ（版画風ｒｙ
うわきもｗ
466:デフォルトの名無しさん
07/04/21 13:36:31
早速スレに晒しときましたｗ
467:デフォルトの名無しさん
07/04/21 13:39:24
おいおまいら、アドレナリンは俺専用のオモチャだ
勝手にアドレナリンをいじるな
暇つぶしに適当な書き込みをするとすぐ怒り出すのでとても面白い
468:デフォルトの名無しさん
07/04/21 13:42:11
>>467
強がりいってらｗあったまわりいｗ
469:デフォルトの名無しさん
07/04/21 13:42:51
>>467
カプサイシンの間違いじゃねぇの
半島人臭いし
470:デフォルトの名無しさん
07/04/21 13:43:53
ﾑｯｷｰ、ﾌｧﾋﾞｮｰﾝ(笑
471:デフォルトの名無しさん
07/04/21 13:45:29
おいハッタリをあんま構うな
あまり追い詰めると
出身校(四流大)で拳銃乱射事件起こすぞきっと
472:デフォルトの名無しさん
07/04/21 13:46:34
>>469
そうそうｗ
版画もちょっと煽るとすぐファビョるしなｗ
半島に帰れよｗ
473:デフォルトの名無しさん
07/04/21 13:47:38
ハッタリ高弘の好物
キムチ餃子
474:デフォルトの名無しさん
07/04/21 13:48:59
さぁーってと
昼休みのハッタリいじめはそろそろ飽きたし
四月の休日を満喫してくるか（←満喫に行くって意味じゃないよｗ
475:デフォルトの名無しさん
07/04/21 13:52:03
版画版画ってバカにすんな！！
Javaのクラスなんかオブジェクトのわけないだろ！
たしかにハッタリたかひろも俺も鮮人だが、それがどうした！
低脳どもが！
476:デフォルトの名無しさん
07/04/21 13:53:51
ハッタリの成りすましはクオリティが低くて萎える
477:デフォルトの名無しさん
07/04/21 13:54:42
GoF本って独習C++を一通りやった程度の知識で理解できますか？
478:デフォルトの名無しさん
07/04/21 13:54:51
メモ：ハッタリは半島人
479:デフォルトの名無しさん
07/04/21 13:56:31
>>478
半島人には関わらない方がよい。
480:デフォルトの名無しさん
07/04/21 21:03:15
>>477
基本的に経験則のまとめ本だから、必要な状況にならないと理解しにくいのが多い。
まあ理解出来る出来ないに関わらず一冊持っとくのは良いと思うよ。
481:デフォルトの名無しさん
07/04/21 21:15:36
こういうのには盛り上がるんだなｗ
482:デフォルトの名無しさん
07/04/21 21:18:22
ほら、宗教の人だから自作自演で信者獲得したフリしないと気が済まないんだろ
483:デフォルトの名無しさん
07/04/27 11:52:06
GoF本を今時会社の机にこれ見よがしに置いてあるの見ると笑える
484:デフォルトの名無しさん
07/04/27 14:49:27
キチガイって飽きないの？
485:デフォルトの名無しさん
07/04/29 00:50:15
>>484
自問自答は黙って答出せ
486:デフォルトの名無しさん
07/05/18 15:28:15
ここのObserverﾊﾟﾀｰﾝはわかりやすかった。
URLﾘﾝｸ(goodjob.boy.jp)
487:デフォルトの名無しさん
07/06/18 21:21:41
アーキテクチャパターンの質問で悪いんだけど、
MVCパターンにおいて、
｢押されたボタンに応じて新しいサブWindowをオープンする作業｣のような、
Window遷移を管理する人(実現する人)って誰になるの?
Model? View?
Window遷移もアプリケーションの中核処理になるから、
Modelの責務の範囲内なのかなとも思うんだけど、、実際どうなの?
488:デフォルトの名無しさん
07/06/26 23:59:02
どーでもねーよ
489:デフォルトの名無しさん
07/07/09 11:31:18
>>487
画面の制御なんてモロにViewだと思うんだけど。
490:デフォルトの名無しさん
07/07/09 22:41:24
ＵＩモデルだな
491:3年前
07/07/11 11:24:49
Domain-Driven Design
ｽﾚﾘﾝｸ(prog板)
1 名前： 仕様書無しさん 投稿日： 04/03/25 02:38
ドメイン駆動型デザインとは何か？
Download draft of book from
URLﾘﾝｸ(www.domaindrivendesign.org)
URLﾘﾝｸ(www.domaindrivendesign.org)
492:そして現在
07/07/11 11:26:36
Domain-Driven Designのエッセンス
「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。
しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関す
る解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無か
ったと言ってもいいでしょう。 Eric Evansの『Domain-Driven Design』（以降DDD）は、「ソフト
ウェアの真の複雑さに挑戦する」という副題からも分かるように、ドメインモデリングに正面
から取り組んだ待望の書籍です。
DDDは、海外では非常に評判の高い書籍です。本書の出版前からMartin Fowler氏により
「期待できる内容だ」と推薦されていたり、GoFの1人であるRalph Johnson氏は自身のブロ
グで本書を「4、5回は読み直した」と賛辞を送っています。Spring Frameworkの開発者Rod
Johnson氏も、最近のプレゼンテーションでDDDを紹介しながら、「Java EE開発者がこれ
から進むべき道はリッチなドメインモデルだ」と発表しています。また、MDAツールSculptor
のように、DDDを積極的に採用したツールやフレームワークも登場しつつあります。
しかし、日本では翻訳書がいまだに出版されていないこともあり、本書の出版から3年近く
経った今でも、まだまだ一部の通の人たちにしか広まっていないように筆者には思われます。
また、原書を読まれた方の中からも「本が分厚すぎて読みきれない・・・」という嘆きの声も
聞かれます（DDD難民という言葉もあるそうです）。
そこで本連載では、全3回に分けて、DDDの全貌を簡潔に紹介してみたいと思います。
DDDはタイトルからは一見分かりにくいのですが、いわゆるパターン本の1つです。
しかし、DDDは全体が読み物の体裁で編まれているため、パターンカタログが読み物から
独立しているもの（『デザインパターン』『J2EEパターン』『エンタープライズアプリケーション
アーキテクチャパターン』など）に比べ、パターンの閲覧性は良くありません。本連載では、
すでに一度読破された方にも有用な資料となるように、パターンカタログとしてDDDを再構成
してみます。
493:デフォルトの名無しさん
07/07/11 19:11:44
へー
494:デフォルトの名無しさん
07/10/08 17:41:42
ここって何も知らん人でも書いていいんだろうか・・・
一つのパターンを適用、っつーか使うっていうのなら何とかできるんだけど、複数のパターンを組み合わせるとなるといきなり手が止まる・・・
デザインパターンはいいコードを書いていれば自然に適用されている物、っていうことなの・・・？
495:デフォルトの名無しさん
07/10/08 18:57:21
一つ使うも複数使うも難易度に差はないだろ
理解しないでサンプルコード改変してるレベルと見える
496:デフォルトの名無しさん
07/10/10 23:46:07
デザインパターンって、「組み合わせて」使うような例ってほとんどないんじゃないかな。
一つのモジュールの別々の箇所で複数のデザインパターンを併用することはよくあるけどねー。
Java のクラスライブラリがいい例。
497:デフォルトの名無しさん
07/10/31 00:50:37
難しいことはいいからデザパタって
ホントに役に立つのかどうか教えろよ
498:デフォルトの名無しさん
07/10/31 00:51:49
>>497
OOPを一から自分で設計するのは骨が折れるぞ
バグも紛れ込むし
499:デフォルトの名無しさん
07/10/31 00:55:39
お前に使いこなせねえよバーカ
500:デフォルトの名無しさん
07/10/31 00:55:43
>>497
仕事なら役に立つよ
一単語だけで意図が伝わる
501:デフォルトの名無しさん
07/10/31 00:58:01
>>499
うるせーハナクソ
502:デフォルトの名無しさん
07/10/31 01:16:18
>>497
自分のそれまでの経験とセンスだけで、
後々のメンテとかになるべく困らないような
設計するのは難しいから、頭のいい先人たちが
編み出した有用なパターンを知っておいた方が楽。
ていうか知らないとかなり大変。
503:デフォルトの名無しさん
07/10/31 01:23:01
>>498
かなりできる人間が過半数超えてれば使えるし、
超えて無いとロスの方がでかい。
504:デフォルトの名無しさん
07/11/08 11:28:46
C++でのcrtpとか言語毎に形成されたイディオム的なパターンは実用性も高いし、初心者にも分かりやすいと思う
結局言語の所まで落とさないと使えないしね
というかC++だとそういうidiom使わないとたちどころに言語になるし
GoFで紹介されてる各パターンは役に立たないけど
そこで使われる考え方っていうのは言語ローカルなイディオムを理解するのに役立つかなぁと思ったけど、
もう少し勉強が進んだらまた違う感想になる気がする
505:デフォルトの名無しさん
07/11/14 02:08:15
デザインパターンを使わずにスマートに書く方法とかって
どんな感じなんになるんでしょうね？
たとえば、うどんをそばを作る場合なんかはほとんど
工程は一緒なのでテンプレートメソッドに使うんだろうけど
みなさんならどうやって書きますか？
ふと考えるといろいろあるけどどれもいまいちな気が。
1どんぶり用意
2うどんかそばを入れる
3だしをそそぐ
506:デフォルトの名無しさん
07/11/14 03:04:16
GoFが役に立たないとか、デザインパターンを使わずにスマートに書くとか・・・学生さんかね？
507:デフォルトの名無しさん
07/11/14 08:14:51
>>506
なんだか継承になれすぎて使わないパターンがあまりおもいつかなかったもので使わなかったらどうだろうかと思ったんですけど。
508:デフォルトの名無しさん
07/11/14 12:22:47
>>505
昔は仕様書を元に上から下へ逐次式に書いたものだよ。
仕様書がすべて、はじめに機能をすべて洗い出せることこそ能力。
これに慣れたままSEになり３０代を迎えると、もう補正が効かない。
あと、現場でやっている人は、GOFどうこうを意識している人はあまりいないとおもう。
509:デフォルトの名無しさん
07/11/15 02:57:13
>>508
>これに慣れたままSEになり３０代を迎えると、もう補正が効かない。
そういう人を一般的に才能がないという。
勉強する意欲がない人はいくら若くてもダメ。
転職するならお早めに。
510:デフォルトの名無しさん
07/11/15 03:47:08
>>508
ちょっと前にやったプロジェクトで、GOFに死ぬほど拘ってる
プロジェクトリーダーが居て困ったことがあるな。
最近、GOFを勉強したらしく、なんか頭がすごく良くなったカン違い
してるみたいで、設計がGOFのどれかのパターンになってないと、
全部NGにされて、直すのに苦労したよ・・・
511:デフォルトの名無しさん
07/11/15 03:50:05
>>508
GoFすら意識してなくて機能をイメージできるものか？出来てるつもりじゃないか？
512:デフォルトの名無しさん
07/11/15 09:22:08
設計なんて茨の道さ。
もんどりうってじたばたして、
痛い思いしながらGoFにしがみついたり、
手放したり、またGoF読み直したり、
もんどりうったり、じたばたしたり、
GoF読み直してピンときてみたり、
こなかったり、もんどりうって、ピンときたり。
513:デフォルトの名無しさん
07/11/15 13:56:27
全ての設計要素は何らかの秩序の上に存在すべき
だが設計要素や立脚する秩序をすべて表現する必要はないってこった
達人の書いたオプソのコード読んでも、凄さが伝わりくい理由がそこにある気がする
514:デフォルトの名無しさん
07/11/15 14:39:57
>>512
オッパイ揉んでピンときたり
が抜けてね？
515:デフォルトの名無しさん
07/12/28 16:51:17
ソースコードの見た目がかっこ良くなるので使ってます
516:デフォルトの名無しさん
08/01/07 21:48:54
開発環境のバージョンによって、含まれるライブラリが違うため、
どちらのバージョンでも動くように、実装を切り替えるということがしたいのです。
XMLのラッパーライブラリのエンジンの実装を切り替える、というようなことです。
Strategyパターンを使うのがよいのでしょうか？
最初は、Decoratorパターンと区別がつかなかったのですが、
GOF本のDecoratorのところにあるように、
・中身を取り換えるのが、Strategyで、
・外側を取り換えるのが、Decorator
ということで、
中のエンジンを取り換えるのは、Strategyパターンということでしょうか？
517:デフォルトの名無しさん
08/01/07 22:43:21
>516
あんまりパターンの名前にとらわれずにしたほうがいいと思われ。
518:デフォルトの名無しさん
08/01/08 00:19:40
うむ。
とりあえず作りたいように作って、似たパターンがあったらそれに合わせていく方向で。
519:デフォルトの名無しさん
08/01/09 03:33:32
>>517-518
ありがとう
過去レスででてたけど、作ってみてリファクタリングの時に考える方法やってみる
520:デフォルトの名無しさん
08/02/06 20:05:11
// Hoge.h
#ifndef HOGE_H
#define HOGE_H
class Hoge {
public:
static Hoge* New();
virtual void Foo() = 0;
virtual ~Hoge() { }
};
#endif
// Hoge.cpp
#include "Hoge.h"
#include <iostream>
class Hoge_ : public Hoge {
public:
virtual void Foo() { std::cout << "Hoge::Foo" << std::endl; }
};
Hoge* Hoge::New() {
return new Hoge_();
}
// main.cpp
#include "Hoge.h"
#include <boost/scoped_ptr.hpp>
int main() {
boost::scoped_ptr<Hoge> hoge(Hoge::New());
hoge->Foo();
}
こうやって実装を pimpl より隠蔽してるソースを見たんだけど、
このデザパタの名前って何？
521:デフォルトの名無しさん
08/02/06 23:46:55
これっしょ？よく見る普通のインターフェイスじゃないか。
URLﾘﾝｸ(boost.cppll.jp)
522:デフォルトの名無しさん
08/02/07 00:21:09
「～パターン」 とかの名前がついてるわけではないのね。
523:デフォルトの名無しさん
08/02/07 03:10:32
strategyじゃね
524:デフォルトの名無しさん
08/02/07 07:40:40
派生クラスを１つしか作らないこと前提で目的も違うから
strategy じゃないな。
525:デフォルトの名無しさん
08/02/14 22:04:23
質問させてください
Compositeパターンで作られたクラスに
インターフェースの拡張を施した新しいクラスを作りたいときは
Bridgeパターンを使いますか？
526:デフォルトの名無しさん
08/02/15 20:35:57
自己解決しました
527:デフォルトの名無しさん
08/02/16 03:47:22
自己解決したらできれば、解決法を書いていきましょう
後で見た人の参考になりますよ
528:デフォルトの名無しさん
08/02/27 09:21:02
フラグを１ビットではなくカウンターで持っておき、ＯＮ扱いを１より大きい
値（仮にＡ）とします。ＯＮしたい状況ではいきなりＡを代入するのではなく
１ずつ足していき、ＯＦＦしたい状況ではすぐにゼロを代入します。
こういう、ＯＮにするときだけショックアブソーバー付きな動作をする
フラグはデザパタではどういう名前が付けられてますか？
529:デフォルトの名無しさん
08/02/27 13:24:07
自家発電しました
530:デフォルトの名無しさん
08/02/27 19:14:49
>>525-526
自己解決パターン
531:デフォルトの名無しさん
08/02/28 01:50:40
アンチパターンだな
532:デフォルトの名無しさん
08/03/02 18:10:25
最近デザインパターンを勉強しだしたんですが
GoFの23個のうち2～3個組み合わせて何か簡単なものを作るとしたら
どんなものが思い浮かびますか？
533:デフォルトの名無しさん
08/03/02 18:27:07
STL
534:デフォルトの名無しさん
08/03/02 18:29:26
Template Method との組み合わせは結構考えられるかと。
535:デフォルトの名無しさん
08/03/02 22:56:35
コマンドパターンとなんかで、
GUIツールのアンドゥの練習
536:デフォルトの名無しさん
08/03/02 22:56:57
やっぱり、アンドゥ、リドゥの練習にしといて
537:デフォルトの名無しさん
08/03/02 23:13:23
Memento パターンと Command パターンの複合か。
538:デフォルトの名無しさん
08/03/03 01:22:59
わかりました
やってみます
539:デフォルトの名無しさん
08/03/04 18:26:09
ｃ++です
DecoratorパターンでConcrete ComponentとDecoratorを区別して
Concrete Componentの型を知る方法はdynamic_castを使うしかないですか？
540:デフォルトの名無しさん
08/03/04 18:53:21
>>539
型を知って何をするかによって方法が変わる気が。
RTTI(dynamic_castもその１つ)を使うか、Concrete Componentのメンバに型を示すIDのようなものを用意しておくか。
そもそもスレ違い。
541:デフォルトの名無しさん
08/05/09 11:50:43
鈴木高弘スレｗ
542:デフォルトの名無しさん
08/05/11 05:10:51
ゲーム作ろうと思い、デザインパターンの勉強をしてるんですが
Singletonをどんな風に使うのか今一ピントきません。
Singletonじゃないと困る場合。
Singletonだと助かる場合。
出来たら例を示して貰えないでしょうか。
543:デフォルトの名無しさん
08/05/11 07:57:27
>>542
ぜひ、こちらへどうぞ
ゲームにおけるデータ構造・クラス設計・パターン
ｽﾚﾘﾝｸ(gamedev板)
544:デフォルトの名無しさん
08/05/11 16:39:33
あちらで聞いてみます
545:デフォルトの名無しさん
08/05/11 17:47:41
やる夫がデザインパターンをやるようです
URLﾘﾝｸ(mojalog.com)
546:デフォルトの名無しさん
08/05/11 18:06:29
>>545
やる夫ｗｗｗｗめちゃめちゃ笑った
547:デフォルトの名無しさん
08/05/11 18:15:14
>>545
デザインパターンの考え方が分かりやすくて助かりました。
548:デフォルトの名無しさん
08/05/11 19:23:44
AA入ってるのって、一見とっつきやすそうだが…、
読みにくくもあったり…しかし微笑ましいのだけは確か。
549:デフォルトの名無しさん
08/05/11 21:11:22
例自体は具体的で読みやすいんじゃないか？
デザパタ本て(全部とは言わないが)ほとんどが
説明のための説明みたいな本になってるし。
550:デフォルトの名無しさん
08/05/12 02:47:40
シンプルファクトリーって始めて知った
ファクトリメソッドとアブストラクトファクトリしか知らなかった
デザインパターン的には常識なの？
551:デフォルトの名無しさん
08/05/12 02:56:07
この手のものは先に名付けたもん勝ちだから
あまり仔細にこだわろうとするな。
> ファクトリメソッドとアブストラクトファクトリしか知らなかった
知ったかどうかよりも理解できたかどうかが大事なんだが。
552:デフォルトの名無しさん
08/05/12 16:39:49
URLﾘﾝｸ(marupeke296.com)
個人的にここのデザインパターンの解説がゲームプログラミングを例にしているせいか
わかりやすいんだが、スレ住人的にはどう？
553:デフォルトの名無しさん
08/05/12 16:59:44
>>552
わかりやすいし、筆者の理解度は高いと思う。
自分の言葉で言いなおしてるところで、
的が外れていないので高感度アップ。
Abstract Factory 一塊のオブジェクト群を沢山の種類用意する
は、恥ずかしながら今までみたどの解説よりスッとくる一文だった。
554:デフォルトの名無しさん
08/05/12 22:57:03
例というなら、GoFの元ネタはウィジェットや言語の実装で現われたパターンだから、
自分でウィジェットや言語を書けば何を言ってるのかすぐわかる
555:デフォルトの名無しさん
08/05/12 23:10:08
うじぇー奴
556:デフォルトの名無しさん
08/05/13 00:53:16
>>552
FlyWeightってこのページで書かれているような感じなの？
557:デフォルトの名無しさん
08/05/13 09:31:42
zsh line editorのwidgetでも使えますか！？
558:デフォルトの名無しさん
08/06/14 11:28:21
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門
URLﾘﾝｸ(www.amazon.co.jp)
この本とかどうだろうね？まだ自分は読み始めだけど。
559:デフォルトの名無しさん
08/06/14 19:02:26
だったら読み終わったときに評価書いてくれ
560:デフォルトの名無しさん
08/06/18 18:46:30
MVCモデルについて質問です。
javaであればModelでは描画するメソッドを一切実装せず、描画メソッドについてはすべてViewで実装するという事ですか？
例えば、Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思いますが、
そういう時もViewまで先送りにした方がいいですか？
561:デフォルトの名無しさん
08/06/19 00:31:36
描画はモデルじゃね？
562:デフォルトの名無しさん
08/06/19 02:05:46
>Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思います
例えばどんな時？
デザパタの本にありがちな、
Shape インタフェースに draw メソッドがあって
Circle でも Triangle でも draw 呼べば片付きますよ、
的な話って、いかにも説明のための説明って気がしてならん。
563:デフォルトの名無しさん
08/06/19 02:20:03
ここまで一切コントローラの話題が無い件
564:デフォルトの名無しさん
08/06/19 07:30:42
>>562
まさにそういう時。
アルゴリズムでdraw可能なオブジェクトをいくつかはじきだす。
その時にそいつにdrawメソッドを持たせておいた方が都合がいいのでそうしているが、
癒着してるようで気がかり。
565:デフォルトの名無しさん
08/06/19 19:37:43
ほれ、答えだ
URLﾘﾝｸ(www.fujigoko.tv)
566:デフォルトの名無しさん
08/06/19 20:07:01
長い；；
567:デフォルトの名無しさん
08/06/20 23:52:54
>>565
当たり前すぎるくらいに当たり前のこと書いてるな。
でも、この当たり前が理解できてないやつが殆どだ。
モデル自体が保存メソッド持ってるフレームワーク見せられて
「なんでこんな設計なの？」「便利だから」
意味不明の回答で泣きそうになった。
次の会社でも探すか。
568:デフォルトの名無しさん
08/06/21 00:25:48
データモデルと永続化は別か，そうかそうか
569:デフォルトの名無しさん
08/06/21 00:50:45
>>567
あたり前田のクラッカーってどうなったんだろう？
570:デフォルトの名無しさん
08/06/21 09:28:30
> モデル自体が保存メソッド持ってるフレームワーク見せられて
普通じゃん。
571:デフォルトの名無しさん
08/06/21 09:42:35
>>567
むしろ保存とか読み込んで再構築とかいう手間を見せ付けてはいけない
572:デフォルトの名無しさん
08/06/21 13:33:10
シリアライズ機能くらい普通じゃん
573:デフォルトの名無しさん
08/06/21 16:01:39
シリアライズを提供することと保存の主体であることは別じゃね？
574:デフォルトの名無しさん
08/06/21 16:06:23
Save(IOutputStream* stream)
Load(IInputStream* stream)
みたいに外部に保存主体があるわけじゃなくて、
まさか内部に保存主体があるのか？
575:デフォルトの名無しさん
08/06/21 16:12:35
dbの話じゃないの？
576:デフォルトの名無しさん
08/06/21 16:23:23
>>574
保存主体ってなんですか＞＜；；
# Save(IOutputStream* stream)
これだと「何を」みたいな目的語が全く存在しない
577:デフォルトの名無しさん
08/06/21 18:08:59
.NET Frameworkだと、シリアライザクラスに分けてあるね。
578:デフォルトの名無しさん
08/06/21 18:15:05
クラスを分けるのは便利な面もあるけど、
保存すべき情報は外部に見せることのできる情報ばかりではないからね。
両方できるようにしてどっちにするか選択できるのが一番良い。
579:デフォルトの名無しさん
08/06/22 09:05:38
Save(PersistContext pContext)とかになってPersistContextの実装しだいでDBにもXMLにも保存できるのが吉かと。
580:デフォルトの名無しさん
08/07/31 21:05:45
>>552のAbstract Factoryの頁を読んでみたんだけど、
とても違和感を感じる、というよりはっきり言って全く間違っているように思うのだが
これは俺の方が間違ってる？
俺がおかしいなと思った点は、
(1) void Create( AbstractWeapons *AbsWep)みたいな"具体的な"値を引数で
取るメソッドのどこが"Abstract"（抽象）なのか？
思うに、この著者は"Abstract"の意味を取り違えているのではないか？
確かに「武器」はAbstractWeapons という型に抽象化されてはいるが、
Abstract Factoryの"Abstract"ってそういう抽象化のことを指しているんじゃないのでは？
(2) 1とも関係するが、著者は自分で『オブジェクト内部で作ってもらった方が、
外部の人は渡すべき武器について知らなくて良いので楽になる』と（もっともな）事を言っているのに
できたコードは全然そうなってない。
581:デフォルトの名無しさん
08/07/31 22:20:23
>>580
そういう疑問を持ったときは実際にプログラミングするのが早い
582:デフォルトの名無しさん
08/08/04 17:36:15
>>580
(1)AbstractなのはMacheneでもWeaponでも無くFactory、
void Machine::CreateはConcreteなWeaponもConcreteなFactoryも知らない
(2)Machineの内部でAbstractなFactoryがWeaponを生成している
実際に生成されているWeaponsを知っているのはConcreteなFactoryのみいう言う状態
と捉えれば別にその2点は間違ってないと思うけど…
#LispとかMLでサンプルを書いたOOP系の本が見たい
583:デフォルトの名無しさん
08/08/07 00:49:16
まぁWeaponをインタフェース名にしろと思ったな。
AbstractWeaponsImpl みたいな感じで
なんらかの共通処理を持った実装クラス名にすることはあるんだが
インタフェース名にAbstractcなんやらーってあんまりしないなあ。
宗教だけど。
584:デフォルトの名無しさん
08/09/08 11:09:58
あげ
585:デフォルトの名無しさん
08/09/08 14:08:20
読み始めたけど、道のりなげぇぇぇぇ。
586:デフォルトの名無しさん
08/09/08 20:11:30
或曰: お仕事
URLﾘﾝｸ(www.issei.org)
こちらのサンプルにあるような、
依存部分だけをインターフェスのContextとして取り出し、
実行時に引数にContextを渡して依存を解決するような場合の
パターン名は何かありますでしょうか？
もし、ない場合適当なパターン名としてどんなものがありますでしょうか？
587:デフォルトの名無しさん
08/09/09 01:27:27
Context と Context のユーザーが
互いにインスタンス参照をもちあう作りが
ものすごく不吉な感じするんだけど
そのあたりどうなんだろう。
588:デフォルトの名無しさん
08/09/09 09:44:23
Head Firstの本ってどう？
589:デフォルトの名無しさん
08/09/09 19:11:26
abstract Factoryパターンと、Factory Methodパターンの違いについて述べよ。
また、ファクトリパターンがどういう場合に有効なのか知るところを述べよ。
生成メソッド（例えばファイル読み込みなど）を生成すべきメソッドに持たせるとどのような不都合が起こるのかを述べよ。
590:デフォルトの名無しさん
08/09/09 20:23:18
>>588
俺持ってるけど良いよ
ホントに重要なパターンだけを優先順位を付けて展開してる、
最初は秘術的なobserverパターンから初めてるのも好感できる
observerはstrutsやMVC関連で良く使われるパターンだよね
591:デフォルトの名無しさん
08/09/10 00:47:57
>>590
でもピザパターンとかが無いからなぁ・・・
入門としては良書だけど、見通しが利かないってとこがちょっと。
592:デフォルトの名無しさん
08/09/10 17:36:05
Head Firstで基礎を勉強したあとの補強にいいのはGoF本？
593:デフォルトの名無しさん
08/09/10 20:58:10
Amazon.co.jp： Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: 本
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(images-jp.amazon.com)
これですか？
高すぎるんですがｗｗｗ
594:デフォルトの名無しさん
08/09/10 21:00:44
>>593
貧乏自慢すんなよ
595:デフォルトの名無しさん
08/09/13 16:16:55
「デザインパターンによるJava実践プログラミング」っていう本がぱっと見GoF本に似てる感じがしたんだけど、
これを読めばGoF本読まなくっていいかな？
596:デフォルトの名無しさん
08/09/13 23:48:47
どれ読んでも難解だよな
ゲームで説明しているページが一番分かりやすい。
1個だけ間違ってるのあるけど
597:デフォルトの名無しさん
08/09/14 04:40:51
GoFをまるぺけのところと照らし合せながら読むのがいいと思う
598:デフォルトの名無しさん
08/09/14 10:29:03
Head Firstシリーズのデザパタ本を読んだ後に同じシリーズのオブジェクト指向設計の本
をちょっと立ち読みしてみたら内容がかぶってる気がしたんだけど、
前者を読んだ後に後者を読む価値はあるかな？
両方読んだ人いたら教えて。
599:デフォルトの名無しさん
08/09/21 15:39:38
stateとstrategyの違いを教えてください。
600:デフォルトの名無しさん
08/09/21 17:17:42
実装クラスで表現されたモノによって呼び方が変わるだけで、構造上の違いはないよ。
601:デフォルトの名無しさん
08/09/22 06:22:50
Gofって所謂カタログ本だと思ってた。
>>598
ある
602:デフォルトの名無しさん
08/09/28 10:00:51
過疎どすな
603:デフォルトの名無しさん
08/09/28 23:50:39
デザパタてはやり過ぎない不思議
604:デフォルトの名無しさん
08/10/02 15:47:16
渇祖
605:デフォルトの名無しさん
08/10/05 14:25:10
>>599
「目的が違う」ってことでいいのかな？
stateはアルゴリズムを動的に切り替えられることに意義があり、
strategyはアルゴリズムを分離することに意義がある
とか。
606:デフォルトの名無しさん
08/10/05 16:08:42
stateの方、それ違くね？
607:デフォルトの名無しさん
08/10/05 16:29:00
The differences between Strategy pattern and State pattern Five ’s Weblog
URLﾘﾝｸ(powerdream5.wordpress.com)
The difference between the two GOF patterns "Strategy" and "State"
URLﾘﾝｸ(www.c-sharpcorner.com)
散々議論されてきた歴史があるのでそれを参考にしたらいいと思うよ
608:デフォルトの名無しさん
08/10/08 23:54:54
Compositeってやつのみっつのくらすをひとつのクラスにすることは出来るの？
609:デフォルトの名無しさん
08/10/09 12:31:35
っていうか、「何でお前が勝手にルール決めてんの？つか誰？」って感じしない？
610:デフォルトの名無しさん
08/10/09 16:31:30
>>608
XMLとか
611:デフォルトの名無しさん
08/10/13 23:36:50
>>609
OOPのノウハウを共有するために呼び名を決めたほうが良いね、ってのが
デザインパターンの意義なのにルールも糞もあるもんか。
おまいが好きなノウハウに好きな名前を付けたけりゃ、そうすればいい。
それを共有しようとする奴は誰もいないだろうがなぁ。
612:デフォルトの名無しさん
08/11/11 15:28:48
あげ
613:デフォルトの名無しさん
08/11/12 23:42:17
まだあったか
614:デフォルトの名無しさん
08/12/16 13:36:00
あげ
615:デフォルトの名無しさん
08/12/23 01:08:25
Amazonから
「ケント・ベックの『実装パターン』、
Amazon.co.jpでお求めいただけます」
メールｷﾀ━(ﾟ∀ﾟ)━!!
↓
N瀬監修T社翻訳........orz
616:デフォルトの名無しさん
09/01/11 02:29:21
シングルトンってインスタンスが初めて呼ばれるまで本当にそのインスタンス生成されていないの？
617:デフォルトの名無しさん
09/01/11 03:20:49
初回に new しているタイプは言うまでもなく、
getInstance内でstatic変数として確保しているタイプでもそうなる。
クラスのstaticメンバ変数として作っちゃうと、mainより前に作られる。
618:デフォルトの名無しさん
09/01/11 07:42:09
そもそも
シングルトンってインスタンス誕生の瞬間までカバーしてたっけ？
619:デフォルトの名無しさん
09/01/11 12:47:51
>>617
それはプログラミング言語によって異なるだろう。
620:デフォルトの名無しさん
09/01/11 13:19:12
>>618
シングルトンは初めて使う時に生成するもんじゃないのか？
621:デフォルトの名無しさん
09/01/11 13:22:04
明日は成人の日か
622:デフォルトの名無しさん
09/01/11 14:29:57
シングルトンて北朝鮮放送の読み方のように言えるよね
623:デフォルトの名無しさん
09/01/11 14:43:18
싱 글똔 さんか。
624:
09/01/18 21:54:19
デザインパターンじゃないんだけど実装パターンに書かれてる
Pluggable Selector てのがいまいちわかりません。例に出てくるJUnitもよく知らないし。
誰か教えてください。
625:デフォルトの名無しさん
09/01/18 22:02:29
シングルトンは任意の実行コンテキスト内でインスタンスの個数を制限するだけで、
いつインスタンス化するかはお好きに。
リファレンスカウントがなければ解放してもいいし。
626:デフォルトの名無しさん
09/01/19 09:13:22
>>624
どこに書かれていて、何が分からないのか分からない。
627:デフォルトの名無しさん
09/01/19 19:08:29
626が全否定
628:デフォルトの名無しさん
09/01/22 02:08:22
すいません。アドバイスください。
車CarContextの走行状態をStateパターンで
CarRunState, CarHighwayRunState, CarIdleStateと設定して、
Stateの派生クラス内で状態遷移の判定を行っているとします
ここで予想外に水陸両用車ShipCarContextが増えて
CarSwimStateの状態を増やそうとした場合に、
今まで派生クラス内で行っていた状態遷移の判定を
CarContext、ShipCarContext内で行うべきでしょうか？
CarContextが状態遷移の判定ルーチンで膨れあがるのが嫌で、
State派生クラスで状態遷移の判定を行っていました
諦めてShipCarContext用の状態判定Stateクラスを一から作り直すか、
CarContext内で状態遷移の判定を行うか悩んでいます
定石があれば教えていただきたいのですが
629:デフォルトの名無しさん
09/01/22 20:56:59
>>628
おそらく定石からは外れるだろうけど、StateManagerみたいな管理クラスを間に挟んで、そこで状態遷移を一元管理させてる。
GOFのStateパターンに従った場合、OOぽいアプローチにできるが、遷移の流れを把握しにくくなるような気がする。
また状態遷移も、今の状態、次の状態、遷移時のアクションが分かれば済むようなもの、まれにガード条件、分岐条件が加わるような場合しか使ってこなかったので、これらの情報を設定ファイルに吐き出して、実行時に状態遷移マネージャに読み込ませてる。
おかげで状態遷移はそれほど膨れ上がらないが、アクションは1～数クラスにまとめてしまうので、膨れ上がるね。
630:デフォルトの名無しさん
09/01/22 21:05:31
FactoryMethodパターンとかAbstractFactoryパターンって解放のことまで考えられてないけど、
解放ってどうするの？
631:デフォルトの名無しさん
09/01/22 21:30:19
>>630
所有権を持っているオブジェクトが破棄してあげればいいんじゃね。
通常だと、Factoryにより生成されたオブジェクトを保持してるオブジェクト
おそらく問題としていることは、複数のオブジェクトでFactoryにより生成されたオブジェクトを保持してる場合を気にしているものと思われる。
所有状態が複雑になるため、このような状態は極力避けるべきだと思うが、どうしても複数で保持する必要があるのなら、参照をコピーした際に所有権も移動させるか、または参照カウンタを実装し、最後まで保持してるオブジェクトに解放を行わせるかのどちらかかと。
632:デフォルトの名無しさん
09/01/22 22:59:32
GoF以外のデザインパターンってありますよね？
ここのサイトでけっこうまとめられてるようですが。
URLﾘﾝｸ(www.tom.sfc.keio.ac.jp)
そういうのっていろんな人が好き勝手に作ってるものなんですか？
一つの本にまとめられていたりとかはしないんですかね
633:628
09/01/23 02:45:12
>>629
ありがとうございます。参考になりました。必ずしもGOFってわけでもないですよね
>GOFのStateパターンに従った場合、OOぽいアプローチにできるが、遷移の流れを把握しにくくなるような気がする。
たしかに把握しにくいです。
とりあえず今回は、それぞれのStateに分散した処理をそのまま使い回したいので、
（泥沼な気もしますが）CarRunStateを例にとると
void CarRunState::update(Context * context);
で読み込んだContextからCarContextにダウンキャスト可能なら、CarContextの遷移判定を行い、
ShipCarContextにダウンキャスト可能なら、ShipCarContextの遷移判定を行うように処理を分けようと思います
CarContextとShipCarContextで判定処理が混在するので、CarRunStateの処理があまりに膨れるようなら、
ダウンキャストではなく、CarRunStateから、CarRunStateForCarとCarRunStateForShipCar
に分けるという方針で行こうと思います
それやるくらいなら・・等、ご意見を頂ければとてもありがたいです
634:デフォルトの名無しさん
09/01/24 20:58:05
デザインパターンなんてもんが存在してるってことは、オブジェクト指向はまだまだってことでは？と言ってみるテスト
635:デフォルトの名無しさん
09/01/24 20:59:29
単なる護符だよ
636:デフォルトの名無しさん
09/01/24 21:38:53
>>634
逆だよ デザインパターンが48個になったら完成
637:デフォルトの名無しさん
09/01/24 22:10:55
>>636
kwsk
638:デフォルトの名無しさん
09/01/24 22:17:29
４８手だろ
639:デフォルトの名無しさん
09/01/25 00:17:36
48のデザインパターンと52の関節技ですねわかります
640:デフォルトの名無しさん
09/01/25 04:38:04
四苦八苦、4x9+8x9=108
で人間の煩悩の数だけでデザインパターンがあるのではないか
641:デフォルトの名無しさん
09/01/25 06:35:53
>>632
結城さんのマルチスレッド編とか。
URLﾘﾝｸ(www.amazon.co.jp)
642:デフォルトの名無しさん
09/02/09 18:03:46
確認なんだけどハッシュはイテレータ作れないよね？
643:デフォルトの名無しさん
09/02/09 19:15:02
要素に順番にアクセスできるのがイテレータだと思うんだけど、
ハッシュの場合のイテレータの『順番』ってのはどういうのを考えてるの？
644:デフォルトの名無しさん
09/02/09 22:10:20
ハッシュド・ビーフが食いたくなった
645:デフォルトの名無しさん
09/02/10 00:00:27
>>642
Map<K,V> m を iterate したいってことか？
for (Map.Entry<K,V> e : m.entrySet()) { K k = e.getKey(); V v = e.getValue(); }
for (K k : m.keySet()) { V v = m.getValue(k); }
用途に応じて好きな方を使え。
そういう意味の質問でないならお前の日本語が悪いから知らん
646:デフォルトの名無しさん
09/02/10 01:18:54
なんだその暗号は
647:デフォルトの名無しさん
09/02/10 01:44:32
アルファがベータをカッパらったらイプシロンした。なぜだろう
648:デフォルトの名無しさん
09/02/10 10:02:27
range based for loop
649:デフォルトの名無しさん
09/02/11 00:47:28
Uncopyableパターンってどういうときに使ってますか？
650:デフォルトの名無しさん
09/02/11 01:03:38
あ、GetInstanceで参照を返すようなSingletonオブジェクトの場合は
受け取り側の変数に参照ではなく実体の変数を使われないようにするために使えますね
651:デフォルトの名無しさん
09/02/11 01:39:42
>>649
面倒くさくてポインタそのまま扱ってるクラスが大量に扱われるときに
コピーコンストラクタを作らずに入れておくとか。
652:デフォルトの名無しさん
09/02/11 05:39:11
>>650 わからん
文を書き直して
653:デフォルトの名無しさん
09/02/11 07:14:15
class CSomethingManager
{
public :
CSomethingManager &GetInstance(){
static CSomethingManager instance;
return instance;
}
private :
CSomethingManager(){}
~CSomethingManager(){}
};
//CSomethingManager &instance = CSomethingManager::GetInstance();
CSomethingManager instance = CSomethingManager::GetInstance();
instance.DoSomething();
654:デフォルトの名無しさん
09/02/11 07:17:09
ユーザーがついうっかり（もしくは何も考えずに)、&を書き忘れてしまうようなことが起こらないようにするために
655:デフォルトの名無しさん
09/02/11 07:18:02
あ、つーかSingletonでコピーコンストラクタを禁止するから関係ないのかｗ
656:デフォルトの名無しさん
09/02/11 07:25:47
>あ、つーかSingletonでコピーコンストラクタを禁止するから関係ないのかｗ
ｽﾏｿ。日本語おかしすぎた
つまりUncopyableパターンでSingletonオブジェクトのコピーを出来なくする使い方があると思ったんだけど、
そもそもSingleton自体に（コピーコンストラクタをprivateで定義することで）そういう考え方が備わってるから
意味ないと気付いた
657:デフォルトの名無しさん
09/02/20 00:33:02
10個位のクラスに、同じような処理を行う長～い1個のメソッド(1000STEP超)があるのですが、
これを今度共通化するなりしてまとめようという話になり、うまくデザインパターンが利用できないかなと考えています。
（デザインパターンに当てはめる必要はないのですが・・・）
クラスA
処理１
処理２
処理３
クラスB
処理１
処理３
クラスC
処理２
処理３
とまぁ、同じような処理を行っているので、
共通クラス
処理１
処理２
処理３
と記述して、呼び出し元のクラスで通る処理を切り替えられないかなと思っているのですが、
こんな用件に対応するデザインパターンてございます？
AbstractFactoryやFactoryMethod、Templeteなどが使えないかなと思うのですが、
結局それぞれのクラスから共通している処理を抜き出しても元々のクラスと同じ数だけクラスが増えることになりそうな気がして、
それだと単に処理抜き出してクラス作っただけで終わりそうなので・・・。
デザインパターンの理解が出来てないのかとも思うので、何かやりようがあったらどなたかご教授ください。
658:デフォルトの名無しさん
09/02/20 07:16:10
A、B、Cの処理ABCが全て同じならクラスは一個でいいだろ
クラス
処理A()
処理B()
処理C()
クラス a = new クラス()
クラス b = new クラス()
クラス c = new クラス()
微妙に違うならインタフェースを作って継承するだけじゃ？
クラスA:インタフェース
クラスB:インタフェース
クラスC:インタフェース
private test(Iインタフェース t)
{
t.処理A()；
t.処理B()；
t.処理C()；
}
659:デフォルトの名無しさん
09/02/20 10:01:15
template method
660:デフォルトの名無しさん
09/02/20 19:55:47
>>657
オレもTemplateMethodに一票
後みんな、原本の翻訳はしないの？
661:デフォルトの名無しさん
09/02/20 21:17:50
デザパタのパターン名なんてよく覚えられるな。
覚えてるやつって丸覚えしてんの？
ちゃんと意味わかって使ってる？
662:デフォルトの名無しさん
09/02/20 21:25:00
design patterns by functional programming paradigm
とかないのかな？
663:デフォルトの名無しさん
09/02/20 21:26:24
GoF 23パターンまでぐらいなら。
意味の方は、人と話すときはその都度ググってるｗ
664:デフォルトの名無しさん
09/02/20 21:32:47
本当によく使うのは5個くらいだから名前も覚えてる。
その他は名前聞いてもああ聞いたことあるなくらいで
後からクラス図見れば十分間に合う。
暗記力のテストじゃないんだし。
665:デフォルトの名無しさん
09/02/20 21:37:58
perlの演算子覚えるのに比べれば楽勝楽勝
666:デフォルトの名無しさん
09/02/20 22:23:28
デザパタの生まれた経緯を考えると名前で呼び合うのが自然なんだろうな。
でもなんかしっくりこない。
667:デフォルトの名無しさん
09/02/21 11:55:02
>>657
別の視点から。
処理1～3が同じ引数を持つのであれば、各処理をそれぞれ一つのクラスのメソッドとした上で、
Decoratorで積み上げる、という考え方もあると思う。
Javaや.NET系のStreamをイメージしてもらうと分かりやすいかも。
668:デフォルトの名無しさん
09/02/25 11:34:59
Decoratorで処理123を組み合わせで積み上げる場合
クラスABCを生成するためにSimpleFactoryでも用意してあげた方がいいのかな？
669:デフォルトの名無しさん
09/02/25 16:51:48
URLﾘﾝｸ(codepad.org)
・基底クラスにfactoryを持たせてみた
・decoratorパターンってhookだなぁと思った
・大量のdecoratorを使うときは定義にマクロを使ったらいいかも
・posthookとprehookの形にできるようにすればもっと柔軟に扱えるかもしれない
670:デフォルトの名無しさん
09/02/25 17:06:38
>>657
なんかすっごい、デザパタ以前の問題の気がｗ
OOPに嗜まずしてデザパタ適応は無理。
671:デフォルトの名無しさん
09/02/25 20:37:44
卑下することは無いと思うけど、別のパラダイムだよな
宣言型のプログラミングじゃなくて、動的な奴
で、こう言うのってなんて言うんだ？
672:669
09/02/25 20:53:45
ガーンこういうのdecoratorって言わないのかー
ちょっとゴフ見直してくるわ
673:デフォルトの名無しさん
09/02/25 21:02:07
>>670
たぶんOOP以前の問題だろうな
答えてる方もあやしいな、Decoratorなんて目的が違いすぎる
674:デフォルトの名無しさん
09/02/25 22:05:33
何でもかんでもデザパタ使えばいいと思ってる奴らが多そう。
675:デフォルトの名無しさん
09/02/25 22:18:18
なんでもかんでもhookを使って実装しているemacsに対してひとこと
676:デフォルトの名無しさん
09/02/25 23:16:05
>>674
オマエがそう思うならそうなんだろ オマエの頭の中では
現実は逆だ。コード設計の意図を次使う人に少しでも伝える為に
藁にもすがる思いでデザパタを入れておく
677:デフォルトの名無しさん
09/02/26 02:15:13
>>674
同感だな
無理やり導入された名ばかりのパターンは害悪でしかない
>>657に対するDecoratorがいい例だし、Templete Methodも使うべきじゃないだろう
678:デフォルトの名無しさん
09/02/26 02:27:43
静的に結合されるcommand patternのようなものを作ればいいんだな
よしやってみる
679:デフォルトの名無しさん
09/02/26 03:03:58
いや>>669が最初からDecoratorでない
もういいよｗ
こういう流れ知ってるからｗ
わざと煽らなくていいし、いいたいことはいったし
680:669
09/02/26 07:28:39
>>679
とりあえずどこがdecoratorじゃないか教えてよ
681:デフォルトの名無しさん
09/02/26 09:52:32
>>657
FactoryMethodパターンは生成に関するパターンでつよｗ
AbstractFactoryパターンはオブジェクト郡の生成に関するパターンでつよｗ
AbstractFactoryパターンを勘違いしちゃってる人が多いでつ。
682:デフォルトの名無しさん
09/02/26 10:25:05
657は、DecoratorかTemplete Methodでググって要求に合う物を使えば良いだろう
>>669はDecoratorになって無いと言うのがよく解らん
C++のobj->method()->method()の記述が何か別な意味でも持つのか？
OOP的な意味で
683:デフォルトの名無しさん
09/02/26 18:45:17
>>680
>>679は↓だからスルーするがよし
URLﾘﾝｸ(blog.livedoor.jp)
684:デフォルトの名無しさん
09/02/26 20:16:39
>>681
>>657はたぶん処理１～３の中にそれぞれクラスＡ～Ｃに対応した処理の分岐があると
言っているんだろう。
だからクラスＡ１～Ｃ３を作って、Ａ１～Ａ３を生成するＡファクトリ……のような感じで
AbstractFactoryパターンを適用し、その際の共通の部分に対しFactoryMethodや
TempleteMethodを適用しようと考えたんだろう。考え方自体はそれほど間違ってない。
685:デフォルトの名無しさん
09/02/27 10:43:13
Factory Method パターンはインスタンス生成の抽象化を目的としているのに対して、
Abstract Factory パターンの目的はあくまでも関連するインスタンス群の生成 API の集約化である。
異なる目的を達成するための手段がたまたま似たような形となったに過ぎない。
686:デフォルトの名無しさん
09/02/28 11:57:36
俺の好きなデザパタ。ベスト3+α。
1) Mediatorパターン
相互作用をこいつに任せると爽快。
相互作用の記述のみに特化したクラス、
という明白な目的を持てるのも嬉しい。
2) FactoryMethodパターン
今でもポツポツこれ使う。
インスタンス化をサブクラスに任せる。自由なような不自由なような。
このパターンが好きなのは某JavaMLなどで○木さんが暴れていたのを見るのが好きだったから。
3) Observerパターン
通知する側される側、で分けちゃうのが何よりスカッとする。
3.1) Stateパターン
これを知ったとき、「ああ、これがOOPか…」と感動した覚えが。
687:デフォルトの名無しさん
09/02/28 12:16:18
>>686
俺も同意だな
初心者には魔法っぽく見えるのはこんなもんでしょ
ところで、SINGLETONは旨いのかな？
スコッチの話なんだが．．．
688:デフォルトの名無しさん
09/02/28 20:37:06
この４つは魔法っぽく見えて他は見えないのか、その差が分からないな
Observerは割と人気がありそうだけど、他は結構変わった感性な気がする
689:デフォルトの名無しさん
09/03/01 10:48:42
デザパタは初心者にとって魔法に見えるというより、
ムダなものに見えてると思う。実体験ではそう感じた。
1) ムダに仕組みを複雑にして、ワケのわからんクラスが増えてしまう
2) デザパタだのなんだの言うけど、こんなの前から似たようなのやってる。
Cでも出来る（とか言ったり）、テンプレートでもできる（とか言ったり）、
OOPLじゃなくてもできる（とても気軽に言う）、
これって○○パターンの派生（気軽に定義をぼやかす）と言えるんじゃね（と言ったり）。
そう思うんなら、せめて無理矢理使うのだけはやめてほすぃ（´；ω；｀）
690:デフォルトの名無しさん
09/03/01 14:50:45
>>689
そりゃそうだろう。
極論すれば、よく見かけるのに名前を付けただけ。
691:デフォルトの名無しさん
09/03/01 15:01:11
デザパタってクラス図とかも状況に応じて変化するんでしょ？
あんまり意識しすぎても意味ない気がするんだけど…
692:デフォルトの名無しさん
09/03/01 16:37:27
それがどうした
693:デフォルトの名無しさん
09/03/03 10:06:50
ぼく
694:デフォルトの名無しさん
09/03/03 10:28:19
> デザパタだのなんだの言うけど、こんなの前から似たようなのやってる。
デザパタの本を渡した新人が9割9分返してくる言葉ｗｗｗ
695:デフォルトの名無しさん
09/03/03 10:49:24
結局のところ、デザパタは難しいんよ。
だから、知ったか大発生になるんよ。
デザパタの価値を知るのは、
「設計の困難＞デザパタ学習の困難」
な場合だけだよ。
デザパタ適応で何が柔軟になるのか、
パターンをカタログ化して嬉しいのか、
そこがピンと来ないんよ。
設計で苦しんでないと、ピンと来ないんよ。
696:デフォルトの名無しさん
09/03/03 11:42:11
デザパタ覚えたての新人が増えたようだな
悪い方に育ってないが、デザパタはそんな仰々しいもんじゃねーよｗ
697:デフォルトの名無しさん
09/03/04 04:08:05
デザインとかいってるけどその名にふさわしいのって一部だけだろ
シングルトンなんてただのコーディングテクニックっていうレベルのものじゃん
698:デフォルトの名無しさん
09/03/04 05:24:29
ところで、SINGLETONは旨いのかな？
スコッチの話なんだが．．．
699:デフォルトの名無しさん
09/03/05 02:04:50
そのネタ定期的にみるな。
700:デフォルトの名無しさん
09/03/05 09:49:09
>>697
>>690
> 極論すれば、よく見かけるのに名前を付けただけ。
701:デフォルトの名無しさん
09/03/05 14:02:47
多分だが、>>697 は「デザイン」の意味をよく解ってない。
702:デフォルトの名無しさん
09/03/06 03:22:16
どうでもいいわ
703:デフォルトの名無しさん
09/03/13 03:37:19
Visitorはダブルディスパッチの模写だ、とかっていうんだけど、
ダブルディスパッチって要は２つのクラス階層で処理を分岐させることではないの？
Bridgeもそうだと思って検索してみたんだけど、なんかそうでもなさげ
なんか勘違いしてる？
704:デフォルトの名無しさん
09/03/13 16:11:54
ダブルディスパッチはvisitされるオブジェクトがVisitorを兼ねる場合のパターンと
見なすこともできる。
どちらの方が都合が良いかは場合によるので一方が他方の模倣というわけではないな。
705:デフォルトの名無しさん
09/03/13 23:44:51
憧れのアーキテクトに会いに行こうぜ
待ってる。
URLﾘﾝｸ(www.microsoft.com)
706:デフォルトの名無しさん
09/03/14 04:16:54
ダブルディスパッチってのは、
例えばクラスAとBにそれぞれ3つの派生クラスa0,a1,a2,b0,b1,b2があったとして、
組み合わせによって動作が異なる場合の解決策。
これをA→Bの順で2回ディスパッチすると、最大9パターンの動作が存在しうる。
Bridgeの場合、
例えばクラスAの委譲先はa0,a1,a2,...、クラスBの委譲先はb0,b1,b2,...というように、一方向の関係になっている。
a?がBの委譲先になったり、b?がAの委譲先になったりはしない。
AもしくはBから1回ディスパッチすればいいので、最大6パターンの動作が存在しうる。
…あんま自信ないけど、こんなかんじで合ってる？
707:デフォルトの名無しさん
09/03/14 17:11:13
>705
MSはなぜ顔写真を載せようと思ったのか
708:デフォルトの名無しさん
09/03/14 17:51:35
BridgeはむしろStrategyのContextクラスがインタフェース階層化された場合と
見ることが出来る。これはモジュールを疎結合にするための構造化の手法だが、
マルチプルディスパッチやVisitorは単純に複数の引数型を動的に解決する方法であり、
つまり条件分岐の上等なやつでしかない。
709:デフォルトの名無しさん
09/03/14 17:56:16
Bridgeパターンよくわからんね。
710:デフォルトの名無しさん
09/03/14 19:12:22
>>706
パターンの目的が知りたいのか構造が知りたいのか分からないからレスもしにくいんだが、
Visitorパターンの目的はダブルディスパッチで、ダブルディスパッチは関数のオーバーロードを実行時の型によって行う動作のこと
ポリモーフィズムを使ってどうやって実現するかを考えればだいたいの人はGoFの構造を考え付くと思う
Bridgeパターンの目的はクラスのある部分を分離してしまうこと
分離元クラスと分離されたクラスがそれぞれ1つずつならpimplみたいな形になるけど、それぞれがクラスツリーを形成する場合を考えればだいたいの人は(ry
711:デフォルトの名無しさん
09/03/14 19:22:22
名前をつけることでｲﾒｰｼﾞを固定化するというか共有するというか
大抵のﾊﾟﾀｰﾝは解かってる人なら大抵思いつくことなんだと思う
解からん人や入門者にもｲﾒｰｼﾞを伝えやすいし
712:あぼーん
あぼーん
あぼーん
713:デフォルトの名無しさん
09/04/29 20:48:01
ｽﾚﾘﾝｸ(mitemite板:530-534番)
714:デフォルトの名無しさん
09/05/12 12:59:13
>3.1) Stateパターン
> これを知ったとき、「ああ、これがOOPか…」と感動した覚えが。
私は逆に、オブジェクトの振る舞いの実装がオブジェクトではなく
状態にあるってのが違和感あってだめだった
同じ「腹痛」状態でも、胃薬飲む人、我慢する人、病院行く人と
色々あるからオブジェクトそのものも状態の一つじゃないかと
715:デフォルトの名無しさん
09/05/12 13:00:29
ああアンカー忘れ
>>686
716:デフォルトの名無しさん
09/05/12 13:38:14
いや多分stateパターンの実装方法が「OOPっぽい」って思ったんじゃなかろうか
717:デフォルトの名無しさん
09/05/12 15:50:39
BridgeってCで言うところの関数ポインタ渡しだよね？
718:デフォルトの名無しさん
09/05/12 18:47:25
Stateで状態が組み合わせだった場合どうなるんだろ
719:デフォルトの名無しさん
09/05/12 19:21:13
設計ミス
720:デフォルトの名無しさん
09/05/16 16:10:06
>>717
関数ポインタ渡しはStrategyだろ
>>718
Boost.Statechart
>>710
何度見てもVisitorはキモいと思う
関数型言語のパターンマッチとかC++のtraitとかで何とかならんのか
721:デフォルトの名無しさん
09/05/16 16:19:23
>Statechart
NFA->DFAの変換をしろということか
722:デフォルトの名無しさん
09/05/22 13:47:08
C++のtraitsの方が何やってるのかさっぱり解らない
どうもテンプレートは苦手だ
723:デフォルトの名無しさん
09/05/22 17:25:35
>>722
traitsはtemplate引数の型をコンパイラに自動判別させるための仕組み
イテレータは知っての通り５つの種類がある
これをいちいち型指定しなくてもコンパイラが判別してくれるようにする
724:デフォルトの名無しさん
09/05/22 22:47:06
char_traitsのほうかもしれないぞ
725:デフォルトの名無しさん
09/05/26 23:05:22
弾幕STG作るのに最適なデザインパターンって何でしょうか？
1.弾の描画処理と当たり判定を決めるクラスと
2.弾の動きを定義するクラス
を作ってコンストラクタで1.のクラスのポインタを渡すように
してみましたが使いづらいです・・。
726:デフォルトの名無しさん
09/05/27 00:24:15
マイクロスレッド？
いや知らないけど
727:デフォルトの名無しさん
09/05/27 03:58:38
STG作ったことないけど
弾、敵機、自機、当たり判定、描画処理
で分けちゃえば？
当たり判定と描画処理はmediatorで
728:725
09/05/28 22:50:07
>>726
ググったら弾幕風講座がヒットしました。これ使うと複雑な弾幕も作りやすくなるとのことですが・・
C++で出来るんでしょうか？
729:デフォルトの名無しさん
09/05/29 01:18:50
Windowsならfiberで
URLﾘﾝｸ(msdn.microsoft.com)
その他の環境はsetjmp・longjmpで実装
「マイクロスレッドを使えば」複雑な弾幕が作りやすくなるってのは
まぁ無いと思うがね
730:デフォルトの名無しさん
09/05/29 05:04:05
コルーチンがあると意外とたのしい
そんな徹夜明けの今日
731:デフォルトの名無しさん
09/05/29 06:29:37
コルーチンからはModula-2しか思いつかない私。
732:725
09/05/30 23:45:55
>>729
OSによって変わったりするんですか？面倒そうですね・・
＞「マイクロスレッドを使えば」複雑な弾幕が作りやすくなるってのは
＞まぁ無いと思うがね
じゃあ使うのやめときます・・。
それよりMediatorパターンがどう役立つのかわかりません・・
「C++で読むデザインパターン」を読んでみましたが、MemberPtnが当たり判定用クラスで、
MessagePutで自機の座標を送るんでしょうか？
URLﾘﾝｸ(www.01-tec.com)
733:デフォルトの名無しさん
09/06/03 18:54:04
>>732
弾、敵機、自機、当たり判定、描画処理とかクラスがあった時に
お互い直接やり取りはせずに必ずMediatorを通してやるのが
Mediatorパターン
734:デフォルトの名無しさん
09/06/04 02:38:42
弾や機体といったActorが高機能でなければ、それぞれ単なる構造体にでもして
統一的なモジュール、つまりMediatorが管理するようにする。
Mediatorは内部処理が汚くなりやすいのが欠点だが
逆に泥臭い処理がどうしても必要な時にそれを閉じ込めるために使える。
735:725
09/06/04 23:41:38
どういう風に便利なのか、よくイメージがわきませんがとりあえず組んでみます
組んでみればわかるかな
736:デフォルトの名無しさん
09/06/05 02:07:12
シューティングなんて作るのは簡単なんだから、とにかくいろいろな組み方を試して
自分にあったやり方を見つけりゃいい
マイクロスレッドも一応試しとき
737:デフォルトの名無しさん
09/06/05 18:54:54
それぞれのパターンに書いてあるクラス図は
必ずその通りにしなきゃならんのかね
心意気だけ同じじゃダメ？
visitorとかあのままだと使いにくくてたまらんのだが
738:デフォルトの名無しさん
09/06/06 02:59:09
好きにいじくっておｋ。
しかしvisitorはあんまいじりようがないと思うんだが。
739:デフォルトの名無しさん
09/06/06 09:09:03
いや
クラスをデータ部分と処理部分に分離したいのはパターン通りなんだけど
分けた後のクラスの両方、もしくは片一方が
抽象/具象に分けるまでも無いときとか
740:デフォルトの名無しさん
09/06/22 23:17:31
絶対遵守のルールじゃないんだから、アレンジすればよろし。
あくまでも「よくあるパターン」を一般化したものなんだから。
741:デフォルトの名無しさん
09/06/23 09:22:08
もっといいのはアレンジの前に、
ほんとにパターンが適合できるか、
使うべきかどうかを考え直すこと。
742:デフォルトの名無しさん
09/06/23 20:52:03
デザインパターンって普通パターンの基底クラスを作って派生クラスから使うものなんですか？
743:デフォルトの名無しさん
09/06/23 20:52:59
必要だからあるのです
744:デフォルトの名無しさん
09/07/03 10:49:10
ただの用語セットだと思った方がいいんでね？
745:デフォルトの名無しさん
09/07/03 19:16:05
検索機能でオプションの項目が沢山ある場合に使えるデザインパターンを教えてください
746:デフォルトの名無しさん
09/07/03 19:19:32
>>745
オブション項目間の依存関係があるなら、
Mediatorパターン。
コレにチェック入ってる時だけこれとこれを有効、
ソレにチェック入っている時だけさらにこれらを画面に出す、とかそういう。
逆に言えば項目間の依存関係がなければ必要なし。
747:デフォルトの名無しさん
09/07/03 19:59:20
助言ありがとうございます
理解を深めて挑戦したいと思います
748:デフォルトの名無しさん
09/07/10 23:09:57
ぬこかわえ
749:デフォルトの名無しさん
09/07/10 23:11:13
誤爆しました＞＜
750:デフォルトの名無しさん
09/07/11 19:15:48
>>741
「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法」
この本にはある程度つくってからパターンにあてはめりゃいいみたいなことが
書いてあるが。
751:デフォルトの名無しさん
09/07/11 19:25:50
絵に描いた餅のウマさを説いたところでってゆう
752:デフォルトの名無しさん
09/07/13 10:36:20
保守
753:デフォルトの名無しさん
09/08/14 16:43:08
デザインパターンを意識しないで最適解を考えて作って見たら
デザインパターンだったって事も多い
ありふれてるからパターンなんだな
754:デフォルトの名無しさん
09/08/14 17:18:57
>>753
まあ、そういうものでしょ。
すでにあったものを整理することで分かりやすくする
というのが要点なんだから。
755:デフォルトの名無しさん
09/08/14 22:07:01
デザパタはよくあるパターンに名前をつけたことがすごい
756:デフォルトの名無しさん
09/08/15 17:51:49
変な萌えネームつけられなくてよかったな
意思疎通するときに恥ずかしいし
757:デフォルトの名無しさん
09/08/17 00:51:05
無味乾燥で疑念の挟みようのない命名なのは助かる。
758:デフォルトの名無しさん
09/08/17 03:12:48
でもGoFじゃないデザパタには不思議なの混ざってたとおもう
759:デフォルトの名無しさん
09/08/17 09:26:16
「Java実例プログラムによるデザインパターン入門講座」のSimple Factoryパターンとか？
パターンの名前でシンプルという単語を使っちゃうセンスとか。
しかもあの本、Factoryなのに、getXXXとしてて、元の、
Factory - create の美しい関係を軽視しちゃってる。
760:デフォルトの名無しさん
09/08/17 09:42:02
はてな界隈で俺流パターンに
アニメや漫画から引用して名付けてんのはたまに見るな
761:デフォルトの名無しさん
09/08/19 21:16:00
デザインパターンって非OOP言語にも適用可能なの？（C言語とか）
762:デフォルトの名無しさん
09/08/19 21:28:44
>>761
GoFのデザパタなら、
「オブジェクト指向における再利用のためのデザインパターン」
とある。
非OOPLでもOOP出来る、と主張したり、実践しようとしたりする人がいるので、
そいういう人に聞いてみるのがいいかも。＞非OOP言語にも適用可能なの？
763:デフォルトの名無しさん
09/08/19 21:46:20
OOPは考え方であって別にCでもOOP出来るわな。
やりやすいかやりにくいかはさておき。
764:デフォルトの名無しさん
09/08/19 23:29:02
CでOOPやると、C++が素晴らしい言語に見えるぞ。
765:デフォルトの名無しさん
09/08/20 09:13:09
>>764
俺もそう思ったクチ。
非OOPLで夢見てもどうしたって煩雑になる。
だから、CでOOP「っぽく」という着地点になってしまったり、
恥ずかしいような虚しいような気分になる。
766:デフォルトの名無しさん
09/08/20 14:45:33
stateとcommandってどうちがうんですか？
767:デフォルトの名無しさん
09/08/20 19:48:28
何を以てstateとcommandを同じだと認識してるのかが全然わからんのだが
768:デフォルトの名無しさん
09/08/21 09:22:31
>>766
あえて調べずに、テキトーなことを言うと、
1) commandパターンはアクションをパラメータ化する。
undoしたりもできるようにもやりやすいと思われ。
2) stateパターンはコンポジションでグルグル切り替える。
ゲームで言うと、
デモ画面、スタート画面、ゲーム中画面、ポーズ画面、エンディング、を切り替えたり。
それぞれの状態で、描画やキー入力、音楽などのそれぞれの処理を行う。
それらのインスタンスを並べて使っている側で、置き換えることで切り替える。
State state;が、state = titleになったり、 = demoになったりしつつ、
stateに対して、state.drowとかsate.playsoundとかしてみたりする。
以上、これらはすべてテキトーです。
769:デフォルトの名無しさん
09/08/21 11:46:31
本でMediatorの項をみるとMediatorのほうには
Medi::changed(Coll*)しか通信手段が書かれてないんですが
ほかの通信よう関数（たとえば最寄の敵の座標をくれ、など）はつけたさないで全部
changed、アドレス比較、・・・というながれでやるのが普通なんでしょうか
770:デフォルトの名無しさん
09/08/25 22:25:46
MFCとか.NET FrameworkとかってGoFのパターンがわかってたら理解早くなる？
771:デフォルトの名無しさん
09/08/25 22:41:16
遅くはならないだろうな
772:デフォルトの名無しさん
09/08/28 16:21:23
・XMLのエレメントツリーは既存の稼働中モジュールなので修正は最小限に
・ツリーに対してどのような操作があるかは未定
という状況を前提に、XMLのエレメントツリーを探索して、
特定のノードや属性値を探したり上書きしたり枝を追加したりしたいんですが、
Visitorパターンがお勧めなんでしょうか？
XMLエレメントの最上位superクラスに、再帰で自分自身と子供について
処理するメソッドを複数追加していくってのはあまりやりたくないのです。
773:772
09/08/28 17:05:09
つらつら考えてたんですが、visitorで処理を追加する場合、visitorクラスの兄弟クラスというのか、
同じインタフェースを実装するクラスを追加するのが普通なんでしょうか？
1人1殺じゃない、1クラス1メソッドという感じで。
acceptからは決まったメソッドしか呼べませんよね。。。
accept時に呼んでほしいメソッド名を第2引数で渡しておいて、
それをvisitの第2引数で戻してもらって、
visitorのvisit内でリフレクションで自分自身の指定メソッドをコールするなんてのは…やらなそうだなあ。
774:デフォルトの名無しさん
09/08/28 23:12:48
XSLTでやれば良いと思うんだけど。
775:デフォルトの名無しさん
09/09/01 01:27:11
仕事で「なるべくデザインパターンとか使わずに、分かりやすいコードでお願いします。」
って言われた。
デザパタより分かりやすいコードってどんなだ…
776:デフォルトの名無しさん
09/09/01 01:30:19
input, process, output の３つのメソッドだけが存在するコード
777:デフォルトの名無しさん
09/09/01 01:54:31
>>775
一切使わずではなく、なるべく使わずなんだよね
Template Method, Strategy, class-side Factory
あたりにとどめておけばいいんじゃない？
上記３つすら理解出来ないと言われれば、お手上げだ
778:デフォルトの名無しさん
09/09/01 02:04:57
>>775
クラスのことをモジュール、メソッドをサブルーチンと言って
相手が安心したような顔をしたら勘定系の書き方をしろということだろうな。
779:デフォルトの名無しさん
09/09/01 11:05:52
メソッドを関数と言うとかそういったやつだなｗ
780:デフォルトの名無しさん
09/09/01 11:21:17
マジレスだが、「わかりやすいコード」が力点だろ。
必要ならデザパタを理解させればいいじゃん。
781:デフォルトの名無しさん
09/09/01 13:24:43
是非うちの老害どもに理解させてやってくれ。
猿に教える方がまだ楽だと思うがね。
782:772
09/09/01 16:06:04
>>774
2つのXMLを両方チェックしながら操作したいのと、
XSLTはデバッグしにくいので…
783:デフォルトの名無しさん
09/09/10 00:40:14
「Java言語で学ぶデザインパターン入門」という本を持っているのですが、それの第２版っぽい
「増補改訂版Java言語で学ぶデザインパターン入門」との差分って分かる方いますか？
今度、デザインパターンを勉強するのですが、増補改訂版を新しく買った方が良いでしょうか？
784:デフォルトの名無しさん
09/10/28 00:54:06
ＧｏＦじゃないけど、DAOパターンについて質問。
DAOってWebサービスからXML取得してビーンにして返す処理も範疇？
パッケージレイアウトでそんな処理をdaoパッケージに入るべきか迷った。
785:デフォルトの名無しさん
09/10/29 17:34:20
アダプタパターンべんりすなぁ
786:デフォルトの名無しさん
09/11/07 23:27:55
StrategyパターンとTempleteMethodパターンの違いがよくわかりません。
教えてください。
787:デフォルトの名無しさん
09/11/08 13:15:03
>>786
ほかのクラスのオブジェクトに処理を任せる（委譲）のがStrategy
自クラスのサブクラスで処理を実装するのがTemplate Method
言葉だけでは分からないと思うので、実装例(Java)を
[Strategy]
class Sample {
private IHoge _internal;
public void Method() {
_internal->Method_A();
_internal->Method_B();
}
}
interface IHoge {
void Method_A();
void Method_B();
}
class HogeHoge implements IHoge {
public void Method_A() {}
public void Method_B() {}
}
（つづく）
788:デフォルトの名無しさん
09/11/08 13:16:37
>>787のつづき
[Template Method]
class SampleParent {
public Method() {
this->Method_A():
this->Method_B();
}
protected abstract void Method_A();
protected abstract void Method_B();
}
class Sample extends SampleParent {
protected void Method_A() {}
protected void Method_B() {}
}
この場合、構造的に違いはあれ、やってることに違いは無い。
おそらくこのような実装例をみて、違いがわからないと感じたのではないでしょうか？（つづく）
789:デフォルトの名無しさん
09/11/08 13:39:35
>>788のつづき
Strategyのメリット
処理の差し替えが容易
上の例では分かりにくいが、例えばMethod_A(),Method_B()のバリエーションが、4つずつあった場合、Strategyであれば、
public void Method() {
_internal_A.Method();
_internaj_B.Method();
}
としていれば、組み合わせはMethod_A(),Method_B()あわせて、8通りとなる
一方、Template Methodの場合、４×4で16通りの組み合わせになる。これはバリエーションが増えれば増えるほど、差が開くことになることを意味している。
デメリットは、処理をほかのクラスに任せてしまうため、Method()の処理を確認するのにあちこちをみなきゃならなくなる。
（つづく）
790:デフォルトの名無しさん
09/11/08 13:48:51
>>789のつづき
逆にMethod_A(), Method_B()のそれぞれでバリエーションが現れるのではなく、その組み合わせでバリエーションが発生する場合は、Template Methodが向いているといえる。
例えば、各ファイルを読み込むクラスを考えると、テキストファイル、画像ファイルなど、オープン > 読み込み > クローズがファイルの種類のバリエーションとなるため、Template Method向きとなる。
これを、無理してStrategyにしてしまうと、逆に分かりづらくなる気がしない？
P.S.
>>787, 788はJavaの例っていってるけど、ぜんぜんJavaじゃないです。ってゆうかコレ何言語？。スマン
791:デフォルトの名無しさん
09/11/08 14:00:52
最後に、StrategyとTemplate Methodの使い分けについて。
機能を分解する際、基本的にStrategyを使う。
ただし、上の例の様に、組み合わせでバリエーションが現れる場合は、Template Methodの適用も考える。
Tmplate Methodのほかの適用例として、Abstract Skelton Classってのもある。詳細はググってもらうとして、簡単に書くと
インターフェース > 抽象クラス > 実装クラスというようなクラス構成のこと
あと、Strategyが理解出来る様になると、委譲型Adapter, Decorator, Chain of Responsibilityなどの、派生するパターンも理解出来る様になると思う。
とりとめの無い文章なって、ごめんね。
792:デフォルトの名無しさん
09/11/08 14:00:55
よくがんばった
793:786
09/11/08 17:06:51
TemplateMethod とStrategyについて質問したものです。回答ありがとうございます。
でもわかりません。
「MethodA(),Method_B()のバリエーションが、4つずつだと」というのはStrategyパターンでは
IHogeをimplementsすつクラスが４あるということですよね。
一方TemplateパターンにおいてはSampleParentをextendsするクラスが４つあるということですよね。
そういうイメージの中、８通りとか１６通りというのは何の数を表しているのでしょうか？
16通りというのはわかります。AB４つずつあるので全部を表現するには新たに１６個のサブクラスが必要になる。
けれどもStrategyの方はよくわからないんです。interfaceクラスをAとBごとに２つ作るということですか？
（つづく）
794:786
09/11/08 17:11:41
class Sample {
private IHogeA _internalA;
private IHogeB _internalB;
public void Method() {
_internalA->Method_A();
_internalB->Method_B();
}
}
interface IHogeA {
void Method_A();
}
interface IHogeB {
void Method_A();
}
class HogeHoge implements IHogeA{//これが４つ
public void Method_A() {}
public void Method_B() {}
}
class HogeHoge implements IHogeB{//これが４つ
public void Method_A() {}
public void Method_B() {}
}
てことなのでしょうか？
795:786
09/11/08 17:12:54
これなら新規に追加するのは８個とおもうのですが。
796:デフォルトの名無しさん
09/11/08 21:09:33
>>794
8通りという言い方は、良くなかったかな。
以下の様に合計8つのサブクラスを作るってことがいいたかったのよね。
interface IHogeA {
void Method_A();
}
interface IHogeB {
void Method_B();
}
class HogeHoge_1 implements IHogeA{
public void Method_A() {}
}
class HogeHoge_2 implements IHogeA{
public void Method_A() {}
}
// HogeHoge_3, HogeHoge_4...とつづく
class AheAhe_1 implements IHogeB{
public void Method_B() {}
}
class AheAhe_2 implements IHogeB{
public void Method_B() {}
}
// AheAhe_3, AheAhe_4とつづく
797:デフォルトの名無しさん
09/11/08 21:19:23
>>793
一方、Template Methodについては、
Method_Aのバリエーションをそれぞれ、A1, A2, A3, A4
Method_Bのバリエーションをそれぞれ、B1, B2, B3, B4
としたとき、
全てのバリエーションを網羅したい場合には、
(A1, B1), (A1, B2), (A1, B3), (A1, B4),
(A2, B1), ...., (A2, B4),
(A3, B1), ...., (A3, B4),
(A4, B1), ...., (A4, B4)
の、16のサブクラスを作る必要がある。
798:デフォルトの名無しさん
09/11/08 21:40:37
StrategyとTemplate Methodを比較した場合、規模が大きくなるにつれて、
Template methodの方がクラス数が爆発的に増大する可能性がある。
ここだけをみれば、Strategyの方が優れている様に見えるけど、
そうではなく、使いどころを誤った場合、そのようなカオス状態になるということ。
十分粒度が細かくなると、
Method_A()とMethod_B()でそれぞれバリエーション化することは、ほぼなくなるため、
>>790でも言ったように、Template Methodでも問題なくなってくると思う。
俺の場合、規模の大きなものを多階層化でクラス分解する場合、委譲型(StrategyやDecoratorなど）で粒度を細かくして行き、
末端のバリエーションに対して、抽象クラス型(Template Method)を適用するようにしてる。
また階層化のクラス分解については、アーキテクチャパターン
(Model-View-ControllerとかPresentation-Abstract-Cntrolとか）について調べてみるといいかも
799:デフォルトの名無しさん
09/11/20 04:49:20
Gof本の151ページに描いてある、Adapterパターンの「適用可能性」について、
・まったく無関係で予想もつかないようなクラス
（必ずしも互換性のあるインタフェースを持つとは限らない）とも協調していける、
再利用可能なクラスを作成したい場合。
って言うのがあるんですが、これの意味がわかる方っていらっしゃいますか？
800:デフォルトの名無しさん
09/11/20 09:22:10
ラムダとか使えばあらかたのデザパタがいらなくなると聞きました。
まとめてエロイ人。
801:デフォルトの名無しさん
09/11/20 12:13:47
>>800
とか が気になるけど
Lambdaで不要になるのはStrategyパターン
802:デフォルトの名無しさん
09/11/21 08:22:02
Template系の半分はいらなくなるわな
803:デフォルトの名無しさん
09/11/21 18:37:22
そうか？
804:デフォルトの名無しさん
09/11/21 20:43:51
ファクトリーでサブクラスの生成を管理しようとしてるんだがこれサブクラスの数がめっちゃ増えてくると結局すごい大変な労力を支払わされない？
今のところ New<T>(){ return new T; } の関数ポインタとmap<TagType, NewType>を使って管理してるんだが、もっと楽な方法はないだろうか
805:デフォルトの名無しさん
09/11/21 21:37:54
パッと思いつくのは map にしてしまっているのでファ
クトリ群を継承とか使って階層的に出来ない点かなぁ…。
ケースバイケースだろうけど。
806:デフォルトの名無しさん
09/11/23 00:12:35
DataMapperパターン
ってどうやって実装すればいいのですか？
807:デフォルトの名無しさん
09/11/23 10:37:09
>>806
節子、それGoFとちゃう。スレ違いや。
808:デフォルトの名無しさん
09/11/23 10:52:17
ORマッパ？
809:デフォルトの名無しさん
09/11/23 15:42:14
やーここはGoFに限定するスレではないべ？
とはいえ>>806はだいぶ狭いドメインの話題のようだが
810:デフォルトの名無しさん
09/11/25 00:46:23
DataMapperパターン
もわからねぇのかこの腐れ外道供
811:デフォルトの名無しさん
09/11/25 21:57:36
わかってるのはお前だけだからがんばれ
812:デフォルトの名無しさん
09/11/29 16:56:36
C++の評議委員がGoに乗り換えするらしいぞ
813:デフォルトの名無しさん
10/01/23 02:24:23
つうか、デザインパターンって流行らないよな
シンプルなことをわざわざ手間をかけて複雑にしてるのばかりだし
814:デフォルトの名無しさん
10/01/23 02:42:48
最近では、言語やフレームワーク、ライブラリに組み込まれてるからね。
コーダーレベルなら、別に意識しなくても良いと思うよ。
815:デフォルトの名無しさん
10/02/06 20:38:41
んなことないだろ。少し複雑なプログラムになれば、いくらでも使うだろ。
別に意識しなくとも自然とGoFのデザインパターンのようなものに行き着く。
816:デフォルトの名無しさん
10/02/06 23:37:34
デザインパタンは、本来は複雑なものをシンプルにするためのものだよね。
その辺の感覚の分からない人の場合、複雑になったり無駄が増えても
とにかくデザインパターンを使えばよい設計になると勘違いしがち
817:デフォルトの名無しさん
10/02/07 01:12:39
根本から理解してない奴増えたな・・・
818:デフォルトの名無しさん
10/02/07 03:47:18
パターンに名前付けたのがすごいし
819:デフォルトの名無しさん
10/02/07 14:43:35
言葉遊びがたまに役に立つこともある、っていう匙加減が難しい。
全く役に立たないと思ったり、逆に、口先だけで何でも解決すると思ったりする。
820:デフォルトの名無しさん
10/03/30 01:53:09
基底クラスAがあり
派生クラスBA クラスCAはクラスをAを継承しています。
クラスBA、CAを作成しわけるクラスFを作成しました。
A b = F.Create(0); // ← クラスBAのインスタンスを作成
A c = F.Create(1); // ← クラスCAのインスタンスを作成
共通のメソッドMethod()はクラスBA,BCでそれぞれオーバーライドされています。
これで、
b.Method();
c.Method()
とすれば、インスタンスによってことなる挙動ができますが、
新たなるクラスDAを作成しました。
DAはnewするときにもうひとつ情報が必要な為、
F.Create(int)→F.Create(int,double)に変更し問題はないのですが
クラスBA、CAにはまったく必要のない情報なのに
A b = F.Create(0,1.0);
A c = F.Create(1,2.0);
A d = F.Create(2,3.0);
みたいにやっています。かなり不自然とと思っています。
どうでしょうか？
821:デフォルトの名無しさん
10/03/30 03:19:26
どうて言われてもな。
CreateB()、CreateC()、CreateD(double)じゃ駄目なのか？