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

1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ] 前すれ 〔隔離〕デザインパターンは本当に必要か？〔スレ〕 pc8.2ch.net/test/read.cgi/tech/1119348596/ 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エンティティ＝静的状態＝ドメインオブジェクト　 と呼ぶことがあるが、 オブジェクト指向本来のドメインオブジェクトは、後者。 292 名前：275 mailto:sage [2007/03/28(水) 12:42:19 ] symfonyは一つのテーブルから二つのクラスを生成する。 テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる） 問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。 なのでそのクラスにそのデータを使うメソッドを書こうかと。 今、>>287の方法でやっていますがこれで良さそうです。 ありがとうございました。 293 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:31:09 ] エンティティとデータアクセスオブジェクトが自動生成ってことか データアクセスはデータアクセスに特化させる方がいいだろねー クラスの「役割」のくくりを大きくすれば、計算からデータの編集、保存まで一緒くたに するって考え方もアルンかもしレンガ、普通はもっと細分化するもんだ。 public　WoodCutPrintContext{ 　　　public void doWoodCutPrint(){ 　　　　　　Coodinator coodinator = getCoodinator(); 　　　　　　Hanzai hanzai = coodinator.getHanzai(); 　　　　　　DrawProcessor drawProcessor = coodinator.getCutProcessor(); 　　　　　　hanzai = drawProcessor.draw(hanzai); 　　　　　　CutProcessor cutProcessor = coodinator.getCutProcessor(); 　　　　　　hanzai = cutProcessor.cut(hanzai); 　　　　　　PrintProcessor printProcessor = coodinator.getPrintProcessor(); 　　　　　　printProcessor.print(hanzai); 　　　} } public 田中君 implements Coodinator { 　・・・ } public 鈴木君 implements Coodinator { 　・・・ } 294 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:34:25 ] ×；DrawProcessor drawProcessor = coodinator.getCutProcessor(); ○：DrawProcessor drawProcessor = coodinator.getDrawProcessor(); w 295 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 12:59:19 ] >>293-294 > 　　　public void doWoodCutPrint(){ 身元バレバレっすよ兄貴ぃ 閑話休題 他の言語、他のフレームワークを使っている人間に 余計なコメントをつけても混乱するだけだ。 もしアドバイスをつけたいなら、Javaではなく PHP5+symfonyの例に即したアドバイスをしろ。 例えば、 ・ データクラスの生成(検索、保存) ・ データクラスの処理(計算、処理) はべき乗パターンに則って別クラスにすべきだ、などという説は そのような冗長な設計が「PHP5＋symfony」に適しているかどうか、 という観点で議論すべきである。 だが、俺はそこまで突っ込むつもりはない。 そんな事をいちいち調べるつもりはないし、 質問者も困惑するだけだからだ。 296 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 13:11:21 ] >>293 つか、今気付いた。 おまいは TemplateMethod Patternを共用したい という質問に対して、全然別の回答をつけている。 特に、クラスの命名がデタラメだ。 ×× public　WoodCutPrintContext{ ... } ×　　public class WoodCutPrintContext{ ... } ○　　public class WoodCutPrintProcess { ... } 297 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 14:58:49 ] ---------------------------------------------------------------------------- デザインパターンにおける Contextの用例 1. Interpreterパターン 　 www.hellohiro.com/pattern/interpreter.htm 　 言語に対して、文法表現(Expressionクラス)と、 　 文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。 　 (注： Inerpreterクラスは付帯的に、言語の束縛〜副作用を表す評価環境(Context)を持つ) 2. Stateパターン 　 www.hellohiro.com/pattern/state.htm 　 オブジェクトの内部状態が変化したときに 　 オブジェクトの処理内容を変えられるようにする。 　 (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) ---------------------------------------------------------------------------- >>293のクラス名 WoodCutPrintContext は、 クラスの役割を表現しておらず不適切な命名と言える。 298 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 15:32:52 ] ---------------------------------------------------------------------------- デザインパターンにおける Contextの用例 【追加と訂正】 2. Stateパターン 【訂正】 　 × (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) 　 ○ (注： ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。　←【訂正】 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) 3. Strategyパターン 【追加】 　 www.hellohiro.com/pattern/strategy.htm 　 Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。 　 それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。 　 (注： ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。 　　　　 個々のアルゴリズムは、個別のConcreteStrategyクラス (〜A, 〜B, 〜C)に記述する。 　　　　 個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。) ---------------------------------------------------------------------------- もしかして >>293は、 　　鈴木、田中 ＝＝ StrategyパターンのConcreteStrategyクラス、 　　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス) と言いたかったのか？ だが、それでは 　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 　・鈴木が田中の手を借りて版画を彫る が全く同じ表現になってしまう。これは不適切だ。 299 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 16:59:49 ] ↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。 「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。 300 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:43:29 ] ■>>293の表現　「鈴木が田中の手を借りて版画を彫る」 /* >>293のコード　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 { // ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君はコンテキストを使って版画を彫る。 　　// 注：　鈴木君のコンテキストには手配師へのコネがあり、 　　//　　　　手配師は、仕事の各工程をメンバーに適当に割り振る。 　　WoodCutPrintContext context 　　　= WoodCutPrintContext.getinstance(); 　　// 鈴木君は、寄せ集めメンバーがバラバラに各工程を担当した 　　//　ツギハギ細工を、自分の成果として公開する。 　　return context.doWoodCutPrint(); 　} } 　　　　　　　↓ /* 「手配師が田中君しか集められなかった場合」の * 　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 田中君を拉致る 　　田中君 agent = 田中君.getInstance(); 　　// 田中君に強制労働させ、成果を横取りして提出する。 　　return agent.createWoodCutPrint(); 　} } 301 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:44:38 ] ■正しい表現 「鈴木と田中が全く同じやり方で版画を彫る」 public class 鈴木君 { 　// 鈴木君には版画を彫るスキルがある。 　public WoodCutPrintStrategy getWoodCutPrintStrategy() { 　　// 鈴木君のスキルは、一般にAと呼ばれるスキルである。 　　return WoodCutPrintConcreteStrategyA.getInstance(); 　} 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君は自分のスキルで版画を彫り、成果を提出する。 　　return getWoodCutPrintStrategy().doWoodCutPrint(); 　} } 302 名前：デフォルトの名無しさん [2007/03/29(木) 18:00:19 ] >>300 バグを発見しますた。 鈴木君の一人プロジェクトが無限ループを起していて いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ /* 「手配師が鈴木君本人しか集められなかった場合」の * 　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君が自分を拉致る 　　鈴木君 agent = 鈴木君.getInstance(); 　　// 鈴木君はいつものようにメンバーに強制労働をさせて、 　　// 成果だけ横取りするつもりだったが、 　　// 結局自分一人では何もできずに 　　// 貯え(VMスタック)を消費しつくして終了 　　return agent.createWoodCutPrint(); // 無限ループで　throw RuntimeException("スタックオーバフロー") 　} } 303 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 18:38:56 ] エロゲで使われているパターン Singleton 他なんかある？ 304 名前：300 mailto:sage [2007/03/29(木) 18:52:15 ] >>302 バグｽﾏｿ( ; -_-) >>294版鈴木君の等価コードはこうだ。 public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　/* 以下、手配師付き変形TemplateMethod(ｺﾝﾃｷｽト)内の等価ｺｰﾄﾞ */ //{ 　　　// 鈴木君は手配師を呼ぶ。(メンバー一人の場合、自分が手配師になる) 　　　Coordinator slave = this; 　　　// 手配師に各工程担当者を集めさせて、 　　　// 版材を準備し、版材処理を実行する。 　　　Hanzai hanzai 　　　　= slave.getCutProcessor().cut( 　　　　　　slave.getDrawProcessor().draw( 　　　　　　　slave.getHanzai())); 　　　// 版材を刷る。 　　　slave.getPrintProcessor().print(hanzai); 　　//} 　　return hanzai; 　} 　public Hanzai getHanzai() { reuturn new Hanzai(); } 　public 切り方 getCutProcessor()　 { return 切れ方_0893D.getInstance(); } 　public 書き方 getDrawProcessor() { return 書き方_1919Z.getInstance(); } 　public 刷り方 getPrintProcessor()　{ return 刷り方_0212A.getInstance(); } } // Functorパターン public class 切り方_0893D extends 切り方 { public Hanzai cut(Hanzai hanzai) { /* 何もしない */ } } public class 書き方_1919Z extends 書き方 { public Hanzai draw(Hanzai hanzai) { /* 何もしない */ } } public class 刷り方_0212A extends 刷り方 { public Hanzai print(Hanzai hanzai) { /* 何もしない */ } } 305 名前：デフォルトの名無しさん [2007/03/29(木) 19:46:45 ] まとめると、 >>275＝>>284の質問(>>292で解決済) 　テンプレートメソッドで、処理が同じものがある場合に、 　(注： 同じなのは、TemplateMethod単位か、個々のメソッド単位か不明) 　どのようなクラス設計をしたら良いか？ >>279-280、>>285-290の回答 　TemplateMethod単位で同じものがあったら、 　それをStrategyパターンで外出しして共用すれば良い。 ※ここまではOK >>293の回答 　TemplateMethodの個々のメソッド単位で同じものがあったら、 　それをStrategyパターンで外出しして共用すれば良い。 ※>>293の実装コードは 　　ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割 　　Coordinatorインタフェースを割り付けている点がおかしい。 　　鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。 306 名前：305 [2007/03/29(木) 19:47:36 ] >>293の実装コードの問題点 分析/設計で得たモデルの特性として、 「手順を構成する複数の工程について、 　各工程の処理方法にバリエーションがあり、 　なおかつ、各処理方法は互いに交換可能」 な事が明らかならば、>>293の実装もありえる。 しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、 不吉な匂いがする。・・・数100人月のシステムで、 このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。 どのような場合にこの実装/設計が破綻するかと言うと、 設計/初期実装に見落としがあって、 Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合 である。この場合、Hanzaiインタフェースのバリエーションに関して、 各処理方法は互いに交換可能でなくなる。 正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ〜 307 名前：デフォルトの名無しさん [2007/03/29(木) 20:14:36 ] デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。 プロトタイプ作成時は、「版画」は１種類だけ考えれば済むから、 その版画作成に使う版材も、処理手順も、詳細処理方法も１種類ずつで済む。 ・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、 　　開発もバッチグーね？とお気楽モード。 ところが開発展開になってから、 「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、 「異なる版画には、異なるサイズや材質の版材が必要」な事とか 「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」 ってな事にも、おそまきながら気付く。 　　　　　　　　　　　　　　　　　　　　　　　　アーキテクチャ設計ﾊﾀｰﾝｗｗｗｗ ・・・いや、気付いてても気付かないフリしたんだろう、 　　アーキテクチャ設計のボンクラ共は。 じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・ 幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。 その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったｗｗｗ 共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。 それでは、正しい解決方法はどこにあるのか それを私は知っているが、このレスにはもう余白がないので書けないｗ 308 名前：鈴木 [2007/03/29(木) 22:31:38 ] おまいら、俺の名前を気安く使うな、不愉快だぞ 続きは「佐藤クン」で 309 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:37:17 ] 上がダメなら、下の名前ならおｋ？ 例えばひろゆきとかゆきひろとかたかゆきとかあと 310 名前：デフォルトの名無しさん [2007/03/29(木) 22:49:30 ] 問題はドメイン・モデリングの欠落だなｗ 311 名前：デフォルトの名無しさん [2007/03/29(木) 22:55:01 ] 問題領域が「版画作成」なら、最終目的は「版画」だけど、 問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ〜よなｗ つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話 312 名前：デフォルトの名無しさん [2007/03/29(木) 22:57:26 ] 「業務処理」の目的は、DB更新と電文(w。 313 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:58:09 ] >>312 それはありえん 314 名前：鈴木 [2007/03/29(木) 22:59:24 ] >>309 それもダメだ、かすってる 鈴木の続きは「都築」でどうだ 315 名前：デフォルトの名無しさん [2007/03/29(木) 23:03:13 ] >>314 じゃニックネームで手を打とうぜ。 例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ 316 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:05:28 ] >>309、>>315 　見事なまでのプロダクトラインだなｗ 317 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:07:17 ] 閑話休題 318 名前：デフォルトの名無しさん [2007/03/29(木) 23:10:48 ] >>312 ある種の基幹系業務システムは、 構築難易度を下げて抽象化すると、 結局、マスタメンテ型アプリに帰着する。 すると、最終目的がマスタ更新ってのも そんなにずれていない。 するとオブジェクト指向で書く必要ないんだな、これが。 （終了） 319 名前：デフォルトの名無しさん [2007/03/29(木) 23:13:24 ] )再開( 320 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:17:09 ] GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ 321 名前：デフォルトの名無しさん [2007/03/29(木) 23:17:18 ] ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。 322 名前：デフォルトの名無しさん [2007/03/29(木) 23:22:56 ] >>321 M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。 CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、 所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ） ちょっと後悔（ｳﾂｳﾂｳﾂｳﾂｼｸｳﾂｳﾂｼｸｼｸｳﾂｳﾂｳﾂｳﾂｳﾂｼｸｼｸｼｸｼｸｳﾂｳﾂｳﾂ そんな事じゃいかん。俺はCMU/SEIはともかくとして、 日本のCMMI連中とは全然話が合わないんだったｗ なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆 323 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:29:25 ] >>322 特に無い。 324 名前：デフォルトの名無しさん [2007/03/29(木) 23:38:44 ] >>320 確かに飽きてきたのも事実 だが使いこなせてる奴が意外と少ないのも事実 325 名前：デフォルトの名無しさん [2007/03/29(木) 23:45:29 ] だが使いこなせてる奴は１０年前から退屈してるのも事実 326 名前：デフォルトの名無しさん [2007/03/29(木) 23:49:47 ] 2PLoP (2ch Pattern Language of Programming)報告： Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、 まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。 彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。 トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、 Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。 　　　　　pc11.2ch.net/test/read.cgi/tech/1172431242/ 327 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:56:05 ] 糞コード放置してった >>293は 今どこで野垂れ死んでいることやら 328 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:05:24 ] >>326 Pythonというか、いわゆる軽量言語にデザパタはいらんのじゃないかなぁ。 大規模開発にはそもそも向いてないでしょ。 もしかしたら、オブジェクト指向すらいらないかもしれないし。 馬鹿にして言ってるのではなくて、住み分けがあるだろうと。 大規模開発は javaなり c++ なりでデザパタを使って書けばいいし、 身近なユーティリティーを書くなら、軽量言語というか perlででも書いた方がいいし。 大規模開発に向かん言語で、デザパタっていっても そもそも意味がないと思うんだな。 329 名前：デフォルトの名無しさん [2007/03/30(金) 00:14:09 ] >>328 常識的な意見ってツマンナイよ rubyからrailが生まれたし、javascriptからAJAXが生まれた そんなご時世なのだ 330 名前：デフォルトの名無しさん [2007/03/30(金) 00:18:07 ] >>328 マジレスするぞ。 Pythonは関数言語的機能のほかに、 metaclassシステムやら、動的言語の性質をあちこち持ってるから、 C++やJavaよりよっぽどSmalltalk寄り。 そこにあろうことかJava版GoFを移植したってのが笑い所。 あと、後半部「ボトムアップでパターン抽出」 これは別に間違ってないだろ。 むしろ、将来Javaに取り入れるべき言語機能やパターンを 発見できるかもしれない(もう金脈は小さいと思うけどな)。 文句ばっか言って他をけなしてないで、 学ぶところは学びなさいってこったｗ 331 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:24:32 ] 関連ないが、Perlのプロトタイプ系OO拡張、あれは結構糞だ。 OOの面倒くさい所と、Perlのいい加減な所がダブルで来る。 でも、Javaと同様なクラスライブラリ書き始めると、 あっちの方がよっぽど融通利いて手早く完成する。 さすが90年代のLispと呼ばれただけの事はあるな。 関連ないが、Javascriptのプロトタイプ系OO機能、あれは最高だ。 あれ一つでずいぶんJavascriptのコードが書きやすくなる。 問題はjavascriptエンジンのバグやエラー報告の不充分さ。 あれ使って10年程前にAJAX風アプリ書いてた時は、 試行運用中に山のように実行時エラーがでて閉口した。 今の連中は幸せだよなぁ。あれで、Netscapeがまだ生き残ってたら 万々歳なんだが。 パターン関係ないチラ裏ｽﾏｿ 332 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:26:57 ] >C++やJavaよりよっぽどSmalltalk寄り。 て言われても、Smalltalk てそんなにいいのか？ 動的言語と言われた時点で、うーみとなりそうだけどなぁ。 型は、事前に論理的誤りを検出するためにあるんだぜ？ それを最初に省いたら、あとから泣きみるだろ。 それでデザパタが必要とされるような大規模開発に 向いてるといえるのだろうか？

---

---

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

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