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)じゃ駄目なのか？