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

1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ] 前すれ 〔隔離〕デザインパターンは本当に必要か？〔スレ〕 pc8.2ch.net/test/read.cgi/tech/1119348596/ 191 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:58:56 ] client　→　Target 　　　　　　　　△ 　　　　　　　　 | 　　　　　　　Adapter→Adaptee TargetはClientに対するInterfaceだからAdapterがTargetを継承するのは当然なのでは？ AdapterはAdapteeに委譲するのは当然だし 192 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 06:29:05 ] >>191 当然だと思う。 でも世のデザパタ解説サイトだと 「継承」「委譲」の2種類を例として出してる場合、 「継承」ではTargetはクラス、Adapterはそれを継承する形になってて 「委譲」ではTargetはインターフェース、Adapterはそれを実装する形になってる。 本質を考えれば継承の場合でもTargetはインターフェースだろ？と思うんだけど。 (というか継承はいらねえと思われ。) オリジナルのGoF本を読んでないので分からんけど。 193 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:14:40 ] >>192 クラスでもいいのでは？ Targetとしての振る舞いに共通なものがあるのだとしたら 抽象クラスとする事もアリだと思うけど Client　→　Target 　　　　 　　　　△ 　　　　　　　　　; 　　　　　　AbstractTarget　 　　　　　　　　　△　　　　　　 　　　　　　　　　 |　　　　　　　 　　　　　　　　Adaptar　　→　　　Adaptee 194 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:29:13 ] まあ、↑みたいにするAdapterパターンの説明としては複雑になるから 省略してTargetをクラスにしてるんだと思うけど 195 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:00:04 ] クラスが悪いとかクラスじゃできないとか言ってるんじゃなくて。 Client からは統一的に扱える、同じように見えるって側面を強調するなら インターフェースでいいじゃねえかと。 委譲のパターンでもTargetはインターフェースで説明できるのに そっちの方がより無駄のない本質的な説明になるのに、 なんでクラスなの？と。 (>>192では委譲・継承とクラス・インターフェースの組み合わせが逆だった。) ↓これが一般例で、他はもう特殊例でしょ？ 　　　　　　<<interface>> client　→　Target <|・・・・・Adapter ・・・・・|> Adaptee 　　　　　　　　　　　implements　　 　 uses ひどいところでは 継承使うパターンがデフォですよ、 単一継承でいかんともしがたい時には 委譲使うパターンで回避ですよ、 に近い説明すら行ってる。 なんかもうコードが共有されるなら継承が最高の解なんだよ、みたいな。 それは15年前に通ってきた道だろう、と。 196 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:07:58 ] それをいったらデザインパターン自体が出てからだいぶ時間がたってるから 当時の説明をそのまま鵜呑みにしてもしょうがないでしょ。 もし初心者がそれ見て今の時代にアンマッチな知識をインプットしてしまう 事に懸念を感じるなら、自分で「こう解釈するのがいいですよ」って説明する サイトでも立ち上げてみればいいｗ 197 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:14:16 ] >>195 ＞↓これが一般例で、他はもう特殊例でしょ？ それは少し乱暴だと思うが・・・・・ そう熱くなるなよｗ 198 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 16:58:29 ] >>195 っていうか、「委譲」って言葉の使い方間違ってね？ 199 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 21:21:49 ] Effective C++ みたいに、時代に合わせて新しくなるデザパタ本があればいいのにな。 200 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 22:04:55 ] GoFのデザインパターンは、モデリングの世界の"Hello World" 見たいな物になってしまったンだと思うね 201 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 19:42:57 ] ほす 202 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 20:07:12 ] 「それはパターンから外れているから駄目だ」とかは全然駄目なセリフの例ですね 203 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:41:05 ] ほす 204 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 13:53:11 ] いまさらデザインパターンを語ることはあるまい 205 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:24:09 ] デザインパターンってもう語りつくされたん？ 206 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:36:31 ] 語れるほど言葉を持たないというのが正確なところかｗ 207 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 18:06:31 ] これはよく使うパターンって何？ 208 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 03:12:29 ] Iterator 209 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 07:26:27 ] Singleton、Factory、Template あたりかなぁ。 210 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:45:02 ] こんぽじっと 211 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:47:05 ] こーるばっく、こまんど、 212 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:28:34 ] 微細主義，機能分割，集団無能化・・・ 213 名前：デフォルトの名無しさん [2007/02/10(土) 20:34:33 ] 結城さんのMLってどうやって送信先メールアドレスを変えるんだ？ 進級２つ登録したから古い方だけ購読解除できればいいんだが まぁ４月になればアドレスが使えなくなるから放置でもいいんだけど 214 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 22:10:48 ] >>213 それって面白い？ 215 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 01:12:50 ] NullObjectのような、GoFの23には含まれていないパターンについて勉強したいのですが、 みなさんはどのように勉強されましたか？ 個人的には本で勉強したいので、参考になる書籍などを示してほしいです。 216 名前：デフォルトの名無しさん [2007/02/12(月) 19:33:51 ] age 217 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 19:38:25 ] boostのコードを読むと、すごい勉強になった 218 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:29:48 ] >>217 kwsk 219 名前：デフォルトの名無しさん [2007/02/12(月) 20:55:12 ] デザインパターンを勉強すると、 自分が頭良くなってスゴイSEなったってカン違いするヤツ、 多いよな・・・ 220 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:59:00 ] 一人前のSEって感じでしょ 221 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 11:29:01 ] GOFデザインパターンはマイクロアーキテクチャーの一種に分類され、 その対象領域は一般にプログラムと呼ばれている、いわゆる動作単位であるから、 どの様に考えてもプログラマの職域に属する事項であるかと 222 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:23:41 ] >>221 「マイクロアーキテクチャー」って一体何の事だか、 分かっている？ 223 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:58:25 ] SEではないな 224 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 08:14:40 ] 半導体設計が思い浮かんだ。 225 名前：デフォルトの名無しさん [2007/02/19(月) 23:50:05 ] >>219 結局デザインパターンって、フレームワーク作る時にしかあんまし使わないかなあ 226 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 23:54:41 ] 勉強が足らんな 227 名前：デフォルトの名無しさん [2007/02/20(火) 00:13:46 ] >>226 kwsk 228 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:24:41 ] フレームワーク使う側でも使う。 java.lan.io.* なんてデコレータパターンの塊だし コレクションフレームワークはそのままイテレータパターンの実装だし。 フレームワークが面倒見てくれない粒度の細かいオブジェクトの組み立てには それはもうファクトリやらテンプレートやらのオンパレードさ。 229 名前：デフォルトの名無しさん [2007/02/20(火) 00:33:57 ] >>228 ｉｏ自身がデコレータでしょ 使ってる側は意識しないはず イテレータは素人でも使うよ 230 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:43:25 ] イテこまし…いやなんでもない 231 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 05:36:30 ] つーか、あるものを利用するだけで自分では使わないんだｗ 232 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 15:50:13 ] プログラマなんてみんなあるものを利用するだけでしょ アセンブラでもマシン語でも。 233 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 23:18:29 ] いんや 234 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:22:45 ] ｺﾞﾌ！ 235 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:07:48 ] ちょっと皆さんに助言願いたい事があります。 例えば、ゲームプログラムなんですが、 あるキャラクタークラスYがあったとしてキャラクタークラスは内部に AI処理を担当するクラスZをコンポジションでもっていたとします。 で、AIのタイプにはいくつかあって（タイプA/B/C）、それぞれの タイプにも、細かく引数によってパラメータの指定ができるとします。 AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジションで 持っていてもまぁなんでもいいのですが、 他のクラス（ゲーム進行管理クラスなど）からそのキャラクターのAIの動作を 変更するために、例えばAI処理をタイプBに変更、そしてB特有のパラメータを設定できるとします。 こういう事を実現するために、現在はクラスZを持っているキャラクタークラスにも、 タイプA,B,Cいずれの処理に切り替えるメンバ関数、あるいはそれぞれのタイプ別にパラメータを 設定する独立したメンバ関数を設定しています。 でもこういう事をすると、AIのタイプを増やすたびにキャラクタークラスにもそれに応じた メンバ関数を追加する手間が必要になってしまいます。 もっとスマートなやり方は無いものでしょうか？ 236 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:14:56 ] 他のクラス　──→　AIクラス 　　　　　　　　　　　　　　△ 　　　　　　　　┌───┼───┐ 　　　　　　　　│　　　　 │　　　 　│ 　　　　　　　　タイプA　　タイプB　　タイプC だろ普通 237 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:17:20 ] >>235 ＞キャラクタークラスは内部にAI処理を担当するクラスZをコンポジションでもっていたとします これ、Composition とは言わないだろう…… ＞AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジション だから、Composition じゃなくて Strategy ＞からそのキャラクターのAIの動作を変更するために 今度は State？ ＞にもそれに応じたメンバ関数を どういうメンバ関数？　それほど増えるとも思えないが。 ＞もっとスマートなやり方は無いものでしょうか？ 無い。これが上限であり下限。 割りきりが必要。極端に変な動作はさせないほうが吉。 238 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:00 ] ｴｴェェェ・・・？ 239 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:40:37 ] >>235 他のクラスオブジェクトへの参照を持つ事をコンポジションというのではないのですか？ ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 いっそZへの参照を利用側に渡してしまおうかと思ったのですが、内部のオブジェクトの参照を 外部に渡してしまうのは好ましくないようなので、どうしようかと思ったのです。 Zのメンバ関数のいくつかは、キャラクタクラス以外のクラスから呼んで欲しくないものがあるので・・・。 240 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:48:58 ] 書き間違えました。 誤：ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 正：キャラクタークラスにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 です。 241 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:35:06 ] >>240 ABCがAIだろうがキャラクターだろうが同じじゃハゲ 242 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:44:26 ] 　　　　　　　　　┌─→AIクラス 　　　　　　　　　│　　　　　◇ 他のクラス　─┤　　　　　│　　　　　　　　　　　　 　 　　　　　　　　　│　　　　　↓　　　　　　　　　　　　 　 ┌→キャラクターA 　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB 　　　　　　　　　│　　　　　　　　　　　　　　　　　 　 　 └→キャラクたーC 　　　　　　　　　│　　　　　　　　　　　　　 　 　　 　 　 ┌→キャラクターA用のセッター 　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB 　　　　　　　　　　　 　　　　　　　　　　　　 　 　　 　 　 └→キャラクターA用のセッター 243 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:45:17 ] まちがいたｗ　　　　　　 　　　　　　　　　┌─→AIクラス 　　　　　　　　　│　　　　　◇ 他のクラス　─┤　　　　　│　　　　　　　　　　　　 　 　　　　　　　　　│　　　　　↓　　　　　　　　　　　　 　 ┌→キャラクターA 　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB 　　　　　　　　　│　　　　　　　　　　　　　　　　　 　 　 └→キャラクたーC 　　　　　　　　　│　　　　　　　　　　　　　 　 　　 　 　 ┌→キャラクターA用のセッター 　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB用のセッター 　　　　　　　　　　　 　　　　　　　　　　　　 　 　　 　 　 └→キャラクターC用のセッター 244 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:49:25 ] Javaで書くとこんな感じ 　　　AICharactor iaChar = ai.getCharactor(); 　　　PropertySetter setter =　PropertySetterFacotory.getSetter(aiChar); 　　　setter.set(iaChar,otherObject); 245 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:53:52 ] プロパティじゃなくてパラメータだなｗ 246 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 03:01:46 ] >>235 そういうときこそ継承使えばいいじゃない 247 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 11:37:58 ] 全 AI が必要とするパラメータを一つの巨大なクラスに集めて、それを渡すことにするとか。 各 AI はそのオブジェクトを一つ受け取って、自分に関係するメンバだけ触ることにすれば、インターフェイスは共通化できる。 AI が増えても、そのクラスにメンバを増やすだけで、他は一切書き換えずに済む。 再コンパイルは必要だろうけど。 248 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 15:49:22 ] みなさん、ありがとうございます。 >>247 その方法も考えていました。なんかオブジェクト指向的に完璧な解決策じゃない 気がしていたんですが、それが一番手っ取り早いのかもしれませんね。 249 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 16:03:31 ] ・・・・・・・・ 250 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 18:16:05 ] パラメータをいじる権利のある人がAIを生成して もしも途中でパラメータを変更する必要があるならそのままそいつが参照を持ちつづけ キャラクタは自分が生成されるときにAIへの参照を貰い受けるような形のほうがいいと思う パラメータを設定できないtickするだけのインターフェイスで貰えるならなお結構 251 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:45:05 ] >>235 なんかよくわからんけど、直感的にBridgeパターンが頭に浮かんだ。違うかな。 252 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:59:31 ] オブジェクト指向ってホントウに垣根が高いんだな・・・・ 253 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:18:21 ] たぶんずれると思うけど。 ・ゲーム進行はキャラとAiBuilderを知ってる。キャラへAiをセットする ・キャラはAIだけ知ってる ・AiとABCTypeはAiBuilderによって生成される ゲーム進行 ----> AiBuilder------- ↓ ↓ | キャラクタ ----> <Interface>Ai | △ | | ↓ AType BType CType 254 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:20:08 ] ずれすぎてだめだった。 ABCはAiのサブクラスね。 255 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:15:43 ] 全角スペースを使い玉へ 半角スペースは続けて使うと一つにまとめられちゃうのだ 256 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 10:19:21 ] テスト      あああ 257 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:41:28 ] interaface Param{ } interface Ai{ 　doHoge(Param param); doFuga(Param param); } interface AITarget{ 　setAi(Ai ai); Param createParam(); } class Character implements AITarget{ } 258 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 00:52:10 ] >>256 これは専ブラが半角スペースをユニコードに変換するタイプなんでおｋなんだよ 259 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 09:53:49 ] キャラクターなんていうデカイ括りがなんで必要なのかわからん まずキャラクターありきでデザインするのよそうよ 260 名前：デフォルトの名無しさん [2007/03/02(金) 21:48:08 ] 今回初めて Visitor パターンを使ってみようと思ったんだけど、 Visitor パターンって巡回順(次のaccept) は、Element に書いた方が、巡回順が再利用できていいと思うんだよね。 でもそうすると、巡回終了処理用のメソッドが欲しくなる。 結城さんの本しか見たことがないんだけど、 この実装方法は、正攻法？　邪道？ ex) public void accept(Visitor vis) { 　　vis.visit(this); 　　Iterator it = contents.iterator(); 　　while(it.hasNext()){ 　　　　((Element)it.next()).accept(vis); 　　} 　　vis.visitEnd(this); //← これのこと } 261 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 23:54:31 ] 最近はaspectあるからVisitor要らなくね？ 262 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:40:04 ] なわけないだろ。 aspectとかＤＩって害虫だろ。 そんな迷走してるより、 とっととクロージャ取り入れて、正常進化して欲しい。 263 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:47:05 ] なわけないだろ。aspectとDIは本流だろ。 264 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 03:17:43 ] AOP&DIの文脈でクロージャの話が出る理由が分からん。 265 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 07:14:09 ] それが正常進化とも思えん 266 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:17:01 ] クロージャはＤにもあるし、Javaにもいずれ実装されるからだろ。 267 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 15:14:26 ] Javasist 系は、VM が後方互換のないバージョンアップをしたとき、 手の打ちようがないよな。 Aspect がうまい具合に言語仕様に入るなんてこともなさそうだしな。 268 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:52:16 ] ランタイムでウィービングすりゃいいじゃん。 269 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 21:49:37 ] 　　　　　　　　　　　２ちゃんで煽りながらデザパタ学習した池沼が 　　　　　　　　　　　古い話題を壊れたレコードのように繰り返すスレ 270 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:07:11 ] ま 敢えて言うほどの事でもないがの 271 名前：269 mailto:sage [2007/03/14(水) 22:13:31 ] こんなスレ未だに見てる奴が居る事実に感動 元お豆のｓずきさんかな 272 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 02:19:28 ] たかひろくんのデザパタ幼稚園 273 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 10:43:46 ] >>33の発言は間違い。 274 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 09:22:19 ] ごふっ 275 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:59:37 ] 質問です。 テンプレートメソッドパターンを適用しようとして気になったのですが、 ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう？ （内容が同じになるものが複数組あります） 内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、 このままでは冗長です。 ぱっと思いつくのは、組ごとに共通のクラスを作っておいて 各コンクリートクラスは共通クラスのただのラッパーになる、という設計ですがおかしいでしょうか？ 使っているのはPHP5なので多重継承はできません。 276 名前：デフォルトの名無しさん [2007/03/26(月) 18:21:23 ] age! 277 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:05:42 ] ConcreteClassのユーザーから見て、 その「処理が同一だけど異なるクラス」とやらは 「全く同じクラス」にしてはいけないものなの？ 278 名前：275 [2007/03/26(月) 19:18:30 ] 微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。 例えば、 www.techscore.com/tech/DesignPattern/TemplateMethod.html ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に public class TanakasWoodCutPrint extends WoodCutPrint{} と public class SuzukisWoodCutPrint extends WoodCutPrint{} の二つが同じ内容になってしまう、という場合にどうすれば良いのか？という事です。 279 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:00:25 ] 木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？ 280 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:44:58 ] 差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。 もう一階層挟んだら綺麗にまとまったりしないかとか。 281 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:44:55 ] メモリが必要になったときに一度だけ生成されて、それ以降の記述では 必ず最初に確保されたメモリが使われるようなパターンは何というの？ C++風に描けば if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る aを使った処理… 全部グローバル変数にすればいいんだろうけど、使わない領域は 確保したくないって時にやる（a が不要になったときは回収してもOK） 282 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:46:53 ] >>281 しんぐるとんだろ？ 283 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:49:00 ] >281 Singleton 284 名前：275 mailto:sage [2007/03/27(火) 12:17:40 ] >>279 >>275で書いた共通クラスというのはそういうイメージなのですが、 タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？ >>280 symfonyでモデルクラスをＤＢスキーマから自動生成後、 各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。 285 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 22:52:26 ] っていうか、そのモデルは何を表してるモデルなのよ？ DBから生成されたものに後付で持たせたい機能って言う意味がわからん モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな 286 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 23:18:27 ] なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。 287 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 07:29:58 ] >>280 まず、モデルの定義を明確にしろ。 ・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、 ・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。 後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。 次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。 版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、 cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。 具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。 ここで、テンプレートパターンを使う。 　　ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass 　　ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass となるようにする。 もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、 同じConcreteStrategyクラスを生成して呼び出せば良い。 違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。 それだけの話ではないか 288 名前：２８７ mailto:sage [2007/03/28(水) 07:36:24 ] >>280ではなく>>275 289 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:14:53 ] symfonyってのをちらっと眺めた感じだと ＞・DBエンティティをそのまま表したクラス(状態) どうもこっちみたいだから、 そもそも適用するレイヤを間違ってる説が有力。 290 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:51:39 ] ODBMS屋乙。 > そもそも適用するレイヤを間違ってる説が有力。 それは前提を勝手に仮定した偏った意見に見える。 >>275の話が 　・どのようなアプリケーション・アーキテクチャ〜レイヤ構成を前提としているか 　・一つのレイヤ限定の話なのか 　・複数のレイヤにまたがった話なのか によって、いくらでも回答の仕方があるだろう。 例えば、 下のレイヤで、オブジェクトの静的状態をDBMSに格納し、 上のレイヤで、オブジェクトの振る舞いをどう扱うか という問題を仮定した場合にも、 ・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法 ・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態 　を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法 の二通りが考えられる。 >>287は、後者の立場から説明した。 291 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:58:15 ] 補足： 前者の立場でも 　　DBMSエンティティ＝静的状態＝ドメインオブジェクト　 と呼ぶことがあるが、 オブジェクト指向本来のドメインオブジェクトは、後者。

---

---

[ 続きを読む ] / [ 携帯版 ]

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