[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 05/09 16:29 / Filesize : 193 KB / Number-of Response : 612
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

「【GoF】デザインパターン 6



1 名前:デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ]
前すれ

〔隔離〕デザインパターンは本当に必要か?〔スレ〕
pc8.2ch.net/test/read.cgi/tech/1119348596/


562 名前:デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:05:46 ]
>Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思います
例えばどんな時?

デザパタの本にありがちな、
Shape インタフェースに draw メソッドがあって
Circle でも Triangle でも draw 呼べば片付きますよ、
的な話って、いかにも説明のための説明って気がしてならん。

563 名前:デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:20:03 ]
ここまで一切コントローラの話題が無い件

564 名前:デフォルトの名無しさん mailto:sage [2008/06/19(木) 07:30:42 ]
>>562
まさにそういう時。
アルゴリズムでdraw可能なオブジェクトをいくつかはじきだす。
その時にそいつにdrawメソッドを持たせておいた方が都合がいいのでそうしているが、
癒着してるようで気がかり。

565 名前:デフォルトの名無しさん mailto:sage [2008/06/19(木) 19:37:43 ]
ほれ、答えだ
www.fujigoko.tv/rev/prof/doc4/index.html

566 名前:デフォルトの名無しさん mailto:sage [2008/06/19(木) 20:07:01 ]
長い;;

567 名前:デフォルトの名無しさん mailto:sage [2008/06/20(金) 23:52:54 ]
>>565
当たり前すぎるくらいに当たり前のこと書いてるな。
でも、この当たり前が理解できてないやつが殆どだ。

モデル自体が保存メソッド持ってるフレームワーク見せられて
「なんでこんな設計なの?」「便利だから」
意味不明の回答で泣きそうになった。

次の会社でも探すか。

568 名前:デフォルトの名無しさん [2008/06/21(土) 00:25:48 ]
データモデルと永続化は別か,そうかそうか

569 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 00:50:45 ]
>>567
あたり前田のクラッカーってどうなったんだろう?

570 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 09:28:30 ]
> モデル自体が保存メソッド持ってるフレームワーク見せられて

普通じゃん。



571 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 09:42:35 ]
>>567
むしろ保存とか読み込んで再構築とかいう手間を見せ付けてはいけない

572 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 13:33:10 ]
シリアライズ機能くらい普通じゃん

573 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:01:39 ]
シリアライズを提供することと保存の主体であることは別じゃね?

574 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:06:23 ]
Save(IOutputStream* stream)
Load(IInputStream* stream)
みたいに外部に保存主体があるわけじゃなくて、
まさか内部に保存主体があるのか?

575 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:12:35 ]
dbの話じゃないの?

576 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:23:23 ]
>>574
保存主体ってなんですか><;;

# Save(IOutputStream* stream)
これだと「何を」みたいな目的語が全く存在しない

577 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 18:08:59 ]
.NET Frameworkだと、シリアライザクラスに分けてあるね。

578 名前:デフォルトの名無しさん mailto:sage [2008/06/21(土) 18:15:05 ]
クラスを分けるのは便利な面もあるけど、
保存すべき情報は外部に見せることのできる情報ばかりではないからね。
両方できるようにしてどっちにするか選択できるのが一番良い。

579 名前:デフォルトの名無しさん mailto:sage [2008/06/22(日) 09:05:38 ]
Save(PersistContext pContext)とかになってPersistContextの実装しだいでDBにもXMLにも保存できるのが吉かと。

580 名前:デフォルトの名無しさん mailto:sage [2008/07/31(木) 21:05:45 ]
>>552のAbstract Factoryの頁を読んでみたんだけど、
とても違和感を感じる、というよりはっきり言って全く間違っているように思うのだが
これは俺の方が間違ってる?

俺がおかしいなと思った点は、

(1) void Create( AbstractWeapons *AbsWep)みたいな"具体的な"値を引数で
  取るメソッドのどこが"Abstract"(抽象)なのか?
  思うに、この著者は"Abstract"の意味を取り違えているのではないか?
  確かに「武器」はAbstractWeapons という型に抽象化されてはいるが、
  Abstract Factoryの"Abstract"ってそういう抽象化のことを指しているんじゃないのでは?

(2) 1とも関係するが、著者は自分で『オブジェクト内部で作ってもらった方が、
  外部の人は渡すべき武器について知らなくて良いので楽になる』と(もっともな)事を言っているのに
  できたコードは全然そうなってない。



581 名前:デフォルトの名無しさん mailto:sage [2008/07/31(木) 22:20:23 ]
>>580
そういう疑問を持ったときは実際にプログラミングするのが早い

582 名前:デフォルトの名無しさん mailto:sage [2008/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 名前:デフォルトの名無しさん mailto:sage [2008/08/07(木) 00:49:16 ]
まぁWeaponをインタフェース名にしろと思ったな。

AbstractWeaponsImpl みたいな感じで
なんらかの共通処理を持った実装クラス名にすることはあるんだが
インタフェース名にAbstractcなんやらーってあんまりしないなあ。

宗教だけど。

584 名前:デフォルトの名無しさん [2008/09/08(月) 11:09:58 ]
あげ

585 名前:デフォルトの名無しさん mailto:sage [2008/09/08(月) 14:08:20 ]
読み始めたけど、道のりなげぇぇぇぇ。

586 名前:デフォルトの名無しさん [2008/09/08(月) 20:11:30 ]
或曰: お仕事
www.issei.org/blog/archives/000225.html

こちらのサンプルにあるような、
依存部分だけをインターフェスのContextとして取り出し、
実行時に引数にContextを渡して依存を解決するような場合の
パターン名は何かありますでしょうか?

もし、ない場合適当なパターン名としてどんなものがありますでしょうか?

587 名前:デフォルトの名無しさん mailto:sage [2008/09/09(火) 01:27:27 ]
Context と Context のユーザーが
互いにインスタンス参照をもちあう作りが
ものすごく不吉な感じするんだけど
そのあたりどうなんだろう。

588 名前:デフォルトの名無しさん mailto:sage [2008/09/09(火) 09:44:23 ]
Head Firstの本ってどう?


589 名前:デフォルトの名無しさん mailto:sage [2008/09/09(火) 19:11:26 ]
abstract Factoryパターンと、Factory Methodパターンの違いについて述べよ。
また、ファクトリパターンがどういう場合に有効なのか知るところを述べよ。
生成メソッド(例えばファイル読み込みなど)を生成すべきメソッドに持たせるとどのような不都合が起こるのかを述べよ。

590 名前:デフォルトの名無しさん mailto:sage [2008/09/09(火) 20:23:18 ]
>>588
俺持ってるけど良いよ
ホントに重要なパターンだけを優先順位を付けて展開してる、
最初は秘術的なobserverパターンから初めてるのも好感できる
observerはstrutsやMVC関連で良く使われるパターンだよね



591 名前:デフォルトの名無しさん [2008/09/10(水) 00:47:57 ]
>>590
でもピザパターンとかが無いからなぁ・・・
入門としては良書だけど、見通しが利かないってとこがちょっと。

592 名前:デフォルトの名無しさん mailto:sage [2008/09/10(水) 17:36:05 ]
Head Firstで基礎を勉強したあとの補強にいいのはGoF本?

593 名前:デフォルトの名無しさん [2008/09/10(水) 20:58:10 ]
Amazon.co.jp: Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: 本
www.amazon.co.jp/dp/4873112494
images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg

これですか?
高すぎるんですがwww

594 名前:デフォルトの名無しさん mailto:sage [2008/09/10(水) 21:00:44 ]
>>593
貧乏自慢すんなよ

595 名前:デフォルトの名無しさん mailto:sage [2008/09/13(土) 16:16:55 ]
「デザインパターンによるJava実践プログラミング」っていう本がぱっと見GoF本に似てる感じがしたんだけど、
これを読めばGoF本読まなくっていいかな?

596 名前:デフォルトの名無しさん mailto:sage [2008/09/13(土) 23:48:47 ]
どれ読んでも難解だよな
ゲームで説明しているページが一番分かりやすい。
1個だけ間違ってるのあるけど

597 名前:デフォルトの名無しさん mailto:sage [2008/09/14(日) 04:40:51 ]
GoFをまるぺけのところと照らし合せながら読むのがいいと思う

598 名前:デフォルトの名無しさん mailto:sage [2008/09/14(日) 10:29:03 ]
Head Firstシリーズのデザパタ本を読んだ後に同じシリーズのオブジェクト指向設計の本
をちょっと立ち読みしてみたら内容がかぶってる気がしたんだけど、
前者を読んだ後に後者を読む価値はあるかな?
両方読んだ人いたら教えて。

599 名前:デフォルトの名無しさん [2008/09/21(日) 15:39:38 ]
stateとstrategyの違いを教えてください。

600 名前:デフォルトの名無しさん mailto:sage [2008/09/21(日) 17:17:42 ]
実装クラスで表現されたモノによって呼び方が変わるだけで、構造上の違いはないよ。



601 名前:デフォルトの名無しさん mailto:sage [2008/09/22(月) 06:22:50 ]
Gofって所謂カタログ本だと思ってた。

>>598
ある

602 名前:デフォルトの名無しさん [2008/09/28(日) 10:00:51 ]
過疎どすな

603 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 23:50:39 ]
デザパタてはやり過ぎない不思議

604 名前:デフォルトの名無しさん [2008/10/02(木) 15:47:16 ]
渇祖

605 名前:デフォルトの名無しさん [2008/10/05(日) 14:25:10 ]
>>599
「目的が違う」ってことでいいのかな?
stateはアルゴリズムを動的に切り替えられることに意義があり、
strategyはアルゴリズムを分離することに意義がある
とか。

606 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:08:42 ]
stateの方、それ違くね?

607 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:29:00 ]
The differences between Strategy pattern and State pattern Five ’s Weblog
powerdream5.wordpress.com/2007/10/05/the-differences-between-strategy-pattern-and-state-pattern/

The difference between the two GOF patterns "Strategy" and "State"
www.c-sharpcorner.com/UploadFile/rmcochran/strategy_state01172007114905AM/strategy_state.aspx

散々議論されてきた歴史があるのでそれを参考にしたらいいと思うよ


608 名前:デフォルトの名無しさん mailto:sage [2008/10/08(水) 23:54:54 ]
Compositeってやつのみっつのくらすをひとつのクラスにすることは出来るの?

609 名前:デフォルトの名無しさん [2008/10/09(木) 12:31:35 ]
っていうか、「何でお前が勝手にルール決めてんの?つか誰?」って感じしない?



610 名前:デフォルトの名無しさん mailto:sage [2008/10/09(木) 16:31:30 ]
>>608
XMLとか



611 名前:デフォルトの名無しさん mailto:sage [2008/10/13(月) 23:36:50 ]
>>609
OOPのノウハウを共有するために呼び名を決めたほうが良いね、ってのが
デザインパターンの意義なのにルールも糞もあるもんか。

おまいが好きなノウハウに好きな名前を付けたけりゃ、そうすればいい。
それを共有しようとする奴は誰もいないだろうがなぁ。






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<193KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef