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