5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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


2 :デフォルトの名無しさん:2006/03/09(木) 04:34:12
【神プログラム】
http://ex14.2ch.net/test/read.cgi/news4vip/1141838441/
にてネ申プログラムの実体にせまる!!


>>管理人さんがスパーハカーみたいで、画廊のイラストを無断で持っていくとPCが壊れちゃうらしい。
>>コワイヨー(((;・д・)))
>>ttp://tenkai-asyu.net/


3 :デフォルトの名無しさん:2006/03/09(木) 15:27:59
過去スレ
デザインパターンの単純そうな質問 - (1)
http://pc5.2ch.net/test/read.cgi/tech/994836140/
【GOF】デザインパターン - (2)
http://pc5.2ch.net/test/read.cgi/tech/1087050664/
【GoF】デザインパターン 3
http://pc8.2ch.net/test/read.cgi/tech/1095388499/
【GoF】デザインパターン 4
http://pc8.2ch.net/test/read.cgi/tech/1116122102/
【GoF】デザインパターン5
http://pc8.2ch.net/test/read.cgi/tech/1119158274/
〔隔離〕デザインパターンは本当に必要か?〔スレ〕
http://pc8.2ch.net/test/read.cgi/tech/1119348596/

関連スレ
デザインパターン
http://piza.2ch.net/tech/kako/976/976074878.html
リファクタリング、させてくれ
http://pc5.2ch.net/test/read.cgi/tech/1081863662/l50
【XP】Agile Process 第2イテレーション【UP】
http://pc5.2ch.net/test/read.cgi/tech/1091773629/l50
【綺麗】デザインパターンは美しい!【究極の美】@プログラマー板
http://pc5.2ch.net/test/read.cgi/prog/1089077456/l50

4 :デフォルトの名無しさん:2006/03/09(木) 15:28:46
Web Page [ja]
Javaプログラマのためのデザインパターン入門
http://objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.html
C++で読むデザインパターン
http://www.01-tec.com/document/cpp_design_pattern.html
Javaなページ
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaMain.html
デザインパターン入門 (ちとわかりずらい…)
http://www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html
Inversion of Control コンテナと Dependency Injection パターン
http://www.kakutani.com/trans/fowler/injection.html
Inversion of Control
http://wiki.bmedianode.com/Spring/?Inversion+of+Control
デザインパターンF.A.Q.
http://www.hyuki.com/dp/dpfaq.html
デザインパターンを読み解く
http://hp.vector.co.jp/authors/VA020635/system/dpattern.html
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
http://www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm



5 :デフォルトの名無しさん:2006/03/09(木) 15:29:36
Web Page [en]
Patterns Home Page
http://hillside.net/patterns/
Design pattern (computer science) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
C#によるデザインパターン
http://www.dofactory.com/Patterns/Patterns.aspx

6 :デフォルトの名無しさん:2006/03/09(木) 15:30:23
書籍
オブジェクト指向における再利用のためのデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/
増補改訂版Java言語で学ぶデザインパターン入門
http://www.hyuki.com/dp/index.html
Java言語で学ぶデザインパターン入門 マルチスレッド編
http://www.hyuki.com/dp/dp2.html
独習デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4798104450/
Javaデザインパターン徹底攻略 標準プログラマーズライブラリ
http://www.amazon.co.jp/exec/obidos/ASIN/4774115797/
デザインパターンによるJava実践プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756141552/
Java実践プログラムによるデザインパターン入門講座
- Swingプログラムで体得する23のパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4894712563/
J2EEデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4873111781/
C#デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4822281698/

7 :3-6:2006/03/09(木) 16:21:29
ういっす。テンプラ貼って見ました。
まったりと語り合いましょうぜ。

8 :デフォルトの名無しさん:2006/03/09(木) 16:29:42
お姉ちゃん本ってどれ?

9 :3-6:2006/03/09(木) 16:31:58
>>8
俺も気になります。お姉ちゃんの部分が気になります。

10 :デフォルトの名無しさん:2006/03/09(木) 19:48:07
お仕着せのパターンで解決できるものばかりなのかね?

11 :デフォルトの名無しさん:2006/03/09(木) 19:57:21
レゴブロックで作れないものはない

12 :デフォルトの名無しさん:2006/03/09(木) 20:50:32
23個のオナニーパターン。

13 :デフォルトの名無しさん:2006/03/09(木) 20:58:10
これ↓人気があるみたいだけど。

デザインパターンとともに学ぶオブジェクト指向のこころ
http://www.amazon.co.jp/exec/obidos/ASIN/4894716844/

14 :デフォルトの名無しさん:2006/03/09(木) 21:33:53
>>8
http://www.amazon.co.jp/exec/obidos/ASIN/4873112494/

O・O・P!O・O・P!と連呼すると・・・・

15 :デフォルトの名無しさん:2006/03/12(日) 02:00:17
結城先生あげ。

16 :デフォルトの名無しさん:2006/03/12(日) 02:21:34
GoF本読んでSmalltalk好きになった
といっても、GoF本のサンプルってほとんどC++なんだよね
で、SmalltalkでといえばDesign Patterns Smalltalk Companion
マジおすすめ

17 :デフォルトの名無しさん:2006/03/12(日) 13:58:40
>>16
>GoF本読んでSmalltalk好きになった
おっ、その心は?
Smalltalkって標準クラスの設計がいいの?

18 :デフォルトの名無しさん:2006/03/13(月) 00:52:53
『・・・こころ』
買っちゃった
♪明日届く〜

19 :デフォルトの名無しさん:2006/03/13(月) 02:32:32
>>17
そうね〜やっぱクラスライブラリの設計ですね
デザインパターンの固まりって感じなんですよ

Smalltalkを調べていくと、言語仕様が非常にシンプルで
言語で規定されるようなこと(制御文とか)すらクラスに
メソッドで定義されている、ってのにちょっと感動。



20 :デフォルトの名無しさん:2006/03/15(水) 00:05:06
このスレでもよく言われるけどデザインパターンは設計の話じゃないってどういうこと?
あきらかに設計の話だと思うんだけど。

21 :デフォルトの名無しさん:2006/03/15(水) 00:07:01
実装レベルでしか理解してない奴がまだまだ多いってこった

22 :デフォルトの名無しさん:2006/03/15(水) 00:23:55
>>20
リファクタリング(この言葉もテストの修正を許容するものから
許容しないものまで幅があって一概には使いにくいな)を前提
にボトムアップで見ると実装の話になる。
テストにしろリファクリングにしろデザパタにしろ、幅がありす
ぎて各自がバラバラの思惑で使うもんだからグダグダになっ
てる。

23 :デフォルトの名無しさん:2006/03/15(水) 01:28:26
今日、java.io.*のクラス図を初めてjudeで自動生成してみたんだが
・・・いや、美しいな。
(こいつぁArtだ。)
クラス設計とはかくありたいなと思ったよ。

あんまりかっこよかったんで、ついA3で印刷して部屋に貼っといたぜ。


24 :デフォルトの名無しさん:2006/03/15(水) 01:34:25
>>23
うp

25 :デフォルトの名無しさん:2006/03/15(水) 01:53:19
日頃どういったクラス設計に携わっているかの違いなんだろうか
格段に美しいとは思わない。当たり前の設計だと思うんだが・・・


26 :NAME IS NULL:2006/03/15(水) 01:57:20
デザパタ入門とJAVAの格言買ってしまった。
良書ということで一週間読み込むとする。

27 :デフォルトの名無しさん:2006/03/15(水) 06:29:22
>>20
実装だろ?
じゃなきゃあんなソースばっか載ってる本になるのはおかしい。

28 :デフォルトの名無しさん:2006/03/15(水) 07:55:55
そもそも実装という作業は、設計作業の一部なんだが。
このことをわかってないヤシが多すぎ。


29 :デフォルトの名無しさん:2006/03/15(水) 09:02:49
設計のデザインパターンと実装のデザインパターンをごっちゃにしてる奴が多いだけでしょ。
デザインパターン=クラス構造とか思い込むからそうなる。

30 :勉強中:2006/03/15(水) 10:54:03
設計ってしかことないけど(というかOOPってしたことないけど)、どれをクラスにするのかを決めて、
実装設計でデザパタを使う。実装がうまくいきそうにない(エレガントでないとか)ので、再度クラスを
考え直す。

っていうのを繰り返すのかな?

31 :デフォルトの名無しさん:2006/03/15(水) 12:36:49
>>20
設計の話だと思うよ。設計というと↓のように大きく分けて2つに分類されると思う。

■設計┬→基本設計
     └→詳細設計(プログラム設計)

デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
SEレベルでの「基本設計」ではない。

以前、俺も「「設計の話じゃない」みたいなニュアンスで登校したことがあるのでフォロー。
えと、知ってたらごめんなさいごめんなさいごめんなさいなのですが。

32 :デフォルトの名無しさん:2006/03/15(水) 12:52:11
>>23
java.io.* のクラスは素敵だよな。あの汎用性と拡張性。
いつも通りに入出力処理してるだけで勝手にMD5チェックサムが取れる、
DigestInput/OutputStreamとかもう天才の発想だよな。あれは感動した。

java.io.* は拡張のしやすさから結構、外部の人間が有益なライブラリ作ったりしてるよね。

↓ここの外人のクラス設計も素敵とおもた。ParallelWriterとかSequenceIteratorとか。
http://www.symbic.net/orbital/Orbital-doc/api/index.html

33 :デフォルトの名無しさん:2006/03/15(水) 19:13:01
>>31
> デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
> SEレベルでの「基本設計」ではない。

SEという定義をどう捉えているのかは不明だが、保守性を考えたシステムを作ろうと
した場合,基本設計はおろか要求の洗い出しの段階から考慮する必要があるのだが
どうだろうか?
そういった点から考えると、デザパタが詳細設計という枠に収まるかどうかは極めて
疑問だと思うぞ。

P.S.
それから、基本設計はSEがやるものだなんて考え方をしてSEとPGの間に溝を作る
こと自体が問題を生みだしてるんじゃないか?


34 :デフォルトの名無しさん:2006/03/16(木) 11:03:32
>>33
まず、基本設計書の認識がお互いあってるか確認したいんだけど、

顧客からの要件を受けて、その要件をコンピュータ上では、
このような形で満たせます。っていう話を顧客に説明するために、
作成する資料が基本設計書という認識でお互いあってるんだよね?

顧客側は一般人だろうし、ただやりたいこと(要件)だけがあるだけで、
それがどんな形でコンピュータ上で実現されるのかわからない。
まずはそれを説明しなくちゃならないんだけど、

それは、例えば「要件」として出勤退勤のタイムカードをパソコンでやりたいとか。
実現方式として例えばOSはWINDOWSです。とか
そして、VBのEXE起動して「出勤ボタン」を押しますとか
Accessのファイル開いて「出勤ボタン」を押しますとか
ブラウザ起動して出勤退勤のページに移動して「出勤ボタン」を押しますとか

そんなものだと思うんだけど、そこにデザパタが入っていけるか?

35 :34:2006/03/16(木) 11:10:17
ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな?
しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
または、その変更になる確立が高い箇所も、デザパタでは吸収できないかもしれないし、
最終的に、それを書くにしても詳細設計書だと思う。

36 :34:2006/03/16(木) 11:17:07
>それから、基本設計はSEがやるものだなんて考え方をしてSEとPGの間に溝を作る
>こと自体が問題を生みだしてるんじゃないか?
それはあるね。SEしてる人間の連絡不足で、よくPGが仕様とは違うものを作ってしまったりする。
その責任がPGの責任になってしまったりするし。
仕様の打ち合わせの段階からSEとPG、両方が参加すればいいのにとか思ったりするわな。

でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すPGも多いんだけど。

37 :33:2006/03/16(木) 13:04:26
>>34
それは私の言っている基本設計書ではありません。

> それは、例えば「要件」として出勤退勤のタイムカードをパソコンでやりたいとか。
> 実現方式として例えばOSはWINDOWSです。とか
これは「要求定義書」になりますね。
要求定義書っていうのは顧客の要求だけが書き連ねられているドキュメントではなく、
利害関係者(顧客,投資者,開発チーム等)の一致した要求が書き連ねられるもの
です。 このため OS は Windows で、というのも投資者(開発側企業)の思惑だったり
顧客の要望だったりする。
最近の開発だと、OSの選定が設計扱いされることは少ないんじゃないか?
なお、要求定義書にデザパタが出てくることはまずありません(変更に強いシステムという
要求はあるけど)。

> そして、VBのEXE起動して「出勤ボタン」を押しますとか
> Accessのファイル開いて「出勤ボタン」を押しますとか
> ブラウザ起動して出勤退勤のページに移動して「出勤ボタン」を押しますとか
これは画面設計書でしょう。 画面設計にいわゆる GoF のデザパタが出てくることは
ありません(芸術的なデザインのパターンはあるでしょうが)。
-----
> ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな?
> しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
関係ないことありませんぜ。 こういった作業はデザパタを適用する上で大きな布石となります。

「オブジェクト指向のこころ」に載っている共通性/可変性分析ってーのは、かなり上流工程の
作業になり、こういった行為を通じて構築対象のインタフェースをクローズアップしていくこと
ができます。 ということで、この工程を実施する時点でもうデザパタを意識することになるのです。


38 :33:2006/03/16(木) 13:11:16
> 仕様の打ち合わせの段階からSEとPG、両方が参加すればいいのにとか思ったりするわな。
> でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すPGも多いんだけど。
そうなんだよな〜。
仕事の面白さを取って責任を取るか、仕事の面白さを捨てて責任逃れをするかってとこで、
みんな後者を取っちゃうんだよなぁ。


39 :デフォルトの名無しさん:2006/03/16(木) 23:51:12
なんかごちゃごちゃしてるけど、
結論としてはデザインパターンは設計の話ってことでいいの?


40 :デフォルトの名無しさん:2006/03/17(金) 01:00:51
どこまでを設計と呼ぶべきかによる、って結論に落ち着くはず。

41 :デフォルトの名無しさん:2006/03/17(金) 01:15:14
デザインパターンは内部設計の話です

42 :デフォルトの名無しさん:2006/03/17(金) 01:27:53
やっぱり、設計段階でソースが出てくるのは同考えてもおかしい。

43 :デフォルトの名無しさん:2006/03/17(金) 01:30:59
こういうフローチャートを書くとこんなソースになるんだよ
っていう教え方はわりとありふれてると思うのです

44 :デフォルトの名無しさん:2006/03/17(金) 01:57:34
アブストラクトファクトリとシングルトンが
同じ設計レベルで出てくることってあるんかいな?


45 :デフォルトの名無しさん:2006/03/17(金) 06:52:58
>>44
シングルトンを「インスタンスの個数を一定数にする」ものだと考えると
アブストラクトファクトリと同じ設計レベルになる。
もっともシングルトンは「インスタンスの個数を1個にする」という上述した
要求の特殊解なんだが。


46 :デフォルトの名無しさん:2006/03/17(金) 06:55:15
>>42
ヒント: ソースコード=設計図

つ ttp://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html


47 :34:2006/03/17(金) 11:25:30
>>37-38
おー、びっくりした。基本設計で「これは○○パターンが適用できますよ!」とかを売り文句にするのかと思った。

>これは画面設計書でしょう。 画面設計にいわゆる GoF のデザパタが出てくることは
ここで伝えたかったことはあれです。あれあれ。
「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ!」とか売り文句みたいなもんです。
システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。

>関係ないことありませんぜ。 こういった作業はデザパタを適用する上で大きな布石となります。
んー、まぁ、要件によって実装は変わるから、デザパタを適用するか、しないかも確かに変わってくるし、
基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか?

48 :34:2006/03/17(金) 11:46:10
>>38
(;´-`)。o(そ、そうか!あいつら責任逃れのためか!あのやろう!)

まあ、そこで責任逃れしても、仕様と違うもの作って、
結局は作り直しさせられて残業の責任を負うはめになると思うけどね。

49 :33:2006/03/17(金) 12:40:57
>>47
> ここで伝えたかったことはあれです。あれあれ。
> 「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ!」とか売り文句みたいなもんです。
> システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。

悪い。 ここんところの日本語がまったく理解できなかった。
文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
というのは要求定義書の役割であって、画面設計書とは別物という認識なのだが。

基本設計というのは要求定義が完了してから始まる工程であり、そこからデザパタは適用できる
と主張しているわけっす。

> 基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか?

オブジェクト指向技術を採用して開発を行う、、、となった時点で、変更容易性とかの話しに直結
するのが普通だと思うぞ。 
基本設計ってーのは、平たく言えばシステム化対象となる問題領域に境界線を引いていく作業だと
思っている。 その時にどの部分をカプセル化して変更を封じ込められるようにするのかを検討する
ことは当然のことじゃないか?


50 :34:2006/03/17(金) 13:33:09
>文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
>というのは要求定義書の役割であって、
あっ。そりゃそうだ。まあその、手順だね。システム化することによってどんな手順・操作になるかとか。

>オブジェクト指向技術を採用して開発を行う、となった時点で、変更容易性とかの話しに直結するのが普通だと思うぞ。 
ある部分の処理が、将来変更するか否か、柔軟性を持たせるべきか否か、重要度が高いか否か、
それはデザパタや、オブジェクト指向を意識せずに開発を進めた場合でも考慮することじゃないか?
それで内部設計の段階で、ここはこうなる可能性があるから柔軟性を持たせようって話になると思うんだけど。

まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
なんか違う気がする。

51 :33:2006/03/17(金) 14:06:42
>>50
私の頭の中にある基本設計ってーのは、要求定義書が終わってから始まる一連の作業であり,
ユーザーのシナリオを一つ一つ分析しながら、サブシステムに分割していき、最終的には大まか
なクラス設計が完了するところまでと思っています。

で、サブシステムの分割や大まかなクラス設計を行う時点では、洗い出したサブシステムや
クラスの責務を決めないといけないので、この時点でインタフェースに着目する必要があるわけです。

そして、インタフェースという観点で設計を行い始めた時点でデザパタの適用というものは視野に
入っているというのが私の考えです。

> まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
> なんか違う気がする。

確かにまぁ、「どこかでデザインパターン使えないか?」といった感じで目を皿のようにして探しながら
基本設計するというイメージではなく、インタフェースを主にして考えながら「どういった切り口で
インタフェースを考えたら、うまくまとめられるのか?」といった観点で作業することになる。
しかし、デザパタを知っておくことで考え方の道筋が整理されるから、ここでのヒラメキが得やすくなる
ということが言いたい。

そう言う意味じゃ「デザパタを適用すること」が目的だと言っているのではなく,「デザパタの知識を利用
することでインタフェースを使った考え方ができるようになること」が重要なのだと思っている。
そして、それが基本設計にも適用できると主張している根拠になっているわけ。


52 :デフォルトの名無しさん:2006/03/17(金) 20:35:31
>>51
GoFの23パターンだとそのレベルで適用するのってあったか?
パターンという括りならわかるけど
俺はそのレベルで適用可能なものってデザパタって言葉とずれてると感じるのだが

53 :33:2006/03/17(金) 21:03:37
>>52
おおまかなクラス設計を行うと言っても、頭の中に実現可能性を想い描くことが
できなければ絵に描いた餅になる。 そういった点で GoF の23パターンを見た場合、
適用できないものの方が少ないと思う。

私の場合、よく使うのはBridge、AbstractFactory、Strategy、Observer、Visitor、等々


54 :52:2006/03/17(金) 21:18:37
>>53
なんか俺はちょっと違うことを考えていたらしい
実現可能か考えずに、より適切なモデリングするぐらいのものかと思ってた
言語まである程度意識してるクラス設計まで ってことでいい?

55 :33:2006/03/17(金) 21:51:21
>>54
いいっす。
そもそも、言語を考えずにモデリングするってーのは、はなはだ危険な行為だと思う。
だいたいクラス設計と言った瞬間に、オブジェクト指向言語の採用が前提となってるので
言語を意識しないモデリングなんてあり得ないと思うが。

基本設計時に詳細にとらわれて詳細の海に溺れてしまうのはいけないことだが、詳細に
立ち入ってはいけないということではない。 むしろ詳細を(頭の片隅ででも)考慮すること
なしに作った基本設計など、実現可能性のあやふやなゴミと同じだと思う。 上流工程は
下流工程のことを考えた上でないと成果物を作ってはならないと思っている。

蛇足だが、この辺りのことを理解してないSEが多く、下流工程を意識することなくモデリング
しようとするSEがいるためにSEとPGがいがみ合ってるということもあると思う。
クラス設計時に名詞と動詞を抽出するなんてアプローチを使ってちゃ、下流工程を意識しよう
にも意識できないわな。 そんな設計だと実装時にギャップで苦しむのは目に見えている。


56 :52:2006/03/17(金) 22:05:51
>>55
アナパタは言語意識しないよね あのレベルなのかと思ってた
ソフトウェアを作るためのモデリングじゃなくて、現状把握のためのモデリングかと
基本設計って結構範囲が広いんだな

57 :デフォルトの名無しさん:2006/03/17(金) 22:18:08
設計段階からデザインパターンを使いまくろうなんて考えていると、
アンチパターンになるぞ。
実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。


58 :33:2006/03/17(金) 22:20:45
アナパタは結構毛色が違うよね。
あれは要求定義書を作る際に使うものだと認識してまふ。
要求定義=Whatの定義、設計=Howの定義なのでどうしても切り口は違って
くるかな。

ということで今日はボチボチ帰って寝るわ〜。


59 :デフォルトの名無しさん:2006/03/18(土) 00:42:04
>>57
それ単に設計が不十分なだけじゃん。

60 :デフォルトの名無しさん:2006/03/18(土) 01:28:46
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい。

61 :デフォルトの名無しさん:2006/03/18(土) 03:58:40
俺がGoFのデザパタ意識するのは
・(ツールレベルの)フレームワークの設計/実装をしてる時
・実装コードのリファクタリングをする時
だけ。
設計か実装かと言われれば、俺の意識だと実装。
前者は人によっては設計と呼ぶかもしれない。

アプリレベルのフレームワーク設計してる時には
とたとえばJ2EEデザインパターンや
アンチパターンは大いに意識するけど
GoFを意識することはない。

62 :デフォルトの名無しさん:2006/03/18(土) 07:55:20
>>57
> 設計段階からデザインパターンを使いまくろうなんて考えていると、
> アンチパターンになるぞ。
> 実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。

リファクタリング時にデザパタが有用であることは認める。 しかし、設計時にも間違い
なく有効だ。
リファクタリングの時にしかデザパタを使わないという考え方が成立するのは、XPのように
必要最小限のシステムを作った後、各サイクルを1週間程度で回していくというプロセスを
採用した時だけだと思うぞ。 ある程度の大きさのシステムを数ヶ月単位で回していく場合、
その考え方では初回のリファクタリングの作業量が莫大なものとなって破綻してしまう。

それから、アンチパターンについてだが、確かにアンチパターンというものは常に頭に
置いておく必要がある。 しかしアンチパターンのほとんどは「ものごとのバランスをとるため」
に存在するのだ。
 「分析地獄」というアンチパターンがあるからといって、分析はやらないでおこう、、、なんて
ことにならないのと同じことだ。

>>60
>>46

>>61
アプリレベルの設計でも Bridge パターンはよく使うぞ。
このパターンは、日本で最も過小評価されているパターンなんじゃないかと思う。
俺も「こころ」本を読むまで Bridge を正しく認識していなかったが。w
(他にも当たり前のように Strategy とか使うけど。)


63 :デフォルトの名無しさん:2006/03/18(土) 10:44:09
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい

64 :デフォルトの名無しさん:2006/03/18(土) 10:47:48
うちだとアプリレベルの設計はもっと大枠で捉えてしまうんすよ。
プロセス・スレッド間の通信には何使うとか、
他システムの通信方法がキモいから
この部分はラッパーでカプセル化しちまおうとか、
DAO層はあのやり方で実装しようとか、
その程度だけ決めて実装(含むプロトタイプ作成)に入っちゃう。

小規模で言わなくても分かってる同士だからうまく行ってるけど
大規模になったらきちんとフレームワーク設計やらなならんのだろうなぁ、とは感じる。

どうやら「こころ」が良本らしいので読んでみようかな。

65 :デフォルトの名無しさん:2006/03/18(土) 12:05:09
>>64
「プロセス・スレッド間の通信には何使う」や「他システムの通信方法がキモいから
この部分はラッパーでカプセル化しちまおう」ってーのは、大枠で捉えているという
よりも、「そこにあるものを使う」っていういわばボトムアップの発想じゃないかな。
 「DAO層はあのやり方で実装しよう」というのも、レイヤーありきの発想でボトムアップ
に近いと思う。

こういった「あるものを流用」したり「技術からの要求を主」にする設計は、顧客の要求する
ものを取り込むタイミングが難しく、顧客ニーズからブレたものができる危険性がある。
大規模開発をする予定があるのなら、トップダウンの視点は身につけておいた方がいいと
思うぞ。  この視点は小規模開発でも有効だし。


66 :34:2006/03/18(土) 13:14:44
>>51
うーむ、詳細設計をしつつ基本設計をする。って感じに聞こえてしまうなぁ。
基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの?
それだと俺が働いてきた会社の基本設計とは違うかもしれない。
というか基本設計とかって働いてる場所によって意味合いが変わってくるかもね。

「こころ」か。良本らしいので俺も読んでみようかな。Bridgeはいいパターンだよね。
漏れがよく使うのはDecorator、Bridge、Factory Method、Strategy、Flyweightとか。
他のは理解はできるけど、いい使い所が思いつかなかったりする orz

それぞれのパターンのうまい使い方の情報交換とかしたい。

67 :デフォルトの名無しさん:2006/03/18(土) 13:50:37
こころ たけーよ こころ orz
昨日、本買ったばっかりなのに

68 :33:2006/03/18(土) 14:46:19
>>66
> 基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの?

いや、クラス設計は完了しないっす。  業務オブジェクトのモデリングが主な目的で、
主要なクラスと主要なメソッドだけを記述したクラス図ができるだけです(あっ、パッケージ
関連図も成果物です)。

詳細設計では、さまざまな内部メソッドを追加し、クラスが追加されることも当然あります。
シーケンス図も詳細設計で考えますかね。

> それぞれのパターンのうまい使い方の情報交換とかしたい。

いいですねー、それ。  どんな感じでやりゃいいのか、イメージはできてないけど。


69 :http://www.vector.co.jp/soft/win95/util/se072729.html:2006/03/18(土) 20:16:45
TextSS のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか?

70 :デフォルトの名無しさん:2006/03/19(日) 02:54:15
俺は Template Method が一番利用頻度高い。
その次に来るのは Adapter や Decorator、Singleton。
DIコンテナ使うことが殆どなので
潜在的には Factory パターンの利用回数がダントツなんだろうか。

Template Method はDIコンテナと親和性が高いので多用してしまう。

71 :デフォルトの名無しさん:2006/03/19(日) 12:36:24
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしいよな

72 :デフォルトの名無しさん:2006/03/19(日) 17:01:07
>>71
釣れますか〜?


73 :デフォルトの名無しさん:2006/03/19(日) 17:49:49
>>72
釣られちゃってますね。

74 :デフォルトの名無しさん:2006/03/19(日) 19:44:20
>>73
おっ、釣れた釣れた。


75 :デフォルトの名無しさん:2006/03/19(日) 22:21:03
>>74
これをメタフィッシングパターンと命名する。


76 :デフォルトの名無しさん:2006/03/20(月) 01:23:29
> それぞれのパターンのうまい使い方の情報交換とかしたい。
とか言っちゃったけど、言いだしっぺの俺がまずなんか書かねば…。


77 :デフォルトの名無しさん:2006/03/20(月) 21:22:18
俺がプロトタイプ作成→リファクタリング→Template Method適用に至るよくある手順

(1) 詳細は無視して大まかな流れだけを実装する。
(2) 細部に肉付けして簡単なテストが通ることを確認する。
(3) 一部の処理が特定の条件下では異なるため、その処理と、条件分岐の部分を書く。
  テストが通ることを確認する。
(4) 別の条件だと別の処理を書かなくてはならず、いい加減面倒になってくる。
  もっとスマートに書けないものかと思案する。
  どう考えても Template Method パターンです。本当にありがとうございました。
(5) という事で書き直す。テストも通る。

78 :デフォルトの名無しさん:2006/03/20(月) 22:29:11
構造に関するパターンは設計段階でも話が出る可能性はある。
振る舞いに関するパターンはほとんどでない。

79 :デフォルトの名無しさん:2006/03/21(火) 08:07:30
>>77
よくある手順って…おまいは毎回そんなことを考えてるのか。
いい加減、最初からわかれよ。

80 :デフォルトの名無しさん:2006/03/21(火) 08:37:57
>>78
振る舞いに関するパターンでも Command,Interpreter,Observer,Visitor なんかは
大まかな設計レベルでも十分考慮対象だったぞ。 それ以外はちょっと詳細な設計
レベルになるかもしれんが。
あと、生成に関するパターンも構造に関するパターンと対にして設計時点で使うわな。


81 :デフォルトの名無しさん:2006/03/21(火) 10:39:52
>79
最初は動くものを作って、だんだん仕上げてく。
こっちの方が最終的に早く出来上がるし、
変な設計に振り回されないので見通しも良くなる。

別フレームワーク作るわけじゃないんだから。

82 :デフォルトの名無しさん:2006/03/21(火) 13:10:21
>>81
曳光弾形式の開発ができる現場だとそれもいいんじゃない?


83 :デフォルトの名無しさん:2006/03/21(火) 13:46:40
行き当たりばったりなだけじゃん

84 :デフォルトの名無しさん:2006/03/21(火) 13:58:20
>>83
悪く言えばそうだけど、XPなんて正にそれじゃん。
行き当たりばったりだったとしても、そのプロセスに顧客を巻き込めれば無問題。
スパイラル開発で各サイクルを早く回そうとするのもまったく同じこと。

ただ、そういったプロセスを使えない開発の場合には、まったくもって指摘通りになる。
そしてこの場合、デザパタはリファクタリング時だけでなく、設計時にも活用することになる。
そんだけのことじゃない?


85 :デフォルトの名無しさん:2006/03/22(水) 00:43:07
俺は84じゃないが、最初は出来るとこまで作って、
後からどんどん洗練してくやり方なんて最近じゃ普通の考え方だと思うんだけど。

むしろ、一気に完成形を目指さず、変更されることを意識しつつ、
少しづつ仕上げていくやり方の方が変更に強いもんができるんじゃないかと。

最近のアジャイル開発とか言われてるのもこんな感じの考え方でしょ?

86 :デフォルトの名無しさん:2006/03/22(水) 02:16:46
設計する時だってプロトタイプ作成を並行して
頭で考えたことが実際に実現可能か調べながら進めていく。
んで一発で完璧な設計にたどり着くことなんて稀で
いろいろ試行錯誤しながら進めていく。
このプロトタイプ作成作業を実装フェーズにカウントすると
行き当たりばったりだと罵られて、
設計フェーズにカウントするとお咎め無し?

俺には同じものに見える。

87 :デフォルトの名無しさん:2006/03/22(水) 08:10:28
>>86
> 俺には同じものに見える。
同じものだ。
しかしプロトタイプを実装フェーズだと考え、それをそのままの形で成果物に
してしまうと成果物が無茶苦茶汚くなることがある。
もちろんそれはプロセス側で対処すべき問題なのだが、そういった対処が
なされていなければ、「行き当たりばったりで作った汚いコード」という謗りを
受けることになる。

プロトタイプを設計フェーズだと考える場合、そのプロトタイプは実装フェーズ
に引き継がれないという暗黙の前提が生まれるため「行き当たりばったり」という
表現は妥当ではなくなる。 ってーか設計フェーズは試行錯誤するのが当たり前。


88 :デフォルトの名無しさん:2006/03/23(木) 15:41:57
なるほど。

89 :デフォルトの名無しさん:2006/04/07(金) 16:41:51
このスレではわりと好意的な評価のようなので
こころを買ってみた。
最初は眠くなる話が多い気がする。
良さが分かるまでにしばらくかかりそうだ。

90 :デフォルトの名無しさん:2006/04/08(土) 01:15:39
>>89
もしや、他にデザパタの本読んだ経験無い?

91 :デフォルトの名無しさん:2006/04/08(土) 01:17:44
結城本でFAかと思ってた

92 :デフォルトの名無しさん:2006/04/08(土) 01:21:13
結城本はかなりメジャーだからむしろ宣伝するやつが少ない

93 :デフォルトの名無しさん:2006/04/08(土) 07:13:58
「ここは○×パターンでコーディングする」と書かれた仕様書が上から落ちてくる
のであれば、結城本でも十分だろう。

しかし自分で適用可能なデザインパターンを見つけ出す(=自分で仕様書を書く)場合、
結城本だけではツライと思う。
(練習問題を飛ばさずに真面目にじっくりやってれば、できるかもしれんが。)


94 :デフォルトの名無しさん:2006/04/08(土) 12:47:40
>90
結城本は持ってる。
デザパタそのものの有用性は自分なりに理解してる。

結城本の感想は93氏に近い。
過程すっ飛ばして天からデザパタが降ってくるスタイル。
パターンの暗記は出来ても理解はありえないなと。

「こころ」は前書き読む限りだと過程を重視してるようなので期待。
まだ第一部読んでるあたりで、UMLがなんちゃらとかそんな話。
非常に眠くなる。読み飛ばせばいいのだけど、それが出来ない性分。

95 :デフォルトの名無しさん:2006/04/08(土) 13:08:32
ある程度パターンを暗記したら、あとは実際にデザパタを意識したコードを読むのが良いと思う。

クラスライブラリを勉強するのがいいかもしれない。
C#とかJavaのクラスライブラリリファレンスをみると勉強になったりする。

あとは使ったことないオブジェクト指向言語の勉強するといいかもしれない。RubyとかD言語とか。
後はフレームワークとかも。Log4jとかRailsとか。

論を勉強するのもいいけど、やっぱり証拠もないと理解しにくいかと。

96 :デフォルトの名無しさん:2006/04/09(日) 02:30:58
てっきりあの「あなたの考えを広げるためのヒント」が
結城本の特徴なのかと思ってた。
あれの域にとどまらず、もっと応用の指針について
解説されてる本があるのね。

97 :デフォルトの名無しさん:2006/04/09(日) 10:33:45
結城本はGOFの劣化版でしかない
GOFのわかりやすいところ(結城が理解できたところ)を
初心者向けに言い直しただけ
それ以上の情報はいっさいなし

オブジェクト指向のこころとアジャイルソフトウェア開発の奥義を読んで、
リファレンスとしてGOFを手元においておけばいいと思う


98 :デフォルトの名無しさん:2006/04/09(日) 10:40:03
GOFはなんでC++を選んだのだろう

99 :デフォルトの名無しさん:2006/04/09(日) 11:14:05
どういうこと?
Smalltalkで全編書けってこと?
GoF本オリジナルは1995年だからJavaはありえんよ


100 :デフォルトの名無しさん:2006/04/09(日) 14:18:36
日本語版なら付属CDにJavaソースあるしね。
確か、SmalltalkとC++のうち話したいことがわかりやすいほうで例示する、みたいなこと
書いてなかったっけ。

101 :デフォルトの名無しさん:2006/04/09(日) 14:21:47
>>99
単純になんでだろう、と思っただけなんだ。
そうか、Javaなかったのか。そりゃ仕方ない。

102 :デフォルトの名無しさん:2006/04/09(日) 15:43:01
結城さんに抽象的なモノを説明させるとかなりヤバい。
例とか背景とかなしで、方法だけを詳しく掘り下げる。
同マルチスレッド編もそんなスタイル。途中で読むの止めた。

具体的な内容だとすごく分かりやすい・読みやすいもの書いてくれるんだけど。
HOW TO 本が彼の本来のフィールドだと思う。

103 :デフォルトの名無しさん:2006/04/13(木) 01:17:07
あるシステムのGUIコンポーネントを表示する部分の設計をしているんだけど、
綺麗な設計が浮かばなくて悩んでます。

Componentは0〜複数個のFrameを持っていて、
Frameには0個か1個のComponentが入り、描画の仕方はComponent自身が知っている、
というのが基本設計で、
「WindowコンポーネントはMenuBarフレームとStatusBarフレームを持っている」
「MenuBarフレームにはMenuコンポーネントが入る」
という感じで定義されていく予定なんだけど、

フレームの大きさに合わせて描画するコンポーネントが一般的なのはいいけど、
フレームの中に入ったコンポーネントの大きさによって描画が変化するコンポーネントがあって、
一度の再描画で全部綺麗に更新するためにはトップダウンでもボトムアップでも駄目で困ってます。

こういう場合、どういうパターンが有用だと思いますか?

104 :デフォルトの名無しさん:2006/04/13(木) 02:13:37
Composite

105 :デフォルトの名無しさん:2006/04/13(木) 23:20:57
トップダウンでできんじゃないの?
>>104のいうとおりCompositeで。

106 :デフォルトの名無しさん:2006/04/13(木) 23:34:25
トップダウンだと、例えばWindowコンポーネントがMenuコンポーネントを中に持つとき、

1.
Windowコンポーネントが自分自身の高さ、幅を持つ(例;width=640 height=400)
Menuコンポーネントが入るべきフレームを設定する(フレームの大きさは幅640、高さ不定)

2.
MenuコンポーネントはWindowコンポーネントの幅に応じて高さが決まる
(幅が狭いとメニューが二行になったりする。今回は30pxと決定)

3.
WindowコンポーネントはMenuコンポーネントのすぐ下にToolBarコンポーネントが入るフレームを設定する。
この位置は、Menuコンポーネントが自分自身の位置を決めることによって初めて決まる。

今回のようにこの順番で描画してくれるなら問題ないのですが、
例えばToolBarが先に初期化されるようにプログラマに記述されたら、そのタイミングではToolBarを置く位置がわからなくなります。
二回走査すればいいのでしょうが、今ひとつすっきりとしなくて困っていますが、
とりあえずCompositeで書いてみるかな…

107 :デフォルトの名無しさん:2006/04/14(金) 08:12:06
そういうのはパターンと言うよりアルゴリズムの話

108 :デフォルトの名無しさん:2006/04/14(金) 08:27:37
>>107
本質的には同じなんだけどな

109 :デフォルトの名無しさん:2006/04/14(金) 08:32:24
二回走査しなければいけない原因を分析
 アルゴリズムの問題
 構造の問題

一回走査で代替するにはどう走査すべきか

新しい手法はどのパターンを適用できるか(できなくても問題ない。銀の弾ではない)

と手順踏めば良いだけのこと
いきなりパターンに解を求めるのは違うよ

110 :デフォルトの名無しさん:2006/04/14(金) 08:36:45
>>109
108じゃないけど本質的には同じじゃないか ^^;

111 :デフォルトの名無しさん:2006/04/14(金) 08:43:37
本質は同じだけど、視野が狭くなるでしょ
元の課題の本質が理解できていない人がとるべき行動ではない

112 :デフォルトの名無しさん:2006/04/14(金) 08:53:08
>>111
そりゃそうだ

113 :デフォルトの名無しさん:2006/04/17(月) 08:55:15
まあ、そんなこと言ってると、このスレの視野が狭くなって話題が無くなるけどな
いいじゃん本質は似たようなもんなんだから。そこからパターンの話が広がってくかも試練氏。

114 :デフォルトの名無しさん:2006/04/18(火) 11:22:22
そろそろJ2EE5.0パターンとか出てこないものか…と思う。

115 :デフォルトの名無しさん:2006/05/08(月) 14:39:08
シングルトンのgetInstanceに引数があるのはおかしいでしょうか。

ファイルを複数管理するクラスで、
アプリ起動時に必要なファイルを読み込み、
メソッドに応じて読み込んだファイルの内容を返すという処理をさせます。

初期化の段階でファイルのルートパスが必要になるので
getInstance(String path)のようなパターンをオーバーロードしようと思っています。

getInstance(String path)はアプリの初期化処理内で1度だけ呼び出し、
ほかはgetInstance()を呼び出すようにしようと考えています。

116 :デフォルトの名無しさん:2006/05/08(月) 16:03:28
>>115
シングルトンって言われると違和感が多少あるけど、処理自体は変じゃないと思いますよ。

117 :デフォルトの名無しさん:2006/05/08(月) 18:56:14
>>115
オレなら初期化用のメソッドを作るかな。

118 :デフォルトの名無しさん:2006/05/08(月) 23:54:26
>115
getInstance(String) の呼び出しを
一回に限定しないとならんわけだけど
それはどのように実現するつもり?

ファイルパスだけでいいのなら、
プロパティファイルなりで指定して
静的初期化ブロックで処理してしまえば良いのでは。
(javaじゃないなら環境変数などで渡す)

119 :デフォルトの名無しさん:2006/05/09(火) 09:53:43
そんなかんじでよさげ。

ハッシュ(マップ)みたいなものにファイルパスをキーにして
自分のインスタンスを複数保持すればいいんでね?
ハッシュから取り出せなかったら場合に、同期で初期化すればよいかと。

120 :デフォルトの名無しさん:2006/05/09(火) 11:12:06
>>116-119
お忙しい中、良レスありがとうございます。
今まではプロパティファイルに絶対パスを指定しておいて初期化メソッドの中で読み込むようなことをしていました。

Webアプリだと環境によってデプロイされる場所が変わってしまい、環境毎にプロパティファイルを設定するのがたいへんでした。
ファイル自体はWEB-INF/fileの位置においてあるので
ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。

121 :デフォルトの名無しさん:2006/05/09(火) 15:21:04
デザパタとは外れますが
>環境毎にプロパティファイルを設定するのがたいへんでした。
war作るたびに設定編集するのは大変なんで
・環境の数だけ設定ファイルディレクトリ作成
・環境依存の設定ファイルを全てぶちこむ
・環境の数だけwar作成
・warを作成する時には環境に適した設定ファイルを使用する
・warの作成は設定の選択も含めてantで行う。
にしてみてはどうでしょうか。

122 :デフォルトの名無しさん:2006/05/09(火) 16:35:08
>ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。

個人的には
・クラスパス直下に、設定ファイルへのパス一覧を記述した.propertiesファイルを置く。
もしくは
・web.xmlに設定ファイルへパス一覧を記述する。
が好き。

コードがすっきりするよ。

123 :デフォルトの名無しさん:2006/06/04(日) 02:34:27
デザインパターン勉強してるんですけど。
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051227/226807/
ここのStateパターンがいまいち理解できません。
if文なんか使いませんと書いてますけど、currentStateを変えるには
結局ifなりswitchなりが必要に思えるんですけど…
どうか教えて下さい!

124 :デフォルトの名無しさん:2006/06/04(日) 02:49:21
if文はあんまりつかいません
と言い換えればOK?

説明文で躓いてるならそれで十分だけど
内容で躓いてるなら
「状態を変更するif文は必要」
「状態を判断するif文は不要」
と考えれば少しは納得いくかも

125 :デフォルトの名無しさん:2006/06/04(日) 03:12:51
switch(状態){
case 朝:
currentState = mornig;
break;
case 昼:
currentState = day;
break;
case 夜:
currentState = night;
break;
}
currentState.showMessage();

こうしか思いつかないんですけど、なにか根本的に間違ってますか?

126 :デフォルトの名無しさん:2006/06/04(日) 03:18:07
>>123
意味的な話をすると、State パターンってのは、表示メソッドが showMessage01 〜 showMessage03 まであったときに、

showMessage01────┐ showMessage02────┐ showMessage03────┐
│ 朝表示するメッセージ │ │ 朝表示するメッセージ │ │ 朝表示するメッセージ │
│ 夜表示するメッセージ │ │ 昼表示するメッセージ │ │ 昼表示するメッセージ │
│ 夜表示するメッセージ │ │ 夜表示するメッセージ │ │ 夜表示するメッセージ │
└──────────┘ └──────────┘ └──────────┘



朝表示するメッセージ─┐ 夜表示するメッセージ─┐ 夜表示するメッセージ─┐
│ showMessage01  │ │ showMessage01  │ │ showMessage01  │
│ showMessage02  │ │ showMessage02  │ │ showMessage02  │
│ showMessage03  │ │ showMessage03  │ │ showMessage03  │
└─────────┘ └─────────┘ └─────────┘

のどっちが使いやすいかーって話にも関連してくる。ちなみに下が State パターン

127 :デフォルトの名無しさん:2006/06/04(日) 03:19:31
>>125
違う違う。状態は予めセットしておくの。
んで showMessage したいときに currentState.showMessage()

128 :123:2006/06/04(日) 03:33:02
>>126
なんとなくわかりますが…
>>127
その状態はいつセットするんですか?
123のサイトの説明ではさっぱり。
currentStateには状態がかわった時にmornigなりdayなりがはいるんですよね?
実装がわからないです。
バカでもうしわけないです。

129 :デフォルトの名無しさん:2006/06/04(日) 03:46:21
>>128
いつセットするか……。
少なくとも showMessage の直前までには正しい状態がセットされてる必要があるね。


逆に考えると、『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
ってのも、メリットの1つじゃないかと。

130 :デフォルトの名無しさん:2006/06/04(日) 03:46:30
状態は変わったときだから
その場合は時間が経過した時になるかな?

showMessage()しかないから利点が見え難いかもしれない
朝・昼・夜にできることがshowMessage以外にも10種類あって
Timerで時間がたったときに状態を変更すると考えるといいかも

すると状態変更はTimerの監視部分だけになって
あとはstateを呼ぶだけで勝手に動作が切り替わる

131 :デフォルトの名無しさん:2006/06/04(日) 03:49:00
『状態がセット』 というより、『状態を判断するタイミング』 って言ったほうが良いかな。

タイミングってのは、コード上の箇所も含むよ。
先に状態を判断しておいて、後からその状態に従った動作を行わせるってのも State パターンで行えるし。

132 :123:2006/06/04(日) 03:56:15
うーん、いまいちよくわからないですね。
朝.showMessage();
昼.showMessage();
夜.showMessage();
の3つのメソッドを作って状態みてどれかのメソッドを呼び出す。
このやり方とサイトの説明の差は>>129さんの
『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
しかないように思えます。
今日はもう寝ます。明日また考えたいと思います。
みなさんありがとうございました。

133 :123:2006/06/04(日) 03:58:09
>>130さんのがなんとなくわかるかも…
明日その辺も考えてみます。

134 :デフォルトの名無しさん:2006/06/04(日) 04:13:05
>>132
ちなみに、こういうメリットもある。

State パターンってのは、『状態』 と 『その状態のときに行う動作』 を ”1つに” まとめておくから、 (>>126)
currentState.showMessage() するときには、currentState に何がセットされてて、どういう動作を行うのか考える必要はないんよ。
ただ showMessage() すれば、その状態に合った動作が行えるってことは保障されてる。

だから、勝手に MyState のサブクラスを自作して、それを currentState にセットしても動くかもね。

135 :デフォルトの名無しさん:2006/06/04(日) 20:30:10
たとえば後からStateに夕方を追加したくなったとすると

Stateを使わない方法では
1.currentStateに状態をセットする箇所に夕方の場合を追加
2.showMessageの中のifやswitchに夕方の場合を追加
showMessage以外にも似たメソッドがあったらそれら全ての中のswitch文を更新しなきゃならん。
つまり2の作業があちこちに散らばっていて見落としが起こりがちだし
ちょっと間違えると既存の朝昼夜の動作にもに影響が出かねない。

Stateクラスとしてまとまっている方法では
1.currentStateに状態をセットする箇所に夕方の場合を追加
2.夕方クラスを追加
クラスを増やすぶん、追加すべきコード量自体はむしろStateを使わない場合より多くなりそうだが
2の作業については変更箇所が新規クラスの追加という形で一箇所にまとまっているため
既存の朝昼夜は基本的に触らなくてすむ。

136 :135:2006/06/04(日) 21:22:31
補足。

状態ではなくメソッドのほうを増やしたくなったとき
Stateを使う場合では朝、昼、夜クラスのメソッドをそれぞれ追加する必要がある。

状態の種別のほうが追加や変更を受けることが多そうならStateを使うといい。

137 :123:2006/06/05(月) 11:43:58
いろいろと説明ありがとうございます。

・朝、昼、夜の状態で行いたい処理が複数ある場合はStateパターンを使う意味がある。
朝、昼、夜クラスとそれらを使うクラスの4つ
夕方が増えた場合の変更箇所 夕方クラス追加。使うクラスの分岐追加の2箇所。

・処理がshowMessage()のみの場合(処理がひとつの場合)Stateパターンを使う意味があまりない。
(状態が増える可能性はあるが処理が増える可能性はない。)
朝、昼、夜のshowMessage()メソッド3つ。
スイッチで各showMessage()をよびだす。
夕方が増えた場合の変更箇所 夕方メソッドの追加、スイッチの分岐追加の2箇所。

とゆう認識でよろしいでしょうか?
でもまだ疑問が。
いろいろサイトをみてまわったんだけど、ほとんどの所でStateパターンはifは使わないと書いてます。
でも今までのやり方だと状態を変える時結局ifが必要で、
ただのポリモルフィズムの説明に思えるんですが…

138 :デフォルトの名無しさん:2006/06/05(月) 12:01:57
>>137
>・処理がshowMessage()のみの場合(処理がひとつの場合)Stateパターンを使う意味があまりない。
割とそうではない場合も。このあたりはケースバイケース。

>でも今までのやり方だと状態を変える時結局ifが必要で、 
>>124

>ただのポリモルフィズムの説明に思えるんですが… 
認識としては全く正しい。多態を使用して、”オブジェクトで状態を表す”のが State パターン

139 :デフォルトの名無しさん:2006/06/05(月) 13:04:39
>>137

1.状態を変えるための判断としてのif
2.(今現在の)状態を判断するためのif

がごっちゃになってない?
Stateパターンだとifは使わないというのはおそらく後者のほうかと
前者はどうしようもないよね。


140 :123:2006/06/05(月) 13:35:35
りょうかいです。
すっきりすることができました。これでやっと次に進めます。
ありがとうございました。

141 :デフォルトの名無しさん:2006/06/06(火) 00:53:15
>>135
コード量では後者の方がむしろ追加分量が増えるという所が何とも吐き気がするんだが…w

142 :デフォルトの名無しさん:2006/06/06(火) 22:10:57
インデントとか改行みたいなもんだよ
コードの見通しを良くするために使う。
また、見通しが良くならないのであれば使うべきではない。

143 :デフォルトの名無しさん:2006/06/06(火) 22:18:34
一番大事なことは
状態のような概念をオブジェクトとして扱うという考え方
なんじゃないかと思う

144 :デフォルトの名無しさん:2006/06/07(水) 10:04:36
一昔前はオブジェクト=モノ。
モノに操作を与える=クラス。
だったすからねえ。

ていうかオブジェクト指向のオブジェクトって言葉が
もう時代にそぐわない気すらするですよ。

145 :デフォルトの名無しさん:2006/06/07(水) 10:30:27
エンティティのほうがまだまし?DBのほうで既成の用語なんで使いづらいけど

146 :デフォルトの名無しさん:2006/06/28(水) 20:36:15
この調子で幸せになれる議論をお願いします

147 :デフォルトの名無しさん:2006/06/28(水) 21:52:49
しかしやっぱ、そんなに議論する内容ってないよねこのスレ。

148 :デフォルトの名無しさん:2006/07/07(金) 23:17:05
commandパターンとstateパターンの違いがよく分からん。

commandパターンは、命令をクラス化して、その派生クラス
のexecute()を呼んで処理させる。
stateパターンは、状態をクラス化して、その派生クラスの
hogehoge()とか、fugafuga()を呼んで処理させる。

結局、名前が違うだけで考え方は一緒のような気がするんだ
が・・・という俺の愚痴。

149 :デフォルトの名無しさん:2006/07/07(金) 23:37:55
>>148
Strategy と State と Command は、どれも多態で処理を切り替えてるから、
おそらく知らない人が見れば同じに見えると思う。

ただ、意味的な物は随分異なる。重点はそこかと。

150 :デフォルトの名無しさん:2006/07/07(金) 23:44:15
そうかそうか。よーくわかったぞ。

151 :デフォルトの名無しさん:2006/07/08(土) 00:42:23
考え方は一緒だけど、使う箇所が違うってだけで分けられたパターンって結構あるよね。
前々スレあたりでGoFも一部の似たようなパターンは無くすとかいってなかったっけ?

152 :デフォルトの名無しさん:2006/07/08(土) 01:22:41
>>141
テストケースのコード量も加味して考えるといいのでは。

153 :デフォルトの名無しさん:2006/07/08(土) 02:29:05
StateとStrategyは構造は同じだけど、意味の区別がやや不明瞭。
Commandは意味も構造も違う。
GoFの原典を読むとそんな感じだな。

154 :デフォルトの名無しさん:2006/07/08(土) 02:58:41
そんな事いったらChainOfResponsibilityだってたんなるtree構造じゃん

155 :デフォルトの名無しさん:2006/07/08(土) 03:20:10
そうか。なるほど。うん。お前の言いたい事はよくわかったぞ。

156 :デフォルトの名無しさん:2006/07/08(土) 04:29:30
何がtree構造だ?馬鹿。

157 :デフォルトの名無しさん:2006/07/08(土) 19:50:03
どうやるとこのスレ盛り上がるのかな。

158 :デフォルトの名無しさん:2006/07/08(土) 22:03:22
なるほど。GoF信奉者は馬鹿ばっかりだという事がよくわかったぞ。

159 :デフォルトの名無しさん:2006/07/08(土) 22:04:42
ごめん。
オレが。
フェブってた。

160 :デフォルトの名無しさん:2006/07/10(月) 23:17:09
フェブってたという言葉がググレません。
トミーフェブラリーのことかー!

161 :デフォルトの名無しさん:2006/07/10(月) 23:24:07
ファブってたのtypoじゃないか

162 :デフォルトの名無しさん:2006/07/10(月) 23:30:05
ファブリーズのことかー!
それは言うならファビョるじゃないかな、たしか。

163 :デフォルトの名無しさん:2006/07/10(月) 23:31:22
>>162
残念、そこは落とすところだ

164 :デフォルトの名無しさん:2006/10/21(土) 01:39:05
現在ゲームをつくっていてどういうパターンを使えばいいか悩んでいます
アドバイスをお願いします。

空で変な生き物(まある種の鳥)が動き回るという部分を作っているのですが、
ここで鳥Aと鳥Bはお互いに相手の位置を参照して動きを決めます。

そのため、
空Skyのオブジェクトが鳥A,鳥Bへのオブジェクト参照していて、
同時に鳥Aと鳥BもSkyオブジェクトを参照するというデータ構造にしています。

このようなものを実装するのに適したデザインパターンを教えてください。

165 :デフォルトの名無しさん:2006/10/21(土) 01:40:01
age

166 :デフォルトの名無しさん:2006/10/21(土) 03:09:11
>>164
あえて言うなら Mediator

167 :デフォルトの名無しさん:2006/11/01(水) 21:48:53
>>164
表示という親クラスを作って
空、鳥A、鳥Bをそのメンバにする。
鳥Aと鳥Bの相互作用が絶対に必要なら
Birdsという鳥全体の動きを仕切るクラスを作って、
そこに鳥Aと鳥Bを入れる。

168 :デフォルトの名無しさん:2006/11/03(金) 19:06:17
>>164
Observer
はどうでしょう。
鳥Aは鳥Bの位置を監視し、その値がかわったら、自分(鳥A)の座標をupdateする。 
鳥Bも同様。


169 :デフォルトの名無しさん:2006/11/03(金) 19:11:56
>>168
無限ループに突入しないようにしないとな

170 :デフォルトの名無しさん:2006/11/17(金) 12:34:28
まだ結城本読了&自分のプログラムにいくつか採り入れる
っていうレベルで、まだGoFのカタログ読んでないです。

結城本のBridgeの「関連しているパターン」に
AbstractFactoryが載ってるんですけど
引用:
Bridgeパターンに登場するConcreteImplementor役を
環境にあわせて適切に構築するために、
AbstractFactoryパターンが用いられる場合があります

Implementorが「抽象的な工場」、ConcreteImplementorが「具体的な工場」
なのか
ConcreteImplementorが「抽象的な工場」で、それを継承して「具体的な工場」
なのか

状況次第なんですかね?
そろそろGoF読まなきゃと思いつつ、なかなかとっつきにくい

171 :デフォルトの名無しさん:2006/11/17(金) 23:07:26
そもそも

>Bridgeパターンに登場するConcreteImplementor役を
>環境にあわせて適切に構築するために、

構築されるものが ConcreteImplementor なんじゃないの?

172 :デフォルトの名無しさん:2006/11/21(火) 10:07:44
>>171
BridgeパターンのConcreteImplementorが
AbstractFactoryの「抽象的な工場(AbstractFactgory)」を構築するのか
「具体的な工場(ConcreteFactory)」を構築するのか

ということがわからんのです(;´Д`)

173 :デフォルトの名無しさん:2006/11/21(火) 21:52:55
>>172
AbstractFactory パターンを使って、ConcreteImplementor を作る、
だと思うよ。クラス図を書けばすっきりする予感。

174 :デフォルトの名無しさん:2006/11/22(水) 01:34:32
>>173
なるほど、そういうことだったんですか。。。
やっと頭の中でクラス図がぼんやりできてきました。

デザパタを教条的に使うだけじゃ、いかんですな。<自分
ありがとうございます

175 :デフォルトの名無しさん:2006/11/24(金) 16:24:47
http://www.01-tec.com/document/cpp_design_pattern.html#Adapter

これってふつうに

class Apple
{
public:
void NamePuts()
{
puts( "りんご" ) ;
}
void ColorPuts()()
{
puts( "赤" ) ;
}
} ;

class Banana
{
public:
void NamePuts()
{
puts( "バナナ" ) ;
}
void ColorPuts()()
{
puts( "黄" ) ;
}
} ;

って書き換えればいいのでは?

176 :デフォルトの名無しさん:2006/11/24(金) 16:39:37
>>175
書き換えられなかったらどうするのか、って話だ。

177 :デフォルトの名無しさん:2006/11/27(月) 16:52:58
>>175の天才ぶりにびびった。

178 :デフォルトの名無しさん:2006/11/28(火) 00:49:44
void ColorPuts()()

179 :デフォルトの名無しさん:2006/11/28(火) 10:45:59
>>175
あなた程の天才がなぜこんなスレを見てるのですか

180 :デフォルトの名無しさん:2006/11/28(火) 11:56:28
Adaptor - 貴方は委譲しますか?継承しますか?

漏れは原則委譲派

181 :デフォルトの名無しさん:2006/11/28(火) 20:42:59
>>180
case by case だけど、俺は継承だな……

182 :デフォルトの名無しさん:2006/11/28(火) 23:47:27
委譲(包含+転送)しか使ったことないです。

継承の方が優れてるケースってどんな時でしょうか。
基本的に adapter is a adaptee な状態にはならんので
継承使おうと言う気が起きないです。

183 :181:2006/11/29(水) 01:17:07
あ、ごめん。普通に勘違いした。委譲だ委譲。

よく考えなくとも Adapter クラスを継承することは大前提なんだよな。
すまね orz

184 :デフォルトの名無しさん:2006/12/11(月) 04:55:44
結局継承によるアダプターは誰も実践してない罠。

でもアダプターパターンの解説見てると
継承による方法が先の場合が多いのはなぜなんだぜ。

185 :デフォルトの名無しさん:2006/12/11(月) 09:15:54
委譲よりも継承の方が、初心者にはOOっぽく見えるんだぜ?

186 :デフォルトの名無しさん:2006/12/11(月) 23:52:47
継承による場合は override によって処理を上書きすることで
完全にコントロール出来ることが利点だと説明するサイトがあったが
コントロールしちゃったらアダプタでもなんでもないと思った。

187 :デフォルトの名無しさん:2006/12/28(木) 20:59:47
質問なんですが、ファクトリパターンってインスタンスが一つあればいいってのはわかるんですが、
メソッドをstaticじゃなくて、シングルトンパターンにする必要があるのですか?
どうせなら、インスタンス作らないで、staticメソッドにしてアクセスした方がいい気がするのですが
インスタンスを生成するかstaticにアクセスするかどちらの方がいいのですか?


188 :デフォルトの名無しさん:2006/12/29(金) 00:06:43
一概には言えまい
staticにしてしまうとファクトリ事態を抽象化することが出来んからな

189 :デフォルトの名無しさん:2006/12/29(金) 00:46:41
>>188
なるほど

190 :デフォルトの名無しさん:2006/12/29(金) 00:52:45
>>182
adapter has a adaptee?

191 :デフォルトの名無しさん:2006/12/29(金) 00:58:56
client → Target
        △
         |
       Adapter→Adaptee

TargetはClientに対するInterfaceだからAdapterがTargetを継承するのは当然なのでは?
AdapterはAdapteeに委譲するのは当然だし

192 :デフォルトの名無しさん:2006/12/29(金) 06:29:05
>>191
当然だと思う。

でも世のデザパタ解説サイトだと
「継承」「委譲」の2種類を例として出してる場合、
「継承」ではTargetはクラス、Adapterはそれを継承する形になってて
「委譲」ではTargetはインターフェース、Adapterはそれを実装する形になってる。
本質を考えれば継承の場合でもTargetはインターフェースだろ?と思うんだけど。
(というか継承はいらねえと思われ。)

オリジナルのGoF本を読んでないので分からんけど。

193 :デフォルトの名無しさん:2006/12/29(金) 08:14:40
>>192
クラスでもいいのでは?
Targetとしての振る舞いに共通なものがあるのだとしたら
抽象クラスとする事もアリだと思うけど

Client → Target
         △
         ;
      AbstractTarget 
         △      
          |       
        Adaptar  →   Adaptee

194 :デフォルトの名無しさん:2006/12/29(金) 08:29:13
まあ、↑みたいにするAdapterパターンの説明としては複雑になるから
省略してTargetをクラスにしてるんだと思うけど

195 :デフォルトの名無しさん:2006/12/29(金) 09:00:04
クラスが悪いとかクラスじゃできないとか言ってるんじゃなくて。

Client からは統一的に扱える、同じように見えるって側面を強調するなら
インターフェースでいいじゃねえかと。
委譲のパターンでもTargetはインターフェースで説明できるのに
そっちの方がより無駄のない本質的な説明になるのに、
なんでクラスなの?と。
(>>192では委譲・継承とクラス・インターフェースの組み合わせが逆だった。)

↓これが一般例で、他はもう特殊例でしょ?

      <<interface>>
client → Target <|・・・・・Adapter ・・・・・|> Adaptee
           implements     uses

ひどいところでは
継承使うパターンがデフォですよ、
単一継承でいかんともしがたい時には
委譲使うパターンで回避ですよ、
に近い説明すら行ってる。

なんかもうコードが共有されるなら継承が最高の解なんだよ、みたいな。
それは15年前に通ってきた道だろう、と。

196 :デフォルトの名無しさん:2006/12/29(金) 09:07:58
それをいったらデザインパターン自体が出てからだいぶ時間がたってるから
当時の説明をそのまま鵜呑みにしてもしょうがないでしょ。
もし初心者がそれ見て今の時代にアンマッチな知識をインプットしてしまう
事に懸念を感じるなら、自分で「こう解釈するのがいいですよ」って説明する
サイトでも立ち上げてみればいいw

197 :デフォルトの名無しさん:2006/12/29(金) 09:14:16
>>195
>↓これが一般例で、他はもう特殊例でしょ?
それは少し乱暴だと思うが・・・・・
そう熱くなるなよw

198 :デフォルトの名無しさん:2006/12/29(金) 16:58:29
>>195
っていうか、「委譲」って言葉の使い方間違ってね?

199 :デフォルトの名無しさん:2006/12/29(金) 21:21:49
Effective C++ みたいに、時代に合わせて新しくなるデザパタ本があればいいのにな。

200 :デフォルトの名無しさん:2006/12/29(金) 22:04:55
GoFのデザインパターンは、モデリングの世界の"Hello World"
見たいな物になってしまったンだと思うね

201 :デフォルトの名無しさん:2007/01/02(火) 19:42:57
ほす

202 :デフォルトの名無しさん:2007/01/02(火) 20:07:12
「それはパターンから外れているから駄目だ」とかは全然駄目なセリフの例ですね

203 :デフォルトの名無しさん:2007/01/04(木) 23:41:05
ほす

204 :デフォルトの名無しさん:2007/01/13(土) 13:53:11
いまさらデザインパターンを語ることはあるまい

205 :デフォルトの名無しさん:2007/01/13(土) 15:24:09
デザインパターンってもう語りつくされたん?

206 :デフォルトの名無しさん:2007/01/13(土) 15:36:31
語れるほど言葉を持たないというのが正確なところかw

207 :デフォルトの名無しさん:2007/01/18(木) 18:06:31
これはよく使うパターンって何?

208 :デフォルトの名無しさん:2007/01/19(金) 03:12:29
Iterator

209 :デフォルトの名無しさん:2007/01/19(金) 07:26:27
Singleton、Factory、Template あたりかなぁ。

210 :デフォルトの名無しさん:2007/01/19(金) 23:45:02
こんぽじっと

211 :デフォルトの名無しさん:2007/01/19(金) 23:47:05
こーるばっく、こまんど、

212 :デフォルトの名無しさん:2007/01/20(土) 01:28:34
微細主義,機能分割,集団無能化・・・

213 :デフォルトの名無しさん:2007/02/10(土) 20:34:33
結城さんのMLってどうやって送信先メールアドレスを変えるんだ?
進級2つ登録したから古い方だけ購読解除できればいいんだが

まぁ4月になればアドレスが使えなくなるから放置でもいいんだけど

214 :デフォルトの名無しさん:2007/02/10(土) 22:10:48
>>213
それって面白い?

215 :デフォルトの名無しさん:2007/02/11(日) 01:12:50
NullObjectのような、GoFの23には含まれていないパターンについて勉強したいのですが、
みなさんはどのように勉強されましたか?
個人的には本で勉強したいので、参考になる書籍などを示してほしいです。

216 :デフォルトの名無しさん:2007/02/12(月) 19:33:51
age

217 :デフォルトの名無しさん:2007/02/12(月) 19:38:25
boostのコードを読むと、すごい勉強になった

218 :デフォルトの名無しさん:2007/02/12(月) 20:29:48
>>217
kwsk

219 :デフォルトの名無しさん:2007/02/12(月) 20:55:12
デザインパターンを勉強すると、
自分が頭良くなってスゴイSEなったってカン違いするヤツ、
多いよな・・・

220 :デフォルトの名無しさん:2007/02/12(月) 20:59:00
一人前のSEって感じでしょ

221 :デフォルトの名無しさん:2007/02/13(火) 11:29:01
GOFデザインパターンはマイクロアーキテクチャーの一種に分類され、
その対象領域は一般にプログラムと呼ばれている、いわゆる動作単位であるから、
どの様に考えてもプログラマの職域に属する事項であるかと

222 :デフォルトの名無しさん:2007/02/13(火) 23:23:41
>>221
「マイクロアーキテクチャー」って一体何の事だか、
分かっている?


223 :デフォルトの名無しさん:2007/02/13(火) 23:58:25
SEではないな

224 :デフォルトの名無しさん:2007/02/14(水) 08:14:40
半導体設計が思い浮かんだ。

225 :デフォルトの名無しさん:2007/02/19(月) 23:50:05
>>219
結局デザインパターンって、フレームワーク作る時にしかあんまし使わないかなあ

226 :デフォルトの名無しさん:2007/02/19(月) 23:54:41
勉強が足らんな

227 :デフォルトの名無しさん:2007/02/20(火) 00:13:46
>>226
kwsk

228 :デフォルトの名無しさん:2007/02/20(火) 00:24:41
フレームワーク使う側でも使う。
java.lan.io.* なんてデコレータパターンの塊だし
コレクションフレームワークはそのままイテレータパターンの実装だし。

フレームワークが面倒見てくれない粒度の細かいオブジェクトの組み立てには
それはもうファクトリやらテンプレートやらのオンパレードさ。

229 :デフォルトの名無しさん:2007/02/20(火) 00:33:57
>>228
io自身がデコレータでしょ
使ってる側は意識しないはず

イテレータは素人でも使うよ

230 :デフォルトの名無しさん:2007/02/20(火) 00:43:25
イテこまし…いやなんでもない

231 :デフォルトの名無しさん:2007/02/20(火) 05:36:30
つーか、あるものを利用するだけで自分では使わないんだw

232 :デフォルトの名無しさん:2007/02/20(火) 15:50:13
プログラマなんてみんなあるものを利用するだけでしょ
アセンブラでもマシン語でも。

233 :デフォルトの名無しさん:2007/02/20(火) 23:18:29
いんや

234 :デフォルトの名無しさん:2007/02/22(木) 13:22:45
ゴフ!

235 :デフォルトの名無しさん: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 :デフォルトの名無しさん:2007/02/24(土) 19:14:56
他のクラス ──→ AIクラス
              △
        ┌───┼───┐
        │     │     │
        タイプA  タイプB  タイプC

だろ普通

237 :デフォルトの名無しさん:2007/02/24(土) 19:17:20
>>235
>キャラクタークラスは内部にAI処理を担当するクラスZをコンポジションでもっていたとします
これ、Composition とは言わないだろう……

>AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジション
だから、Composition じゃなくて Strategy

>からそのキャラクターのAIの動作を変更するために
今度は State?

>にもそれに応じたメンバ関数を
どういうメンバ関数? それほど増えるとも思えないが。

>もっとスマートなやり方は無いものでしょうか?
無い。これが上限であり下限。


割りきりが必要。極端に変な動作はさせないほうが吉。

238 :デフォルトの名無しさん:2007/02/24(土) 19:48:00
エエェェェ・・・?

239 :デフォルトの名無しさん:2007/02/24(土) 22:40:37
>>235
他のクラスオブジェクトへの参照を持つ事をコンポジションというのではないのですか?

ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、
いっそZへの参照を利用側に渡してしまおうかと思ったのですが、内部のオブジェクトの参照を
外部に渡してしまうのは好ましくないようなので、どうしようかと思ったのです。
Zのメンバ関数のいくつかは、キャラクタクラス以外のクラスから呼んで欲しくないものがあるので・・・。

240 :デフォルトの名無しさん:2007/02/24(土) 22:48:58
書き間違えました。

誤:ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、
正:キャラクタークラスにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、

です。

241 :デフォルトの名無しさん:2007/02/24(土) 23:35:06
>>240
ABCがAIだろうがキャラクターだろうが同じじゃハゲ

242 :デフォルトの名無しさん:2007/02/24(土) 23:44:26

         ┌─→AIクラス
         │     ◇
他のクラス ─┤     │              
         │     ↓               ┌→キャラクターA
         ├─→キャラクター <|─────┼→キャラクターB
         │                      └→キャラクたーC
         │                       ┌→キャラクターA用のセッター
         └─→プロパティセッター<|───┼→キャラクターB
                                  └→キャラクターA用のセッター

243 :デフォルトの名無しさん:2007/02/24(土) 23:45:17
まちがいたw      

         ┌─→AIクラス
         │     ◇
他のクラス ─┤     │              
         │     ↓               ┌→キャラクターA
         ├─→キャラクター <|─────┼→キャラクターB
         │                      └→キャラクたーC
         │                       ┌→キャラクターA用のセッター
         └─→プロパティセッター<|───┼→キャラクターB用のセッター
                                  └→キャラクターC用のセッター

244 :デフォルトの名無しさん:2007/02/24(土) 23:49:25
Javaで書くとこんな感じ

   AICharactor iaChar = ai.getCharactor();
   PropertySetter setter = PropertySetterFacotory.getSetter(aiChar);
   setter.set(iaChar,otherObject);

245 :デフォルトの名無しさん:2007/02/24(土) 23:53:52
プロパティじゃなくてパラメータだなw

246 :デフォルトの名無しさん:2007/02/25(日) 03:01:46
>>235
そういうときこそ継承使えばいいじゃない

247 :デフォルトの名無しさん:2007/02/25(日) 11:37:58
全 AI が必要とするパラメータを一つの巨大なクラスに集めて、それを渡すことにするとか。
各 AI はそのオブジェクトを一つ受け取って、自分に関係するメンバだけ触ることにすれば、インターフェイスは共通化できる。
AI が増えても、そのクラスにメンバを増やすだけで、他は一切書き換えずに済む。
再コンパイルは必要だろうけど。

248 :デフォルトの名無しさん:2007/02/25(日) 15:49:22
みなさん、ありがとうございます。
>>247
その方法も考えていました。なんかオブジェクト指向的に完璧な解決策じゃない
気がしていたんですが、それが一番手っ取り早いのかもしれませんね。

249 :デフォルトの名無しさん:2007/02/25(日) 16:03:31
・・・・・・・・

250 :デフォルトの名無しさん:2007/02/25(日) 18:16:05
パラメータをいじる権利のある人がAIを生成して
もしも途中でパラメータを変更する必要があるならそのままそいつが参照を持ちつづけ
キャラクタは自分が生成されるときにAIへの参照を貰い受けるような形のほうがいいと思う
パラメータを設定できないtickするだけのインターフェイスで貰えるならなお結構

251 :デフォルトの名無しさん:2007/02/25(日) 23:45:05
>>235
なんかよくわからんけど、直感的にBridgeパターンが頭に浮かんだ。違うかな。

252 :デフォルトの名無しさん:2007/02/25(日) 23:59:31
オブジェクト指向ってホントウに垣根が高いんだな・・・・

253 :デフォルトの名無しさん:2007/02/26(月) 01:18:21
たぶんずれると思うけど。

・ゲーム進行はキャラとAiBuilderを知ってる。キャラへAiをセットする
・キャラはAIだけ知ってる
・AiとABCTypeはAiBuilderによって生成される

ゲーム進行 ----> AiBuilder-------
↓ ↓ |
キャラクタ ----> <Interface>Ai |
△ |
| ↓
AType BType CType

254 :デフォルトの名無しさん:2007/02/26(月) 01:20:08
ずれすぎてだめだった。
ABCはAiのサブクラスね。

255 :デフォルトの名無しさん:2007/02/26(月) 09:15:43
全角スペースを使い玉へ
半角スペースは続けて使うと一つにまとめられちゃうのだ

256 :デフォルトの名無しさん:2007/02/26(月) 10:19:21
テスト
     あああ

257 :デフォルトの名無しさん: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 :デフォルトの名無しさん:2007/02/27(火) 00:52:10
>>256
これは専ブラが半角スペースをユニコードに変換するタイプなんでおkなんだよ

259 :デフォルトの名無しさん: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 :デフォルトの名無しさん:2007/03/02(金) 23:54:31
最近はaspectあるからVisitor要らなくね?

262 :デフォルトの名無しさん:2007/03/03(土) 00:40:04
なわけないだろ。
aspectとかDIって害虫だろ。
そんな迷走してるより、
とっととクロージャ取り入れて、正常進化して欲しい。

263 :デフォルトの名無しさん:2007/03/03(土) 00:47:05
なわけないだろ。aspectとDIは本流だろ。

264 :デフォルトの名無しさん:2007/03/03(土) 03:17:43
AOP&DIの文脈でクロージャの話が出る理由が分からん。

265 :デフォルトの名無しさん:2007/03/03(土) 07:14:09
それが正常進化とも思えん

266 :デフォルトの名無しさん:2007/03/03(土) 09:17:01
クロージャはDにもあるし、Javaにもいずれ実装されるからだろ。

267 :デフォルトの名無しさん:2007/03/03(土) 15:14:26
Javasist 系は、VM が後方互換のないバージョンアップをしたとき、
手の打ちようがないよな。
Aspect がうまい具合に言語仕様に入るなんてこともなさそうだしな。


268 :デフォルトの名無しさん:2007/03/04(日) 15:52:16
ランタイムでウィービングすりゃいいじゃん。

269 :デフォルトの名無しさん:2007/03/14(水) 21:49:37







           2ちゃんで煽りながらデザパタ学習した池沼が



           古い話題を壊れたレコードのように繰り返すスレ







270 :デフォルトの名無しさん:2007/03/14(水) 22:07:11

敢えて言うほどの事でもないがの

271 :269:2007/03/14(水) 22:13:31
こんなスレ未だに見てる奴が居る事実に感動
元お豆のsずきさんかな

272 :デフォルトの名無しさん:2007/03/16(金) 02:19:28
たかひろくんのデザパタ幼稚園

273 :デフォルトの名無しさん:2007/03/16(金) 10:43:46
>>33の発言は間違い。

274 :デフォルトの名無しさん:2007/03/21(水) 09:22:19
ごふっ

275 :デフォルトの名無しさん:2007/03/26(月) 17:59:37
質問です。
テンプレートメソッドパターンを適用しようとして気になったのですが、
ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう?
(内容が同じになるものが複数組あります)
内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、
このままでは冗長です。

ぱっと思いつくのは、組ごとに共通のクラスを作っておいて
各コンクリートクラスは共通クラスのただのラッパーになる、という設計ですがおかしいでしょうか?

使っているのはPHP5なので多重継承はできません。

276 :デフォルトの名無しさん:2007/03/26(月) 18:21:23
age!

277 :デフォルトの名無しさん:2007/03/26(月) 19:05:42
ConcreteClassのユーザーから見て、
その「処理が同一だけど異なるクラス」とやらは
「全く同じクラス」にしてはいけないものなの?

278 :275:2007/03/26(月) 19:18:30
微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。

例えば、
http://www.techscore.com/tech/DesignPattern/TemplateMethod.html
ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に
public class TanakasWoodCutPrint extends WoodCutPrint{}

public class SuzukisWoodCutPrint extends WoodCutPrint{}
の二つが同じ内容になってしまう、という場合にどうすれば良いのか?という事です。

279 :デフォルトの名無しさん:2007/03/26(月) 22:00:25
木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの?

280 :デフォルトの名無しさん:2007/03/26(月) 22:44:58
差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。
もう一階層挟んだら綺麗にまとまったりしないかとか。

281 :デフォルトの名無しさん:2007/03/26(月) 23:44:55
メモリが必要になったときに一度だけ生成されて、それ以降の記述では
必ず最初に確保されたメモリが使われるようなパターンは何というの?

C++風に描けば

if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る
aを使った処理…

全部グローバル変数にすればいいんだろうけど、使わない領域は
確保したくないって時にやる(a が不要になったときは回収してもOK)


282 :デフォルトの名無しさん:2007/03/26(月) 23:46:53
>>281
しんぐるとんだろ?

283 :デフォルトの名無しさん:2007/03/26(月) 23:49:00
>281
Singleton

284 :275:2007/03/27(火) 12:17:40
>>279
>>275で書いた共通クラスというのはそういうイメージなのですが、
タイプAクラス、タイプBクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね?

>>280
symfonyでモデルクラスをDBスキーマから自動生成後、
各モデルクラスに同じ機能を持たせたい(基本的にその機能の実装はモデルクラス毎に違うが、同じものもある)というケースです。


285 :デフォルトの名無しさん:2007/03/27(火) 22:52:26
っていうか、そのモデルは何を表してるモデルなのよ?
DBから生成されたものに後付で持たせたい機能って言う意味がわからん
モデル=状態ならばそれ自体が処理するメソッドを持たすべきではないな

286 :デフォルトの名無しさん:2007/03/27(火) 23:18:27
なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。

287 :デフォルトの名無しさん: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 :287:2007/03/28(水) 07:36:24
>>280ではなく>>275

289 :デフォルトの名無しさん:2007/03/28(水) 10:14:53
symfonyってのをちらっと眺めた感じだと
>・DBエンティティをそのまま表したクラス(状態)
どうもこっちみたいだから、
そもそも適用するレイヤを間違ってる説が有力。

290 :デフォルトの名無しさん:2007/03/28(水) 10:51:39
ODBMS屋乙。

> そもそも適用するレイヤを間違ってる説が有力。

それは前提を勝手に仮定した偏った意見に見える。
>>275の話が
 ・どのようなアプリケーション・アーキテクチャ〜レイヤ構成を前提としているか
 ・一つのレイヤ限定の話なのか
 ・複数のレイヤにまたがった話なのか
によって、いくらでも回答の仕方があるだろう。

例えば、
下のレイヤで、オブジェクトの静的状態をDBMSに格納し、
上のレイヤで、オブジェクトの振る舞いをどう扱うか
という問題を仮定した場合にも、
・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法
・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態
 を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法
の二通りが考えられる。

>>287は、後者の立場から説明した。

291 :デフォルトの名無しさん:2007/03/28(水) 10:58:15
補足:
前者の立場でも
  DBMSエンティティ=静的状態=ドメインオブジェクト 
と呼ぶことがあるが、
オブジェクト指向本来のドメインオブジェクトは、後者。

292 :275:2007/03/28(水) 12:42:19
symfonyは一つのテーブルから二つのクラスを生成する。
テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。(後者にConcreteStrategyを持たせてる)
問題領域に現れるクラスが内部的な実装方法としてDBにデータを保存するようになっているだけ、と考えてる。
なのでそのクラスにそのデータを使うメソッドを書こうかと。

今、>>287の方法でやっていますがこれで良さそうです。
ありがとうございました。

293 :デフォルトの名無しさん: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 :デフォルトの名無しさん:2007/03/29(木) 00:34:25
×;DrawProcessor drawProcessor = coodinator.getCutProcessor();
○:DrawProcessor drawProcessor = coodinator.getDrawProcessor();

w

295 :デフォルトの名無しさん:2007/03/29(木) 12:59:19
>>293-294
>    public void doWoodCutPrint(){

身元バレバレっすよ兄貴ぃ

閑話休題

他の言語、他のフレームワークを使っている人間に
余計なコメントをつけても混乱するだけだ。
もしアドバイスをつけたいなら、Javaではなく
PHP5+symfonyの例に即したアドバイスをしろ。

例えば、
・ データクラスの生成(検索、保存)
・ データクラスの処理(計算、処理)
はべき乗パターンに則って別クラスにすべきだ、などという説は
そのような冗長な設計が「PHP5+symfony」に適しているかどうか、
という観点で議論すべきである。

だが、俺はそこまで突っ込むつもりはない。
そんな事をいちいち調べるつもりはないし、
質問者も困惑するだけだからだ。

296 :デフォルトの名無しさん:2007/03/29(木) 13:11:21
>>293
つか、今気付いた。
おまいは TemplateMethod Patternを共用したい
という質問に対して、全然別の回答をつけている。
特に、クラスの命名がデタラメだ。

×× public WoodCutPrintContext{ ... }
×  public class WoodCutPrintContext{ ... }
○  public class WoodCutPrintProcess { ... }

297 :デフォルトの名無しさん:2007/03/29(木) 14:58:49
----------------------------------------------------------------------------
デザインパターンにおける Contextの用例

1. Interpreterパターン
  http://www.hellohiro.com/pattern/interpreter.htm
  言語に対して、文法表現(Expressionクラス)と、
  文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。
  (注: Inerpreterクラスは付帯的に、言語の束縛〜副作用を表す評価環境(Context)を持つ)

2. Stateパターン
  http://www.hellohiro.com/pattern/state.htm
  オブジェクトの内部状態が変化したときに
  オブジェクトの処理内容を変えられるようにする。
  (注: オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
     個々の内部状態とその処理内容をConcreteStateクラスとして実装する)

----------------------------------------------------------------------------
>>293のクラス名 WoodCutPrintContext は、
クラスの役割を表現しておらず不適切な命名と言える。

298 :デフォルトの名無しさん:2007/03/29(木) 15:32:52
----------------------------------------------------------------------------
デザインパターンにおける Contextの用例 【追加と訂正】

2. Stateパターン 【訂正】
  × (注: オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
     個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
  ○ (注: ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。 ←【訂正】
     個々の内部状態とその処理内容をConcreteStateクラスとして実装する)

3. Strategyパターン 【追加】
  http://www.hellohiro.com/pattern/strategy.htm
  Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。
  それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。
  (注: ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。
     個々のアルゴリズムは、個別のConcreteStrategyクラス (〜A, 〜B, 〜C)に記述する。
     個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。)

----------------------------------------------------------------------------
もしかして >>293は、
  鈴木、田中 == StrategyパターンのConcreteStrategyクラス、
  WoodCutPrintContext == Strategyパターンのクライアント (Contextクラス)
と言いたかったのか?
だが、それでは
 ・鈴木と田中が同じ手順(Strategy)で版画を彫る 
 ・鈴木が田中の手を借りて版画を彫る
が全く同じ表現になってしまう。これは不適切だ。

299 :デフォルトの名無しさん:2007/03/29(木) 16:59:49
↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。
「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。


300 :デフォルトの名無しさん: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 :デフォルトの名無しさん: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 :デフォルトの名無しさん:2007/03/29(木) 18:38:56
エロゲで使われているパターン

Singleton

他なんかある?

304 :300: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
デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。

プロトタイプ作成時は、「版画」は1種類だけ考えれば済むから、
その版画作成に使う版材も、処理手順も、詳細処理方法も1種類ずつで済む。
・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、
  開発もバッチグーね?とお気楽モード。

ところが開発展開になってから、
「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、
「異なる版画には、異なるサイズや材質の版材が必要」な事とか
「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」
ってな事にも、おそまきながら気付く。
                        アーキテクチャ設計ハターンwwww
・・・いや、気付いてても気付かないフリしたんだろう、
  アーキテクチャ設計のボンクラ共は。

じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・
幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。
その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったwww
共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。

それでは、正しい解決方法はどこにあるのか
それを私は知っているが、このレスにはもう余白がないので書けないw




308 :鈴木:2007/03/29(木) 22:31:38
おまいら、俺の名前を気安く使うな、不愉快だぞ
続きは「佐藤クン」で

309 :デフォルトの名無しさん:2007/03/29(木) 22:37:17
上がダメなら、下の名前ならおk?

例えばひろゆきとかゆきひろとかたかゆきとかあと

310 :デフォルトの名無しさん:2007/03/29(木) 22:49:30
問題はドメイン・モデリングの欠落だなw


311 :デフォルトの名無しさん:2007/03/29(木) 22:55:01
問題領域が「版画作成」なら、最終目的は「版画」だけど、
問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ〜よなw
つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話

312 :デフォルトの名無しさん:2007/03/29(木) 22:57:26
「業務処理」の目的は、DB更新と電文(w。

313 :デフォルトの名無しさん: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 :デフォルトの名無しさん:2007/03/29(木) 23:05:28
>>309>>315
 見事なまでのプロダクトラインだなw

317 :デフォルトの名無しさん:2007/03/29(木) 23:07:17
閑話休題

318 :デフォルトの名無しさん:2007/03/29(木) 23:10:48
>>312
ある種の基幹系業務システムは、
構築難易度を下げて抽象化すると、
結局、マスタメンテ型アプリに帰着する。

すると、最終目的がマスタ更新ってのも
そんなにずれていない。
するとオブジェクト指向で書く必要ないんだな、これが。

(終了)

319 :デフォルトの名無しさん:2007/03/29(木) 23:13:24
)再開(

320 :デフォルトの名無しさん:2007/03/29(木) 23:17:09
GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙w

321 :デフォルトの名無しさん:2007/03/29(木) 23:17:18

ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。

322 :デフォルトの名無しさん:2007/03/29(木) 23:22:56
>>321
M$のHワラ氏、ITアーキテクチャ誌に連載してたね、2年ほど前。

CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、
所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ)
ちょっと後悔(ウツウツウツウツシクウツウツシクシクウツウツウツウツウツシクシクシクシクウツウツウツ

そんな事じゃいかん。俺はCMU/SEIはともかくとして、
日本のCMMI連中とは全然話が合わないんだったw

なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの?(爆


323 :デフォルトの名無しさん:2007/03/29(木) 23:29:25
>>322
特に無い。

324 :デフォルトの名無しさん:2007/03/29(木) 23:38:44
>>320
確かに飽きてきたのも事実
だが使いこなせてる奴が意外と少ないのも事実

325 :デフォルトの名無しさん:2007/03/29(木) 23:45:29
だが使いこなせてる奴は10年前から退屈してるのも事実

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書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。

     http://pc11.2ch.net/test/read.cgi/tech/1172431242/

327 :デフォルトの名無しさん:2007/03/29(木) 23:56:05
糞コード放置してった >>293
今どこで野垂れ死んでいることやら

328 :デフォルトの名無しさん: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に取り入れるべき言語機能やパターンを
発見できるかもしれない(もう金脈は小さいと思うけどな)。

文句ばっか言って他をけなしてないで、
学ぶところは学びなさいってこったw

331 :デフォルトの名無しさん:2007/03/30(金) 00:24:32
関連ないが、Perlのプロトタイプ系OO拡張、あれは結構糞だ。
OOの面倒くさい所と、Perlのいい加減な所がダブルで来る。
でも、Javaと同様なクラスライブラリ書き始めると、
あっちの方がよっぽど融通利いて手早く完成する。
さすが90年代のLispと呼ばれただけの事はあるな。

関連ないが、Javascriptのプロトタイプ系OO機能、あれは最高だ。
あれ一つでずいぶんJavascriptのコードが書きやすくなる。
問題はjavascriptエンジンのバグやエラー報告の不充分さ。
あれ使って10年程前にAJAX風アプリ書いてた時は、
試行運用中に山のように実行時エラーがでて閉口した。
今の連中は幸せだよなぁ。あれで、Netscapeがまだ生き残ってたら
万々歳なんだが。

パターン関係ないチラ裏スマソ

332 :デフォルトの名無しさん:2007/03/30(金) 00:26:57
>C++やJavaよりよっぽどSmalltalk寄り。

て言われても、Smalltalk てそんなにいいのか?
動的言語と言われた時点で、うーみとなりそうだけどなぁ。
型は、事前に論理的誤りを検出するためにあるんだぜ?
それを最初に省いたら、あとから泣きみるだろ。
それでデザパタが必要とされるような大規模開発に
向いてるといえるのだろうか?

333 :デフォルトの名無しさん:2007/03/30(金) 00:27:09
> OOは大規模開発向け

だなんて地に足のついてない発言してる人が
まだ国内に居ると知って、ワロタ

済まないが、実績作ってから言ってくれ
おまいらの作ってるのはOOじゃねぇだろ
単にOO系言語でOOP風の事をしました(でも中身はCOBOLそっくり)
だろ

334 :デフォルトの名無しさん:2007/03/30(金) 00:28:45
>>232
あぁーあ。今度はCS系関数言語厨房か。
マイクロソフトリサーチの人が
なんとかしてくれるだろ。

335 :デフォルトの名無しさん:2007/03/30(金) 00:29:28
> デザパタが必要とされるような大規模開発

どっから出てきた妄想ですか?

336 :デフォルトの名無しさん:2007/03/30(金) 00:31:22
すげぇずうずうしさだなコイツ

>>306-307, >>310-312, >>318
大規模(自称)OO開発の失敗例
ケーススタディしたばっかだっつうのに、
解決策も出さずに「大規模OO開発」かよ。


337 :デフォルトの名無しさん:2007/03/30(金) 00:32:59
なんだよ、Py厨だけじゃないのかよ。
てか、py厨が引っ掻き回してるのか?

ただな、デザパタなんてなくてもやれるし、あったらあったで
便利だし、ぐらいのところでいいだろ。

実際、それ以上でもそれ以下でもないし。

338 :デフォルトの名無しさん:2007/03/30(金) 00:33:59
> 型は、事前に論理的誤りを検出するためにあるんだぜ?

そんなキミには、汎用純関数型言語Haskellを使って、
monadic programmingを駆使した通信ミドルウェア開発が
オヌヌメ。使用検証技術も必須だよ?jfitsの人がやってるような奴

339 :デフォルトの名無しさん:2007/03/30(金) 00:36:05
大規模(自称)OO開発の失敗例 ケーススタディ  >>306-307, >>310-312, >>318
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

に解決策提案するまで、
大規模OO開発へのデザインパターン適用の話題自粛で
お願いします。


340 :デフォルトの名無しさん:2007/03/30(金) 00:36:10
何この盛り上がりようw

341 :デフォルトの名無しさん:2007/03/30(金) 00:37:31
たかびー祭+ピチョンパターン祭 合同イベント

342 :デフォルトの名無しさん:2007/03/30(金) 00:40:04
おいおまいら騒ぐな

> 大規模OOにデザパタ必須
って言ってる人の大規模は、
せいぜい数千行〜数万行ぽっちの事だぞ、きっと

343 :333=336:2007/03/30(金) 00:42:56
>>328

どうぞご自由に個人〜数人の範囲で
大規模開発しててくださいです。
いや、それくらいの規模が一番いいと思うよ。
がんばれー

火ぃ噴くのは、プログラムもろくにできないのが
数十人単位で集まっちゃうような地獄の話だからw

344 :デフォルトの名無しさん:2007/03/30(金) 00:44:49
なんなんだよ、この盛り上がり。
そんなにヒマがあるなら、その、なんだ、Pythonのその膨大な過去の
素敵なコードの資産から、スマートなパターンを抽出して、
俺らをあっと言わせてくれよ。
もう、ずいぶん作業は進んでるんだろ?
ここで威張ってるぐらいなんだから。

345 :デフォルトの名無しさん:2007/03/30(金) 00:46:34
>>344
/~ytakagi/ に直接言え。
もっとも連絡先も書いてねぇけどw

346 :デフォルトの名無しさん:2007/03/30(金) 00:48:29
盛り上がってもいいけど、もっと具体的な話してくれ。
抽象論は聞き飽きた。

347 :293:2007/03/30(金) 00:50:44
物凄いレス着いたw

>>295
PHP5+symfonyなんてしらね

>>296-297
で座パタなんてクソ喰らえw

>>298
> WoodCutPrintContext == Strategyパターンのクライアント (Contextクラス)
>と言いたかったのか?
その意味も含んでるけど
>だが、それでは
> ・鈴木と田中が同じ手順(Strategy)で版画を彫る 
> ・鈴木が田中の手を借りて版画を彫る
>が全く同じ表現になってしまう。これは不適切だ。
が意味不明。
どこをどうすれば鈴木君と田中君の接点が見えてくるのか?

>>300
勝手に解釈して話を進めないようにw

>>301-
目が疲れたから読めん

っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
ソコを主体に考えてしまう悲しい性がワロスw

348 :デフォルトの名無しさん:2007/03/30(金) 00:50:51
一体何を聞きたいんだ?

・ソフトウェア・プロダクトラインのための資産管理
・大規模開発へのOOおよびデザパタ適用の是非
・そのほか

349 :デフォルトの名無しさん:2007/03/30(金) 00:54:30
とりあえず、>>293
・話の発端(PHP5+symfony)も見えてないし
・クラス命名のセンスもないし
・クラス設計のセンスもないし
・等価コードの意味も理解できないし
・目が悪くて人の話も聞かない
奴である事だけはかろうじて理解できた

でなんか用かよタコ

350 :デフォルトの名無しさん:2007/03/30(金) 00:59:16
> >だが、それでは
> > ・鈴木と田中が同じ手順(Strategy)で版画を彫る 
> > ・鈴木が田中の手を借りて版画を彫る
> >が全く同じ表現になってしまう。これは不適切だ。
> が意味不明。
> どこをどうすれば鈴木君と田中君の接点が見えてくるのか?

お前はシャレも解せぬ不粋な人間だと理解した

351 :デフォルトの名無しさん:2007/03/30(金) 01:00:00
> っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
> ソコを主体に考えてしまう悲しい性がワロスw

はいはい釣れた釣れた

352 :293:2007/03/30(金) 01:09:32
終わりか?
>・クラス命名のセンスもないし
>・クラス設計のセンスもないし
それは否定できんなw
ほいじゃーね

353 :デフォルトの名無しさん:2007/03/30(金) 01:09:50
思い切り東陽町スタイルだな。あの糞コード

354 :デフォルトの名無しさん:2007/03/30(金) 01:11:19
> public WoodCutPrintContext{

単にソースコード保守するだけの
運用チームじゃないかな、彼は

355 :デフォルトの名無しさん:2007/03/30(金) 15:41:55
>>293の元設計の問題点

1. 詳細設計〜実装の主眼を「コード再利用率の向上」に置いたのが誤り。
  小手先のテクに走らず、分析〜設計段階で一貫したドメインモデルを用い、
  それを素直にコード化して、保守性・拡張性を高める事こそ重要である。

2. 継承や委譲を駆使した「差分コードプログラミング」は煩雑過ぎて人間の手に余る。
  もし本気で「差分コード」を扱いたいなら、アスペクト指向開発方法論(AOSD)を取り入れ、
  差分定義の組み込みはAOP言語のweaving機能に任せろ。人間の手でやるな。
  ・・・だが残念な事に、アスペクト指向言語はまだ底辺現場で使える段階にはない。

つづく

356 :293:2007/03/31(土) 00:03:16
>>293から50レス以上あって
くだらない能書きは大量に吐き出されたが
もっと良い解決方法を提示するコードが出てこないとはw
所詮は口だけ、本を読んだだけの頭でっかちで現場で使えん奴らばかりだなw
コリャデスマがなくならないわけだ

357 :デフォルトの名無しさん:2007/03/31(土) 02:06:50
お前のコードの問題点は示しただろ?すずき


358 :デフォルトの名無しさん:2007/03/31(土) 10:55:10
>>356
一応いっておくが、おまいに絡んでるのはキチガイ一人だけだ。

359 :デフォルトの名無しさん:2007/03/31(土) 11:48:32
>>358
議論しているのをキチガイ呼ばわりする奴って
どこにでもわくのな

360 :デフォルトの名無しさん:2007/03/31(土) 11:52:26
【ひろたかと2ちゃんの不思議な関係】

・ひろたかがかつて在籍していた会社は全て、ひろたかが去った直後に
 2ちゃんでしつこく攻撃される。

・ひろたかの元仕事相手、脳内ライバル、
 その他ひろたかが自分にとって脅威だと感じる対象は、
 2ちゃんのあちこちのスレに中傷文が書かれる。

・ひろたかが出没するスレには
 常に「キチガイ」「発狂」を連発する荒しが発生する。

・2ちゃんに居る頭も性格も悪い粘着に               ← いまココ
 噛んで含めるように高度な概念を教えてやると、
 いつの間にかたかひろ本人も同じ意見を主張するようになるw

・ひろたかは論破されていても、それに気付かないフリをして勝利宣言をする。
・ひろたかは論破されると、他のスレで暴れる。
・ひろたかは成りすまし/匿名発言をよくするが、それが見破られると
 「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。

さ〜て、また荒しが発生するのかなw

361 :293:2007/03/31(土) 12:56:20
>>358
そういわれるとちょっと寂しい気も・・・w
>>357,359
議論になってな(ry
>>360
「いまココ」ってところで、「ひろたか」が「たかひろ」になってるってことか・・・w

362 :デフォルトの名無しさん:2007/03/31(土) 13:15:59
>>361
議論になっていないと考える低脳はお前だけだ

363 :293:2007/03/31(土) 13:27:20
だってボク低脳ですから

364 :デフォルトの名無しさん:2007/03/31(土) 13:39:50
>>293の元設計の問題点 (つづき)

2-1. Bridgeパターン・スパゲティ (クラスの過剰分割によるOOモデルの崩壊)

 >>293のコードで省略されているクラス/コードを補足すると、>>304 のようになる。(※1)
  ※1.createWoodCutPrint() の //{ ... //} 内は、下記の等価コード。
    WoodCutPrintContext.getInstance().doWoodCutPrint()

 >>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、
 「Coordinatorパターン」とでも呼ぶべき「変形Bridgeパターン」を導入し、
 Coordinatorで処理詳細の選択できるようにした。
  (注:蛇足だがこの種のカスタマイズには、
    古くから使われている DI (Dependency Injection)パターンの方が適している。
    更に蛇足だが、カスタマイズ内容はコード中に直接記述したりはせずに、
    外部ファイル(XML形式)に分離記述して後から変更可能にするのがマナーである。

 このコード(>>293, >>304)は、その字面の単純さにもかかわらず、
 挙動を読み取りにくく、保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)

365 :デフォルトの名無しさん:2007/03/31(土) 13:55:01
くだらねえことをいつまでもグダグダ書いてるが、>>275の問題の本質は
「テーブルとクラスをどうやってマッピングするか」ってところにあることに気づけや。
マッピング後のクラス設計以前の問題。

んでhibrenateとか見る限り、今のところ碌なやり方は存在しない。

366 :デフォルトの名無しさん:2007/03/31(土) 13:59:48
うっせぇぞ低脳。

お前はさっさとODBMS営業逝ってこいや
負け犬が

367 :デフォルトの名無しさん:2007/03/31(土) 14:03:10
ODBMS(w

ぷぷぷ

もう10年前にたかひろの子分に
「(製造業など一部の特殊分野を除いては)
 仮想記憶方式のODBMSなんてもう売れねぇよ」
って伝えたはずだけど。まだ悪あがきしてたんか。おめでてぇなw

368 :デフォルトの名無しさん:2007/03/31(土) 14:10:47
そん時に提示した代替手段が、
・ ORマッピングによるRDBMSとの共存
・ Stonebreaker氏のORDBMSの発展
だったな。

369 :デフォルトの名無しさん:2007/03/31(土) 14:41:39
>>293の元設計の問題点(つづき2)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

 >>293のコード(及び>>304の補足コード)は、その字面の単純さにもかかわらず、
 挙動を読み取りにくく、保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)

 (1)挙動を読み取りにくくなる原因:
  原因(1-1) データと処理の分離記述による、カプセル化の破壊。
 (2)保守性が悪い原因:
  原因(2-1) カスタマイズ内容のハードコーディング。
     クラス選択の変更や、クラスの新規追加の度に、コード修正が必要になる。
 (2)前提条件の変化に対し柔軟性が低くなる原因:
  原因(3-1) モデルの過剰な単純化により、現実世界の複雑な問題に適応できなくなる。

 以下では、その原因を探る。
 原因(1-1)データと処理の再分離による、カプセル化の破壊
    オブジェクト指向では、データとその処理をカプセル化し、クラスを導入する事で
    (1)データ操作の局所性
    (2)外部操作インタフェースの限定、
    (3)型システムによる安全性/信頼性の向上
    が可能になり、それを利用してプログラムの信頼性/可読性/保守性の向上を図れる。

    しかし>>293,>>304のコードでは、
    データ(Hanzai及びバリエーション)と処理方法(〜Processor)を別々のクラスに分離記述した後、
    関連するデータクラスと処理クラスを適切な方法で再カプセル化しなかったため、
    オブジェクト指向のメリットが得られなくなっている。(非OO的コード)

370 :デフォルトの名無しさん:2007/03/31(土) 14:59:40
>>355>>364>>369
その問題点を直したスケルトンコードを頼む

371 :293:2007/03/31(土) 15:13:25
>>365が僕の考えからは少し極端な意見だがいいこと言った。
まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに
とらわれないコードを書いたんだがね。
自分のレスの後だったんでよっぽど悔しかったんだろうw。
だが少しだけ付き合ってあげようw

> >>293のコードで省略されているクラス/コードを補足すると、>>304 のようになる。(※1)
なりません。

> >>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、
・・・・
> このコード(>>293, >>304)は、その字面の単純さにもかかわらず、
> 挙動を読み取りにくく、保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
カプセル化を否定しているように聞こえるが?

そもそも鈴木君や田中君をドメインとして(まぁドメイン領域内のある部分ではあるが)時点で設計が
崩壊してるんだけどw
>>278の要件を分析してみると、

1.このケースの主処理は木版が作成プロセスである。
2.鈴木君や田中君は木版画作成プロセスのバリエーションである。

この2点から、木版画作成プロセスを中心に考えて、どのように違いを吸収していくかを考えないと遺憾のとちゃうの?
で、

3.木版画作成プロセスから見た場合、鈴木君や田中君(、山田君、佐藤君・・・・)の役割は、
  木を塗ったり切ったり印刷したりの方法論を持っているオブジェクト。
4.鈴木君や(略)画持っている方法論は、皆違う場合もあれば同じ場合もあるから、鈴木君や田中君(ry)と独立するべき。
  (そもそもの>>275の要件)

となるのが自然な設計だと思うけど?

372 :365:2007/03/31(土) 15:25:41
>>371
キチガイにかまわないであげてください。

373 :293:2007/03/31(土) 15:34:06
>>372
むむ・・・
スレが荒れてしまいますな・・・
まぁ彼が言うクラス粒度が細かくなりすぎると見通しが悪くなるのは事実だけどね
その辺の加減が難しい・・・

374 :デフォルトの名無しさん:2007/03/31(土) 15:51:23
 -- 引き続き、元質問者(>>275) の挙げた例題(>>278) を題材に、 --
 -- デスマ現場で発生した問題 (>>306-307) を論じる。       --


375 :デフォルトの名無しさん:2007/03/31(土) 15:53:01
>>293の元設計の問題点(つづき2)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

 原因(3-1)モデルや型の過度な単純化による、複雑な問題への適応能力低下。
    現実の問題は、>>293のような単純な構造は持っていない。

    まず、データにはバリエーションがある。
    例えばデスマ事例(>>306-307)で指摘されているように、
    操作対象となるオブジェクト/データ(Hanzai)は一種類ではなく、
    実際には何種類ものバリエーションが存在する。(分析モデル)
     Hanzai <─┬ 原料Hanzai <─┬ 木版<─┬ 柔かい木版
           │         │    └ 硬い木版
           │         ├ ゴム版
           │         ├ 芋版
           │         └ 銅版
           ├ 加工中Hanzai<─┬ 下絵中Hanzai
           │            └ 切除中Hanzai
           └ 完成した版画版
     ※ ここでHanzaiのサブクラスは、
      工程進行に伴う状態変化 (原料→下絵中→切除中→完成) と見なせる。
      ただし、後工程になるほどデータの内部構造は複雑になっていく。
    
    次に、データはしばしば単純なモノシリック構造ではなく、
    複数のデータを内部構造として持つComposite構造を持つ。
     完成した
      版画版 ◇┬ 背景部 ◇─(略)
     (人物画)  └人物部 ◇┬ 頭髪
                    ├ 顔  ◇┬ 目
                    │     ├ 鼻
                    │     └ 口
                    ├ 上着

376 :デフォルトの名無しさん:2007/03/31(土) 15:59:12
    当然のように、処理もこのComposite構造の対応している必要がある。
     人物画のゴム版画の為の
     切除処理 ◇┬ 背景部 ◇─(略)
             └人物部 ◇┬ 頭髪パターン切除
                     ├ 顔  ◇┬ 目をリアリスティックに表現する切除
                     │     ├ 鼻の膨らみを表現する切除
                     │     └ 口の生々しさを表現する切除
                     ├ 毛皮パターン切除

    それでは、切除工程の操作は、作成対象データ(人物画)と同じComposite構造を持ち、
    素材×Compositeの要素数分必要になるのか?

    そんな事はない。
    例えば、頭髪パターン切除と、毛皮パターン切除には同じ切除テクニックが使える。

    これが現実世界の共用だ。


377 :デフォルトの名無しさん:2007/03/31(土) 16:11:43
御託はいらん
読む気も無い

378 :デフォルトの名無しさん:2007/03/31(土) 16:12:41
【そして、現実の世界へ・・・】

それではここで、精神性疾患患者たかひろの設計でデスマ化した
デスマ事例(>>306-307)に戻ろう。
途中から読んでいる方には何の事やらサッパリ判らないだろうから
説明を加えると。

>>293のコードは、精神性疾患患者たかひろが、その劣悪なる知能で設計し
その結果デスマを巻き起こしたコードと極めて類似している。
したがって、>>293の詳細な分析は、デスマ事例コードへの解決策を与えるのである。


379 :デフォルトの名無しさん:2007/03/31(土) 16:39:53
いまごろ解決しても、お前の頭がおかしくなったのはもとには戻らん。
あきらめろ。

380 :ワロス:2007/03/31(土) 16:46:39
「版画の世界」から、「デスマ・システム」への概念マッピング(・∀・)
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
         【版画作成アプリ】       【マスタメンテ型基幹システム】
[主要ドメイン] 版画作成プロセス       マスタ更新プロセス
[主要データ] 下絵、原料版材         入力 (画面入力,電文入力)
         完成した版画版        出力 (DB更新,電文出力,)
                               (付帯的な画面出力)
[主要プロセス]版材取得            入力取得
         下絵作成            入力取得
         版材の品質チェック      入力チェック
         下絵と切除テクのマッチング 業務チェック
         切除処理            DB参照、演算処理、DB更新
         印刷処理            出力処理 (画面出力,電文出力)

381 :デフォルトの名無しさん:2007/03/31(土) 16:49:08
【たかひろと2ちゃんの不思議な関係】

・たかひろがかつて在籍していた会社は全て、たかひろが去った直後に
 2ちゃんでしつこく攻撃される。

・たかひろの元仕事相手、脳内ライバル、
 その他たかひろが自分にとって脅威だと感じる対象は、
 2ちゃんのあちこちのスレに中傷文が書かれる。

・たかひろが出没するスレには                 ← いまココ (・∀・)>>358, >>371, >>379
 常に「キチガイ」「発狂」を連発する荒しが発生する。

・2ちゃんに居る頭も性格も悪い粘着に               
 噛んで含めるように高度な概念を教えてやると、
 いつの間にかたかひろ本人も同じ意見を主張するようになるw

・たかひろは論破されていても、それに気付かないフリをして勝利宣言をする。
・たかひろは論破されると、他のスレで暴れる。
・たかひろは成りすまし/匿名発言をよくするが、それが見破られると
 「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。

さ〜て、まだ荒しを続けるつもりかな?

382 :デフォルトの名無しさん:2007/03/31(土) 16:51:04
またたかひろが暴れてるな
 
 そう。お前自身の信仰は誰も問題にしていない。
 例え神の存在を否定する信仰だろうと、
 ここ日本では誰もメクジラなど立てない。
 
 お前が問題なのは、
 お前がお前自身の信仰を大切にしているのと同様に、
 他人も自身の信念や大切なものを抱えながら生きている
 という事を理解せずに、
 ・他人の信念を批判しまくったり、
 ・自分勝手で不合理な自己主張をおしつけたり、はたまた 

   匿名で 他人の名前を挙げて
   執拗な人格批判/いやがらせを繰り返している

 という事実にある。

 お前と正式に顔を合わせて以来もう数年経つが
 ある日突然ネット上で名前を挙げて非難が開始され俺はとまどった。

 俺は匿名で非難を浴びるような生き方は、これまで一切していない。
 なのに、お前に会ってしばらくしてから突然攻撃が始まった。
 最初はお前の周辺に異常者が居て、俺を攻撃してるのかと思った。
 ・・・でも結局お前がその異常者本人だと気付いた。
 お前しか知りえない情報、お前しか感じ得ない感情で
 キチガイじみた様相で攻撃してくる奴は、お前しかいないって。

 悔い改めよ。そしてお前が迷惑をかけた人、一人一人に許しを乞え。

383 :デフォルトの名無しさん:2007/03/31(土) 17:00:02
荒しはスルーするとして。

>>380
その概念マッピングは、>>375-376 と多少ズレている。
マスタメンテ型システムってのは、
システム開発の都合で業務処理を極端なまでに単純化して、
    業務処理アプリ=DBテーブル編集アプリ
と見なすもんだ。

すると主要ドメインはあくまで業務処理プロセスであって、
マスタ更新プロセスではない。


384 :デフォルトの名無しさん:2007/03/31(土) 17:08:41
>>379
たかひろ、お前が壊れているのは最初から知っている。
お前が壊れた設計をしていたのにも、1週間と待たずに気付いた。
当然の事ながら、問題の解決策もすぐに判った。

ただ、お前がお前自身の精神状態の異常さに気がつかずに、
多くの人々に多大な迷惑をかけ続けた経緯には、
さすがの俺も心が痛んだ。
だから、あえてお前の古傷を持ち出し、
お前の行動を是正しようとしているんだ。

謙虚になれ、たかひろ。
お前はお前が思っているのの1/100も有能ではない。
単なる空っぽの本棚だ。お前の頭は



385 :375:2007/03/31(土) 17:16:39
>>375の分析モデルがズレたので、再投稿
------------------------------------------------------------
   【版材の分析モデル】

     Hanzai <─┬ 原料Hanzai <─┬ 木版<─┬ 柔かい木版
             │            │    └ 硬い木版
             │            ├ ゴム版
             │            ├ 芋版
             │            └ 銅版
             ├ 加工中Hanzai<─┬ 下絵中Hanzai
             │            └ 切除中Hanzai
             └ 完成した版画版
------------------------------------------------------------

386 :375:2007/03/31(土) 17:17:57
あれ?まだずれてる。

>>375の分析モデル図差し替え
------------------------------------------------------------
   【版材の分析モデル】

     Hanzai <─┬ 原料Hanzai <─┬ 木版<─┬ 柔かい木版
             │            │      └ 硬い木版
             │            ├ ゴム版
             │            ├ 芋版
             │            └ 銅版
             ├ 加工中Hanzai<─┬ 下絵中Hanzai
             │            └ 切除中Hanzai
             └ 完成した版画版
------------------------------------------------------------

387 :デフォルトの名無しさん:2007/03/31(土) 17:53:08
>>383

「マスタメンテ型アプリ」設計が導入されたのは、
今回ではなく、何世代も前の電算機導入の頃の話だろう。
それ以来業務処理は「マスタメンテ型アプリ」に合わせて変形し成長した。

だから今さら「マスタメンテ型アプリ」抜きの業務処理プロセスなど
存在しない。

  業務処理プロセス(の一部) ∝ マスタメンテ型アプリのプロセス

としても大きな咀嚼はないだろう。

もし、新システム提案の初期に業務分析の専門家が入り、
提案を新しい業務プロセス設計の形で詳細に残していたら・・・
そこから正確なドメイン・モデルを作成できるのかもしれない。

だが今時の新システム構築なんて、大抵中身はマイグレーション。
COBOLプログラマがプログラムの動きを日本語で説明して「設計書でござい」
なんて言い出すおバカな世界だからなぁ・・・

388 :デフォルトの名無しさん:2007/03/31(土) 17:54:57
>>365
さて、そろそろORマッピングスレを爆撃に行くかw

389 :369:2007/03/31(土) 19:59:13
バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。

A.> >>365が僕の考えからは少し極端な意見だがいいこと言った。

  ORマッピングの話は、>>275の前提条件のスコープ外。

  議論に直接関係ない話を持ち込んで、議論を撹乱するのは
  詐欺師の常套手段なので、みなさん気を付けるように。

  また、もしORマッピングに興味を持った人が居たら、
  まずはデータベース板の該当スレを参照すると良い。

B.> > >>293のコードで省略されているクラス/コードを補足すると、>>304 のようになる。(※1)
  > なりません。

  これは自分で補足コードを書いて見れば簡単に確認できる。
  結果は>>304 のようなコードになるはずだ。
   (但し>>364に説明してあるように、等価コード部 //{〜}// 内は >>364※1と読み替える)

  確認作業はコーディング能力のある人にしか実行できないが、
  それは致し方ない所だろう。



390 :369 (>>389つづき):2007/03/31(土) 19:59:56
バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。

C.> > このコード(>>293, >>304)は、その字面の単純さにもかかわらず、
  > > 挙動を読み取りにくく、保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
  > カプセル化を否定しているように聞こえるが?

  はい、みなさん注目!!!
  これが典型的な詐欺師の手口です。騙されないように。

  元レス>>369>>293-294のカプセル化破綻問題を指摘している。
  自分の問題点を指摘された >>293は、逆上して事実と反対の事を言い出している。

1.システムの全体像が見えていない以上、
  処理の動作主体をモデル化しておく必要がある。
  ここで動作主体とは、「鈴木君」や「田中君」である。

2.動作主体が「鈴木君」や「田中君」であり、
  プロセスは >>293の最初のクラス=WoodCutPrintProcessクラスである。


391 :369 (>>389つづき):2007/03/31(土) 20:05:01
バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。

1.> このケースの主処理は木版が作成プロセスである。

  このケースでは、システムの全体像が見えていない以上、
  処理の動作主体をモデル化しておく必要がある。

  ここで動作主体とは、「鈴木君」や「田中君」である。

2.> 鈴木君や田中君は木版画作成プロセスのバリエーションである。

  前述のように、動作主体が「鈴木君」や「田中君」であり、
  プロセスは >>293の最初のクラス=WoodCutPrintContextクラスである。

  (なおこのクラスの名称 "WoodCutPrintContext"は、内容を適切に表していない。
   正しくは、"WoodCutPrintProcess"と命名するべきである。根拠は>>297 参照)



392 :デフォルトの名無しさん:2007/03/31(土) 20:06:02
たかひろがバカなのは判ったから
とにかく sageを覚えろ

393 :デフォルトの名無しさん:2007/03/31(土) 20:18:05
あらあら、よく見たらアイツ
またまた敗走宣言してるやん >>379

ワロス

394 :デフォルトの名無しさん:2007/03/31(土) 20:19:51
>>380
GJ!

「版画作成プロセス」と「マスタメンテ・プロセス」は所詮は別物、
もともと厳密に1対1に対応するものではない。

そこで>>380の齟齬の悪そうな部分を若干修正してみた。
大きな変更点は「版画作成プロセス」でなく「版画版作成プロセス」とした点。

----------------------------------------------------------------------
「版画の世界」から、「デスマ・システム」への概念マッピング part2
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
         【版画版作成アプリ】      【マスタメンテ型基幹システム】
[主要ドメイン]  版画版作成プロセス       マスタメンテ・プロセス
[主要データ]   版材原料            入力 (画面入力データ)
         下絵              DB参照データ
         加工中の版画版  
         完成状態の版画版        出力 (DB更新データ)
         刷り上がった版画        表示 (画面表示データ)
[主要プロセス]  版材原料取得          入力取得
         版材作成            入力チェック
         下絵取得&下絵処理       業務チェック, DB参照
         切除処理            演算処理, DB更新
         印刷処理            画面表示
----------------------------------------------------------------------
修正結果を見ると、両者の対応関係はそんなには悪くない。
むしろ、別物にしてはずいぶん良い対応関係を持っている、と言える。

395 :394 AAズレ修正:2007/03/31(土) 20:35:49
----------------------------------------------------------------------
「版画の世界」から、「デスマ・システム」への概念マッピング ver.2
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
         【版画版作成アプリ】       【マスタメンテ型基幹システム】
[主要ドメイン] 版画版作成プロセス       マスタメンテ・プロセス
[主要データ]  版材原料             入力 (画面入力データ)
         下絵                DB参照データ
         加工中の版画版  
         完成状態の版画版       出力 (DB更新データ)
         刷り上がった版画        表示 (画面表示データ)
[主要プロセス]版材原料取得          入力取得
         版材作成             入力チェック
         下絵取得&下絵処理      業務チェック, DB参照
         切除処理             演算処理, DB更新
         印刷処理             画面表示
----------------------------------------------------------------------

396 :デフォルトの名無しさん:2007/04/01(日) 02:18:44
ある意味すごいなw
未だにコードが出てこないし解釈間違ってるけど、このエネルギーはスゴイ。
便所の100wと比喩してはいけないw

397 :396:2007/04/01(日) 05:00:48
スマソ 誤爆した

398 :デフォルトの名無しさん:2007/04/01(日) 07:01:05
まあまあ
元々の質問はもうとっくにクローズしてるし、
>>293はjavaとよく似た擬似コードで記述されたクラス設計に過ぎんから、
代替コードを示す必要もない。

現在議論されているのは、>>293の背景にある設計理念の問題、
そして、それに類する設計を現実に適用した時のギャップね解決方法だろ。

理解できないなら結論が出るまで静観するがよろし

399 :デフォルトの名無しさん:2007/04/01(日) 08:41:27
このスレ、爆発力はあるな
問題は火のつけ方

400 :デフォルトの名無しさん:2007/04/01(日) 09:44:28
>>397
ナニコレww
勝手に誤爆にするなよwww
>>397-398
おまいウザイから別にスレ立て手やれよ

401 :デフォルトの名無しさん:2007/04/01(日) 09:52:28
あとそんなに自分の主張に自信があるなら
コテつけてレスしろ

402 :デフォルトの名無しさん:2007/04/01(日) 10:38:41
>>400-401 またスレ荒しか

403 :デフォルトの名無しさん:2007/04/01(日) 10:40:13
おまぃはバカなんだから黙っとけ

404 :デフォルトの名無しさん:2007/04/01(日) 16:38:31
いやさ、例の「精神性疾患の俗称連呼」の人、
別スレで暴れまくっててえらい騒ぎになってるわ。

どうも東京都在住の44歳の人物らしい。
44歳にもなって2ちゃん三昧とは幼いね。

405 :デフォルトの名無しさん:2007/04/01(日) 16:50:51
リアルワールドが悲惨なんだよ、きっと

406 :デフォルトの名無しさん:2007/04/01(日) 17:02:21
よしよし

407 :デフォルトの名無しさん:2007/04/01(日) 18:05:17
NGワード推奨:キチガイ

408 :デフォルトの名無しさん:2007/04/01(日) 19:09:37
某スレで、コーディング能力も設計能力も疑わしい44歳の人が
「擬似コードを元にした議論はよくねぇ〜」とか叫んでて笑えた。
「print文入れて動作を見ればいい」ってそれなんて名前のBASIC言語?w

409 :デフォルトの名無しさん:2007/04/01(日) 20:54:04
なんと言う春休み。
思わず読み飛ばしてしまった。
このスレはしばらく伸びる。

410 :デフォルトの名無しさん:2007/04/01(日) 21:05:50
>>409
荒しに来たのなら、帰ってくれ。

411 :デフォルトの名無しさん:2007/04/04(水) 02:42:25
こっちが平和になったと思ったら
今度はあっちで暴れてたんだな
http://pc11.2ch.net/test/read.cgi/tech/1172431242/

412 :デフォルトの名無しさん:2007/04/04(水) 14:16:56
>>407
自分がそれだから、そうやって相手を封じたい訳ね。
ま、相手なんてお前の脳内にしか居ないんだけど(藁

413 :デフォルトの名無しさん:2007/04/04(水) 14:25:05
誤爆?


414 :デフォルトの名無しさん:2007/04/05(木) 14:50:04
>>412
おまえが自己の行動に無自覚な精神障害者である事はよくわかった。

415 :デフォルトの名無しさん:2007/04/06(金) 14:56:12
ここのスレ主はそろそろ鉄格子付き個室病棟の中か。

頭も性格も悪いスレ主に意見すると
ひたすら泥沼に引きずり込もうとあがくから
始末が悪い。

416 :デフォルトの名無しさん:2007/04/06(金) 15:56:32
スレ主は、OOやデザパタに対して、狂信的な宗教感情を持っている。

その信仰はあまりにも愚かで盲目的であり、
自身の独自解釈とは異なる意見を持つ者に対して
狂信的信者の狂ったな正義感を持って攻撃と排除を試みる。
しかし、世の中に広く受け入れられる技術ノウハウというものは、
そのようなカルト的宗教活動とは一切無縁のものである。

417 :デフォルトの名無しさん:2007/04/06(金) 16:08:13
個人的な技術ノウハウの蓄積は、
 ・日々の実践と経験を通じた、メンタルモデルの形成
 ・合理的思考による、メンタルモデルの検討と洗練
 ・明確な目的意識に基づく、合目的なノウハウの抽出と洗練
を通じて行われる。

そして世の中に広く受け入れられる技術ノウハウというものは、
個々人のノウハウを、他の専門家を交えた健全な議論に晒し、
目的と手段の合理性を詳細に検討し、
その過程で多くの人々が同意し共感する事を通じて、
初めて成立するものである。

418 :デフォルトの名無しさん:2007/04/06(金) 16:28:04
注: 誤解のないように注記しておく。

ここでスレ主とは、今回のスレを立てた人物の事ではなく
関連スレのど真ん中に居座り、罵詈雑言を撒き散らしては議論妨害を繰り返す、
牢名主のような人物の事である。

419 :デフォルトの名無しさん:2007/04/06(金) 19:28:31
GoFってなんて呼べばいいの?
個人的にはゴフって読んでるんだけど、公の場で使ったら笑われたりする?

420 :デフォルトの名無しさん:2007/04/06(金) 19:37:48
>>419
情報処理用語の読み方を確認するスレ
http://pc8.2ch.net/test/read.cgi/tech/1056173956/670

 670 :デフォルトの名無しさん :2005/05/16(月) 20:02:16
  GOFはともかくGoFはゴフと読んでる。

421 :デフォルトの名無しさん:2007/04/06(金) 20:33:32
ゴフゴフ

422 :デフォルトの名無しさん:2007/04/06(金) 22:39:06
護符としての効能はあるんだろうか?

423 :デフォルトの名無しさん:2007/04/07(土) 01:00:50
      __
    i<´   }\   , - 、
   ヽ.._\./  .ンく r-兮、 __
    ∠`ヽ.! /   ヾニEヲぐ ,ゝ->     さすがGoFだ。
   /_`シ'K-───‐-、l∠ イ       デスマくらっても
   l´__,/l\、_ ̄0¨0)゙@Yヘ, -┤      何ともないぜ。
.    l'___|⌒ヾ''ー==、ーr='イ i二|      
   / .」   i   /./7r‐く  lー!
.   f.  ヽ‐i人.∠'<   _i. l,.-ゝ.
    トiヘヘ「ト〈      `X  トレi7__|
   〉ト:トハj`! i.    /  トー┤lルj,リ
  /‐+----+‐l    iー--i---ヾ'〃
.  l_i____i__|   |___i,__i_|

424 :デフォルトの名無しさん:2007/04/07(土) 01:57:18
荒らしは帰ってくれ

425 :デフォルトの名無しさん:2007/04/07(土) 20:59:35
あっちの隔離スレ、すげぇ荒れようだな。

こっちであんまヘタレな擬似コード出してくるから
ちょっとからかってやったらすぐキレ出して、
改めて問題点を7レス分ほど指摘しただけで
延々と一週間もこの騒ぎだ。

狂信者って本当に怖いね。

426 :デフォルトの名無しさん:2007/04/08(日) 00:52:40
イタイ・・・・

427 :デフォルトの名無しさん:2007/04/08(日) 00:56:10
http://pc11.2ch.net/test/read.cgi/tech/1175959706/

428 :デフォルトの名無しさん:2007/04/21(土) 09:39:44
State パターンで相談です。各 State クラス間でコンテキストを共有したい
場合に、相互の依存度を下げるにはどういったイディオムが使えますか?

例えば、ウィザード形式のインストーラの画面を State と見なすと、
A 画面で設定した内容を次の B 画面でも使いたいとか、最終的には、
全ての画面で設定した内容をもとに処理を行いたい、など。

Context を各 State のコンストラクタに渡してあげれば目的は達成できる
のですが、各 State が興味があるのは Context の限られた一部分であり、
Context 全体を渡すのは不釣り合いな気がしています。

もう一つの悩みは、Context が受動的な「共有データクラス」の役割を
演じることになるというものです。どうもこの構造がしっくりこない
というか、オブジェクト指向っぽくないと思うのです。

あるいは、こういう場合にはそもそも State パターンは使わないとか、
そういった指摘でもかまいませんので、よろしくお願いします。

429 :デフォルトの名無しさん:2007/04/21(土) 09:47:55
その前にStateパターンのクラスズをよく見て依存関係を
シッカリ把握しなさい

430 :428:2007/04/21(土) 10:02:23
>>429
問題にしているのは以下のような依存関係です。
Controller has a State
Controller has a Context
StateA is a State
StateB is a State

431 :デフォルトの名無しさん:2007/04/21(土) 10:13:33
>>430
私が問題にしているのは
>各 State が興味があるのは Context の限られた一部分であり
です。
StateはContextに興味はありません。

432 :デフォルトの名無しさん:2007/04/21(土) 10:26:13
ハッタリ業務コンサルのデザインパターン解釈はダメダメだな

433 :デフォルトの名無しさん:2007/04/21(土) 10:42:32
まー独自解釈して苦しんでしまう事は初心者にはよくあることだから気にする必要は無いw

434 :428:2007/04/21(土) 10:44:02
>>431
Context という言葉を使ったのがまずかったですね。ごめんなさい。
GoF では Context が State に処理を移譲することになっていたかと
思いますが、ここでは「共有データ」の意味で Context を使ってます。

つまり、Controller が State に処理を移譲していて、各 State は
Context を参照・更新するという構造です。

State が Controller に無関心だと言う点についてはもちろん同意です。
今回の悩みどころは、各 State の「成果物」を共有する時のうまい手段は
ないものか、というものです。

GoF に従うなら、
Context has a State
Context has a SharedData
StateA is a State
StateB is a State
で、StateA や StateB が SharedData を参照更新する、という感じです。

435 :デフォルトの名無しさん:2007/04/21(土) 10:48:50
ContextがMediatorになるんじゃないの?


436 :デフォルトの名無しさん:2007/04/21(土) 10:52:17
WebApplicationやStrutsと同じジャマイカ

437 :デフォルトの名無しさん:2007/04/21(土) 11:07:11
扱うデータの型や処理の型を問題にせずSharedDataでひとくくりにするから
概要設計レベルではContextで解決したつもりになっていても
詳細設計レベルで一気に破綻するんだろ。

ハッタリコンサル(初心者)の典型だな

438 :デフォルトの名無しさん:2007/04/21(土) 11:12:12
>>435
Mediatorで相互依存性を弱めるというのは正しい方向だが
それをContextと呼び続けるのは病気だ。
今ならDIだろ。

439 :デフォルトの名無しさん:2007/04/21(土) 11:15:19
いまどき概要設計/詳細設計かよ

440 :デフォルトの名無しさん:2007/04/21(土) 11:17:17
ハッタリコンサルはメーカ毎の工程名の相違に鈍感
OMGの工程名対応表でも見とけクズ

441 :デフォルトの名無しさん:2007/04/21(土) 11:22:56
いまどき工程かよw

442 :デフォルトの名無しさん:2007/04/21(土) 11:27:07
ハッタリが話題ずらしに必死だな
上空レベル、海面レベルとでも読み替えておけクズ

443 :デフォルトの名無しさん:2007/04/21(土) 11:28:25
>>435
> ContextがMediatorになるんじゃないの?

ContextではなくMediatorだろうな、
古臭いデザパタ厨房の妄想に合わせてやれば

444 :デフォルトの名無しさん:2007/04/21(土) 11:29:48
>>442
そりゃユースケースの話だろwバーカw

445 :デフォルトの名無しさん:2007/04/21(土) 11:31:11
ハッタリ必死すぎるぞ

カプサイシン摂取過多でそろそろ拳銃乱射事件かw

446 :デフォルトの名無しさん:2007/04/21(土) 11:33:12
ハッタリコンサルの仕事:
奴隷コーダに一画面分のコードを書かせ、
それが複数画面で使いまわせると信じ込んで
詳細設計の雛形にする

447 :デフォルトの名無しさん:2007/04/21(土) 11:35:53
ハッタリコンサルの仕事2:概要設計
一画面分のコードで、データ類がContextにまとめられているのを見て、
Contextというクラスを作れば複数画面にも対応できるとはずだ
という妄想設計をすること。

448 :デフォルトの名無しさん:2007/04/21(土) 11:37:09
>>446
お、宗旨替えか?
そうだよSE/コンサルはコーダ以下なんだよwやっと気づいたか

449 :デフォルトの名無しさん:2007/04/21(土) 11:44:03
>>448

はぁ?
お前がダメ人間だからといって、
他もダメ扱いすんな。

中小企業のダメコンサルに比べたら
大企業のSEには中にはまともなのが居るよ。

例えば俺。
コーディングもできるし(あたりまえ)、
科学技術にも口出しできるし、
ダメコンサルを叩いて再起不能にする事もできる。
お前を今叩いているようにな

450 :デフォルトの名無しさん:2007/04/21(土) 11:45:54
ここで叩かれてボロボロになってるハッタリコンサルって、誰なの?

451 :デフォルトの名無しさん:2007/04/21(土) 11:50:20
>コーディングもできるし(あたりまえ)
コンプまるだしw

452 :デフォルトの名無しさん:2007/04/21(土) 11:53:19
>例えば俺。
日中カキコしまくりのヒキコモリが大企業のSE?w

453 :デフォルトの名無しさん:2007/04/21(土) 11:54:03
>>450
各種情報を総合すると、こいつが本人らしい。
http://megalodon.jp/?url=http://pc11.2ch.net/test/read.cgi/tech/1172431242/626&date=20070410182152

454 :デフォルトの名無しさん:2007/04/21(土) 11:56:16
>>453
みっともねぇ〜ないい歳こいた親父が
2ちゃんごときで必死になっちゃってw
仕事場でオナニー三昧2ちゃん三昧って
それなんていう引き篭もり部屋?

455 :428:2007/04/21(土) 12:00:16
うーん。Mediator だとクラスの数が増えてしまうので、ちょっとおおげさ
かなという気がします。コストとメリットがバランスしないというか。

問題をうまく処理できることはもちろん大切なんですが、「やり過ぎ」も
避けたいなと。

データ共有型 State パターンは割とありがちなことかと思ったのですが、
検索してもあんまりピンとくるものがないんですよね。まあ、探し方が
悪い気もしますが、どちらかと言うと状態遷移の問題に着目したものが
多かった気がします。

C++ だし参照渡しでお茶を濁そうかなと思ったり。

456 :デフォルトの名無しさん:2007/04/21(土) 12:06:18
>>454
おめえは気の利いたこといってるつもりなんだと思うけど、
とにかくセンスが無さすぎる

457 :デフォルトの名無しさん:2007/04/21(土) 12:06:31
妄想に基づく独自解釈をGoogleで探しても、適切な例が出てくるわけない。
StateパターンにおけるContextクラスの役割は約一ヶ月前に書いた通り。

お前の負けだ。観念しろ

458 :デフォルトの名無しさん:2007/04/21(土) 12:08:07
>>456
キチガイのセンスに合わせるのは難しいな
四流大学出はそういう会話が得意なんだろうけど。

459 :デフォルトの名無しさん:2007/04/21(土) 13:21:07
>>446
手足として使った奴隷コーダに強烈な恨みを買っているのが
ハッタリコンサルのダメダメな所。

「勝手に引き抜いて、変な仕事ばかり回してきて
 あのバカは一体何様のつもりだ?」
って泣いてたぜ、奴隷コーダちゃん


460 :デフォルトの名無しさん:2007/04/21(土) 13:24:16
>>459
そうそうw
そういえばあのコーダも使えなかったよなw
Javaのクラスはオブジェクトじゃない!とかわけのわからないこといってたしw

461 :デフォルトの名無しさん:2007/04/21(土) 13:25:40
>>460
そういえばあいつ、頭おかしくなって会社やめちゃったってなw
ヒキって2chばっかやってるらしい。
版画とかよばれてるしw

462 :デフォルトの名無しさん:2007/04/21(土) 13:33:03
>>461
ああ、あのゴミか
ほんと死ねばいいのにな

463 :デフォルトの名無しさん:2007/04/21(土) 13:34:23
>>462
同意w
おれがあいつならとっくに吊ってるw

464 :デフォルトの名無しさん:2007/04/21(土) 13:34:37
>>460
バカが発振し始めたな
デブのことだよハッタリ高弘ちゃん

465 :デフォルトの名無しさん:2007/04/21(土) 13:36:25
>>464
版画ハケーン(版画風ry

うわきもw

466 :デフォルトの名無しさん:2007/04/21(土) 13:36:31
早速スレに晒しときましたw

467 :デフォルトの名無しさん:2007/04/21(土) 13:39:24
おいおまいら、アドレナリンは俺専用のオモチャだ
勝手にアドレナリンをいじるな
暇つぶしに適当な書き込みをするとすぐ怒り出すのでとても面白い


468 :デフォルトの名無しさん:2007/04/21(土) 13:42:11
>>467
強がりいってらwあったまわりいw

469 :デフォルトの名無しさん:2007/04/21(土) 13:42:51
>>467
カプサイシンの間違いじゃねぇの
半島人臭いし

470 :デフォルトの名無しさん:2007/04/21(土) 13:43:53
ムッキー、ファビョーン(笑

471 :デフォルトの名無しさん:2007/04/21(土) 13:45:29
おいハッタリをあんま構うな
あまり追い詰めると
出身校(四流大)で拳銃乱射事件起こすぞきっと

472 :デフォルトの名無しさん:2007/04/21(土) 13:46:34
>>469
そうそうw
版画もちょっと煽るとすぐファビョるしなw
半島に帰れよw

473 :デフォルトの名無しさん:2007/04/21(土) 13:47:38
ハッタリ高弘の好物
キムチ餃子

474 :デフォルトの名無しさん:2007/04/21(土) 13:48:59
さぁーってと
昼休みのハッタリいじめはそろそろ飽きたし
四月の休日を満喫してくるか(←満喫に行くって意味じゃないよw

475 :デフォルトの名無しさん:2007/04/21(土) 13:52:03
版画版画ってバカにすんな!!
Javaのクラスなんかオブジェクトのわけないだろ!

たしかにハッタリたかひろも俺も鮮人だが、それがどうした!
低脳どもが!

476 :デフォルトの名無しさん:2007/04/21(土) 13:53:51
ハッタリの成りすましはクオリティが低くて萎える

477 :デフォルトの名無しさん:2007/04/21(土) 13:54:42
GoF本って独習C++を一通りやった程度の知識で理解できますか?

478 :デフォルトの名無しさん:2007/04/21(土) 13:54:51
メモ:ハッタリは半島人

479 :デフォルトの名無しさん:2007/04/21(土) 13:56:31
>>478
半島人には関わらない方がよい。

480 :デフォルトの名無しさん:2007/04/21(土) 21:03:15
>>477
基本的に経験則のまとめ本だから、必要な状況にならないと理解しにくいのが多い。
まあ理解出来る出来ないに関わらず一冊持っとくのは良いと思うよ。

481 :デフォルトの名無しさん:2007/04/21(土) 21:15:36
こういうのには盛り上がるんだなw

482 :デフォルトの名無しさん:2007/04/21(土) 21:18:22
ほら、宗教の人だから自作自演で信者獲得したフリしないと気が済まないんだろ

483 :デフォルトの名無しさん:2007/04/27(金) 11:52:06
GoF本を今時会社の机にこれ見よがしに置いてあるの見ると笑える

484 :デフォルトの名無しさん:2007/04/27(金) 14:49:27
キチガイって飽きないの?

485 :デフォルトの名無しさん:2007/04/29(日) 00:50:15
>>484
自問自答は黙って答出せ

486 :デフォルトの名無しさん:2007/05/18(金) 15:28:15
ここのObserverパターンはわかりやすかった。
ttp://goodjob.boy.jp/chirashinoura/id/135.html

487 :デフォルトの名無しさん:2007/06/18(月) 21:21:41
アーキテクチャパターンの質問で悪いんだけど、
MVCパターンにおいて、
「押されたボタンに応じて新しいサブWindowをオープンする作業」のような、
Window遷移を管理する人(実現する人)って誰になるの?

Model? View?

Window遷移もアプリケーションの中核処理になるから、
Modelの責務の範囲内なのかなとも思うんだけど、、実際どうなの?

488 :デフォルトの名無しさん:2007/06/26(火) 23:59:02
どーでもねーよ

489 :デフォルトの名無しさん:2007/07/09(月) 11:31:18
>>487
画面の制御なんてモロにViewだと思うんだけど。

490 :デフォルトの名無しさん:2007/07/09(月) 22:41:24
UIモデルだな

491 :3年前:2007/07/11(水) 11:24:49
Domain-Driven Design
http://pc11.2ch.net/test/read.cgi/prog/1080149913/

1 名前: 仕様書無しさん 投稿日: 04/03/25 02:38
 ドメイン駆動型デザインとは何か?

 Download draft of book from
 http://www.domaindrivendesign.org/book/DDD_2003-04-15.pdf
 http://www.domaindrivendesign.org/


492 :そして現在:2007/07/11(水) 11:26:36
Domain-Driven Designのエッセンス

「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。
しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関す
る解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無か
ったと言ってもいいでしょう。 Eric Evansの『Domain-Driven Design』(以降DDD)は、「ソフト
ウェアの真の複雑さに挑戦する」という副題からも分かるように、ドメインモデリングに正面
から取り組んだ待望の書籍です。

DDDは、海外では非常に評判の高い書籍です。本書の出版前からMartin Fowler氏により
「期待できる内容だ」と推薦されていたり、GoFの1人であるRalph Johnson氏は自身のブロ
グで本書を「4、5回は読み直した」と賛辞を送っています。Spring Frameworkの開発者Rod
Johnson氏も、最近のプレゼンテーションでDDDを紹介しながら、「Java EE開発者がこれ
から進むべき道はリッチなドメインモデルだ」と発表しています。また、MDAツールSculptor
のように、DDDを積極的に採用したツールやフレームワークも登場しつつあります。

しかし、日本では翻訳書がいまだに出版されていないこともあり、本書の出版から3年近く
経った今でも、まだまだ一部の通の人たちにしか広まっていないように筆者には思われます。
また、原書を読まれた方の中からも「本が分厚すぎて読みきれない・・・」という嘆きの声も
聞かれます(DDD難民という言葉もあるそうです)。
そこで本連載では、全3回に分けて、DDDの全貌を簡潔に紹介してみたいと思います。

DDDはタイトルからは一見分かりにくいのですが、いわゆるパターン本の1つです。
しかし、DDDは全体が読み物の体裁で編まれているため、パターンカタログが読み物から
独立しているもの(『デザインパターン』『J2EEパターン』『エンタープライズアプリケーション
アーキテクチャパターン』など)に比べ、パターンの閲覧性は良くありません。本連載では、
すでに一度読破された方にも有用な資料となるように、パターンカタログとしてDDDを再構成
してみます。


493 :デフォルトの名無しさん:2007/07/11(水) 19:11:44
へー

494 :デフォルトの名無しさん:2007/10/08(月) 17:41:42
ここって何も知らん人でも書いていいんだろうか・・・

一つのパターンを適用、っつーか使うっていうのなら何とかできるんだけど、複数のパターンを組み合わせるとなるといきなり手が止まる・・・
デザインパターンはいいコードを書いていれば自然に適用されている物、っていうことなの・・・?

495 :デフォルトの名無しさん:2007/10/08(月) 18:57:21
一つ使うも複数使うも難易度に差はないだろ
理解しないでサンプルコード改変してるレベルと見える

496 :デフォルトの名無しさん:2007/10/10(水) 23:46:07
デザインパターンって、「組み合わせて」使うような例ってほとんどないんじゃないかな。

一つのモジュールの別々の箇所で複数のデザインパターンを併用することはよくあるけどねー。
Java のクラスライブラリがいい例。

497 :デフォルトの名無しさん:2007/10/31(水) 00:50:37
難しいことはいいからデザパタって
ホントに役に立つのかどうか教えろよ

498 :デフォルトの名無しさん:2007/10/31(水) 00:51:49
>>497
OOPを一から自分で設計するのは骨が折れるぞ
バグも紛れ込むし

499 :デフォルトの名無しさん:2007/10/31(水) 00:55:39
お前に使いこなせねえよバーカ

500 :デフォルトの名無しさん:2007/10/31(水) 00:55:43
>>497
仕事なら役に立つよ
一単語だけで意図が伝わる

501 :デフォルトの名無しさん:2007/10/31(水) 00:58:01
>>499
うるせーハナクソ

502 :デフォルトの名無しさん:2007/10/31(水) 01:16:18
>>497
自分のそれまでの経験とセンスだけで、
後々のメンテとかになるべく困らないような
設計するのは難しいから、頭のいい先人たちが
編み出した有用なパターンを知っておいた方が楽。
ていうか知らないとかなり大変。

503 :デフォルトの名無しさん:2007/10/31(水) 01:23:01
>>498

かなりできる人間が過半数超えてれば使えるし、
超えて無いとロスの方がでかい。

504 :デフォルトの名無しさん:2007/11/08(木) 11:28:46
C++でのcrtpとか言語毎に形成されたイディオム的なパターンは実用性も高いし、初心者にも分かりやすいと思う
結局言語の所まで落とさないと使えないしね
というかC++だとそういうidiom使わないとたちどころに言語になるし

GoFで紹介されてる各パターンは役に立たないけど
そこで使われる考え方っていうのは言語ローカルなイディオムを理解するのに役立つかなぁと思ったけど、
もう少し勉強が進んだらまた違う感想になる気がする

505 :デフォルトの名無しさん:2007/11/14(水) 02:08:15
デザインパターンを使わずにスマートに書く方法とかって
どんな感じなんになるんでしょうね?

たとえば、うどんをそばを作る場合なんかはほとんど
工程は一緒なのでテンプレートメソッドに使うんだろうけど

みなさんならどうやって書きますか?
ふと考えるといろいろあるけどどれもいまいちな気が。

1どんぶり用意
2うどんかそばを入れる
3だしをそそぐ

506 :デフォルトの名無しさん:2007/11/14(水) 03:04:16
GoFが役に立たないとか、デザインパターンを使わずにスマートに書くとか・・・学生さんかね?

507 :デフォルトの名無しさん:2007/11/14(水) 08:14:51
>>506
なんだか継承になれすぎて使わないパターンがあまりおもいつかなかったもので使わなかったらどうだろうかと思ったんですけど。

508 :デフォルトの名無しさん:2007/11/14(水) 12:22:47
>>505
昔は仕様書を元に上から下へ逐次式に書いたものだよ。
仕様書がすべて、はじめに機能をすべて洗い出せることこそ能力。

これに慣れたままSEになり30代を迎えると、もう補正が効かない。

あと、現場でやっている人は、GOFどうこうを意識している人はあまりいないとおもう。

509 :デフォルトの名無しさん:2007/11/15(木) 02:57:13
>>508
>これに慣れたままSEになり30代を迎えると、もう補正が効かない。

そういう人を一般的に才能がないという。
勉強する意欲がない人はいくら若くてもダメ。
転職するならお早めに。


510 :デフォルトの名無しさん:2007/11/15(木) 03:47:08
>>508
ちょっと前にやったプロジェクトで、GOFに死ぬほど拘ってる
プロジェクトリーダーが居て困ったことがあるな。

最近、GOFを勉強したらしく、なんか頭がすごく良くなったカン違い
してるみたいで、設計がGOFのどれかのパターンになってないと、
全部NGにされて、直すのに苦労したよ・・・

511 :デフォルトの名無しさん:2007/11/15(木) 03:50:05
>>508
GoFすら意識してなくて機能をイメージできるものか?出来てるつもりじゃないか?

512 :デフォルトの名無しさん:2007/11/15(木) 09:22:08
設計なんて茨の道さ。
もんどりうってじたばたして、
痛い思いしながらGoFにしがみついたり、
手放したり、またGoF読み直したり、
もんどりうったり、じたばたしたり、
GoF読み直してピンときてみたり、
こなかったり、もんどりうって、ピンときたり。

513 :デフォルトの名無しさん:2007/11/15(木) 13:56:27
全ての設計要素は何らかの秩序の上に存在すべき
だが設計要素や立脚する秩序をすべて表現する必要はないってこった
達人の書いたオプソのコード読んでも、凄さが伝わりくい理由がそこにある気がする

514 :デフォルトの名無しさん:2007/11/15(木) 14:39:57
>>512
オッパイ揉んでピンときたり
が抜けてね?

515 :デフォルトの名無しさん:2007/12/28(金) 16:51:17
ソースコードの見た目がかっこ良くなるので使ってます

516 :デフォルトの名無しさん:2008/01/07(月) 21:48:54
開発環境のバージョンによって、含まれるライブラリが違うため、
どちらのバージョンでも動くように、実装を切り替えるということがしたいのです。
XMLのラッパーライブラリのエンジンの実装を切り替える、というようなことです。

Strategyパターンを使うのがよいのでしょうか?
最初は、Decoratorパターンと区別がつかなかったのですが、
GOF本のDecoratorのところにあるように、

・中身を取り換えるのが、Strategyで、
・外側を取り換えるのが、Decorator
ということで、

中のエンジンを取り換えるのは、Strategyパターンということでしょうか?

517 :デフォルトの名無しさん:2008/01/07(月) 22:43:21
>516
あんまりパターンの名前にとらわれずにしたほうがいいと思われ。

518 :デフォルトの名無しさん:2008/01/08(火) 00:19:40
うむ。
とりあえず作りたいように作って、似たパターンがあったらそれに合わせていく方向で。

519 :デフォルトの名無しさん:2008/01/09(水) 03:33:32
>>517-518
ありがとう
過去レスででてたけど、作ってみてリファクタリングの時に考える方法やってみる

520 :デフォルトの名無しさん:2008/02/06(水) 20:05:11
// Hoge.h
#ifndef HOGE_H
#define HOGE_H
class Hoge {
public:
static Hoge* New();
virtual void Foo() = 0;
virtual ~Hoge() { }
};
#endif

// Hoge.cpp
#include "Hoge.h"
#include <iostream>
class Hoge_ : public Hoge {
public:
virtual void Foo() { std::cout << "Hoge::Foo" << std::endl; }
};
Hoge* Hoge::New() {
return new Hoge_();
}

// main.cpp
#include "Hoge.h"
#include <boost/scoped_ptr.hpp>
int main() {
boost::scoped_ptr<Hoge> hoge(Hoge::New());
hoge->Foo();
}

こうやって実装を pimpl より隠蔽してるソースを見たんだけど、
このデザパタの名前って何?

521 :デフォルトの名無しさん:2008/02/06(水) 23:46:55
これっしょ?よく見る普通のインターフェイスじゃないか。
http://boost.cppll.jp/HEAD/libs/smart_ptr/sp_techniques.html#abstract

522 :デフォルトの名無しさん:2008/02/07(木) 00:21:09
「〜パターン」 とかの名前がついてるわけではないのね。

523 :デフォルトの名無しさん:2008/02/07(木) 03:10:32
strategyじゃね

524 :デフォルトの名無しさん:2008/02/07(木) 07:40:40
派生クラスを1つしか作らないこと前提で目的も違うから
strategy じゃないな。

525 :デフォルトの名無しさん:2008/02/14(木) 22:04:23
質問させてください
Compositeパターンで作られたクラスに
インターフェースの拡張を施した新しいクラスを作りたいときは
Bridgeパターンを使いますか?

526 :デフォルトの名無しさん:2008/02/15(金) 20:35:57
自己解決しました

527 :デフォルトの名無しさん:2008/02/16(土) 03:47:22
自己解決したらできれば、解決法を書いていきましょう
後で見た人の参考になりますよ

528 :デフォルトの名無しさん:2008/02/27(水) 09:21:02
フラグを1ビットではなくカウンターで持っておき、ON扱いを1より大きい
値(仮にA)とします。ONしたい状況ではいきなりAを代入するのではなく
1ずつ足していき、OFFしたい状況ではすぐにゼロを代入します。

こういう、ONにするときだけショックアブソーバー付きな動作をする
フラグはデザパタではどういう名前が付けられてますか?

529 :デフォルトの名無しさん:2008/02/27(水) 13:24:07
自家発電しました

530 :デフォルトの名無しさん:2008/02/27(水) 19:14:49
>>525-526
自己解決パターン

531 :デフォルトの名無しさん:2008/02/28(木) 01:50:40
アンチパターンだな

532 :デフォルトの名無しさん:2008/03/02(日) 18:10:25
最近デザインパターンを勉強しだしたんですが
GoFの23個のうち2〜3個組み合わせて何か簡単なものを作るとしたら
どんなものが思い浮かびますか?

533 :デフォルトの名無しさん:2008/03/02(日) 18:27:07
STL

534 :デフォルトの名無しさん:2008/03/02(日) 18:29:26
Template Method との組み合わせは結構考えられるかと。

535 :デフォルトの名無しさん:2008/03/02(日) 22:56:35
コマンドパターンとなんかで、
GUIツールのアンドゥの練習

536 :デフォルトの名無しさん:2008/03/02(日) 22:56:57
やっぱり、アンドゥ、リドゥの練習にしといて

537 :デフォルトの名無しさん:2008/03/02(日) 23:13:23
Memento パターンと Command パターンの複合か。

538 :デフォルトの名無しさん:2008/03/03(月) 01:22:59
わかりました
やってみます

539 :デフォルトの名無しさん:2008/03/04(火) 18:26:09
c++です
DecoratorパターンでConcrete ComponentとDecoratorを区別して
Concrete Componentの型を知る方法はdynamic_castを使うしかないですか?

540 :デフォルトの名無しさん:2008/03/04(火) 18:53:21
>>539
型を知って何をするかによって方法が変わる気が。
RTTI(dynamic_castもその1つ)を使うか、Concrete Componentのメンバに型を示すIDのようなものを用意しておくか。
そもそもスレ違い。

541 :デフォルトの名無しさん:2008/05/09(金) 11:50:43
鈴木高弘スレw

542 :デフォルトの名無しさん:2008/05/11(日) 05:10:51
ゲーム作ろうと思い、デザインパターンの勉強をしてるんですが
Singletonをどんな風に使うのか今一ピントきません。

Singletonじゃないと困る場合。
Singletonだと助かる場合。
出来たら例を示して貰えないでしょうか。

543 :デフォルトの名無しさん:2008/05/11(日) 07:57:27
>>542
ぜひ、こちらへどうぞ

ゲームにおけるデータ構造・クラス設計・パターン
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

544 :デフォルトの名無しさん:2008/05/11(日) 16:39:33
あちらで聞いてみます

545 :デフォルトの名無しさん:2008/05/11(日) 17:47:41
やる夫がデザインパターンをやるようです
http://mojalog.com/2008/02/post_160.html


546 :デフォルトの名無しさん:2008/05/11(日) 18:06:29
>>545
やる夫wwwwめちゃめちゃ笑った

547 :デフォルトの名無しさん:2008/05/11(日) 18:15:14
>>545
デザインパターンの考え方が分かりやすくて助かりました。

548 :デフォルトの名無しさん:2008/05/11(日) 19:23:44
AA入ってるのって、一見とっつきやすそうだが…、
読みにくくもあったり…しかし微笑ましいのだけは確か。

549 :デフォルトの名無しさん:2008/05/11(日) 21:11:22
例自体は具体的で読みやすいんじゃないか?
デザパタ本て(全部とは言わないが)ほとんどが
説明のための説明みたいな本になってるし。

550 :デフォルトの名無しさん:2008/05/12(月) 02:47:40
シンプルファクトリーって始めて知った
ファクトリメソッドとアブストラクトファクトリしか知らなかった
デザインパターン的には常識なの?



551 :デフォルトの名無しさん:2008/05/12(月) 02:56:07
この手のものは先に名付けたもん勝ちだから
あまり仔細にこだわろうとするな。

> ファクトリメソッドとアブストラクトファクトリしか知らなかった
知ったかどうかよりも理解できたかどうかが大事なんだが。

552 :デフォルトの名無しさん:2008/05/12(月) 16:39:49
http://marupeke296.com/DP_main.html

個人的にここのデザインパターンの解説がゲームプログラミングを例にしているせいか
わかりやすいんだが、スレ住人的にはどう?


553 :デフォルトの名無しさん:2008/05/12(月) 16:59:44
>>552
わかりやすいし、筆者の理解度は高いと思う。
自分の言葉で言いなおしてるところで、
的が外れていないので高感度アップ。

Abstract Factory 一塊のオブジェクト群を沢山の種類用意する

は、恥ずかしながら今までみたどの解説よりスッとくる一文だった。

554 :デフォルトの名無しさん:2008/05/12(月) 22:57:03
例というなら、GoFの元ネタはウィジェットや言語の実装で現われたパターンだから、
自分でウィジェットや言語を書けば何を言ってるのかすぐわかる

555 :デフォルトの名無しさん:2008/05/12(月) 23:10:08
うじぇー奴

556 :デフォルトの名無しさん:2008/05/13(火) 00:53:16
>>552
FlyWeightってこのページで書かれているような感じなの?

557 :デフォルトの名無しさん:2008/05/13(火) 09:31:42
zsh line editorのwidgetでも使えますか!?

558 :デフォルトの名無しさん:2008/06/14(土) 11:28:21
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門
http://www.amazon.co.jp/dp/4894716828

この本とかどうだろうね?まだ自分は読み始めだけど。

559 :デフォルトの名無しさん:2008/06/14(土) 19:02:26
だったら読み終わったときに評価書いてくれ

560 :デフォルトの名無しさん:2008/06/18(水) 18:46:30
MVCモデルについて質問です。

javaであればModelでは描画するメソッドを一切実装せず、描画メソッドについてはすべてViewで実装するという事ですか?
例えば、Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思いますが、
そういう時もViewまで先送りにした方がいいですか?

561 :デフォルトの名無しさん:2008/06/19(木) 00:31:36
描画はモデルじゃね?

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

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

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

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

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

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

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

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

次の会社でも探すか。

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

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

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

普通じゃん。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

宗教だけど。

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

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

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

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

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

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

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


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

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

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

592 :デフォルトの名無しさん: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, 佐藤 直生, 木下 哲也, 福龍興業: 本
http://www.amazon.co.jp/dp/4873112494
http://images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg

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

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

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

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

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

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

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

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

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

>>598
ある

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

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

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

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

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

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

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

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


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

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



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

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

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

612 :デフォルトの名無しさん:2008/11/11(火) 15:28:48
あげ

613 :デフォルトの名無しさん:2008/11/12(水) 23:42:17
まだあったか

614 :デフォルトの名無しさん:2008/12/16(火) 13:36:00
あげ

615 :デフォルトの名無しさん:2008/12/23(火) 01:08:25
Amazonから
「ケント・ベックの『実装パターン』、
Amazon.co.jpでお求めいただけます」
メールキタ━(゚∀゚)━!!

N瀬監修T社翻訳........orz



616 :デフォルトの名無しさん:2009/01/11(日) 02:29:21
シングルトンってインスタンスが初めて呼ばれるまで本当にそのインスタンス生成されていないの?

617 :デフォルトの名無しさん:2009/01/11(日) 03:20:49
初回に new しているタイプは言うまでもなく、
getInstance内でstatic変数として確保しているタイプでもそうなる。
クラスのstaticメンバ変数として作っちゃうと、mainより前に作られる。

618 :デフォルトの名無しさん:2009/01/11(日) 07:42:09
そもそも
シングルトンってインスタンス誕生の瞬間までカバーしてたっけ?

619 :デフォルトの名無しさん:2009/01/11(日) 12:47:51
>>617
それはプログラミング言語によって異なるだろう。

620 :デフォルトの名無しさん:2009/01/11(日) 13:19:12
>>618
シングルトンは初めて使う時に生成するもんじゃないのか?

621 :デフォルトの名無しさん:2009/01/11(日) 13:22:04
明日は成人の日か

622 :デフォルトの名無しさん:2009/01/11(日) 14:29:57
シングルトンて北朝鮮放送の読み方のように言えるよね

623 :デフォルトの名無しさん:2009/01/11(日) 14:43:18
싱 글똔 さんか。

624 :  :2009/01/18(日) 21:54:19
デザインパターンじゃないんだけど実装パターンに書かれてる
Pluggable Selector てのがいまいちわかりません。例に出てくるJUnitもよく知らないし。
誰か教えてください。

625 :デフォルトの名無しさん:2009/01/18(日) 22:02:29
シングルトンは任意の実行コンテキスト内でインスタンスの個数を制限するだけで、
いつインスタンス化するかはお好きに。
リファレンスカウントがなければ解放してもいいし。

626 :デフォルトの名無しさん:2009/01/19(月) 09:13:22
>>624
どこに書かれていて、何が分からないのか分からない。

627 :デフォルトの名無しさん:2009/01/19(月) 19:08:29
626が全否定

628 :デフォルトの名無しさん:2009/01/22(木) 02:08:22
すいません。アドバイスください。

車CarContextの走行状態をStateパターンで
CarRunState, CarHighwayRunState, CarIdleStateと設定して、
Stateの派生クラス内で状態遷移の判定を行っているとします

ここで予想外に水陸両用車ShipCarContextが増えて
CarSwimStateの状態を増やそうとした場合に、
今まで派生クラス内で行っていた状態遷移の判定を
CarContext、ShipCarContext内で行うべきでしょうか?

CarContextが状態遷移の判定ルーチンで膨れあがるのが嫌で、
State派生クラスで状態遷移の判定を行っていました
諦めてShipCarContext用の状態判定Stateクラスを一から作り直すか、
CarContext内で状態遷移の判定を行うか悩んでいます
定石があれば教えていただきたいのですが

629 :デフォルトの名無しさん:2009/01/22(木) 20:56:59
>>628
おそらく定石からは外れるだろうけど、StateManagerみたいな管理クラスを間に挟んで、そこで状態遷移を一元管理させてる。

GOFのStateパターンに従った場合、OOぽいアプローチにできるが、遷移の流れを把握しにくくなるような気がする。

また状態遷移も、今の状態、次の状態、遷移時のアクションが分かれば済むようなもの、まれにガード条件、分岐条件が加わるような場合しか使ってこなかったので、これらの情報を設定ファイルに吐き出して、実行時に状態遷移マネージャに読み込ませてる。

おかげで状態遷移はそれほど膨れ上がらないが、アクションは1〜数クラスにまとめてしまうので、膨れ上がるね。

630 :デフォルトの名無しさん:2009/01/22(木) 21:05:31
FactoryMethodパターンとかAbstractFactoryパターンって解放のことまで考えられてないけど、
解放ってどうするの?


631 :デフォルトの名無しさん:2009/01/22(木) 21:30:19
>>630
所有権を持っているオブジェクトが破棄してあげればいいんじゃね。
通常だと、Factoryにより生成されたオブジェクトを保持してるオブジェクト

おそらく問題としていることは、複数のオブジェクトでFactoryにより生成されたオブジェクトを保持してる場合を気にしているものと思われる。

所有状態が複雑になるため、このような状態は極力避けるべきだと思うが、どうしても複数で保持する必要があるのなら、参照をコピーした際に所有権も移動させるか、または参照カウンタを実装し、最後まで保持してるオブジェクトに解放を行わせるかのどちらかかと。


632 :デフォルトの名無しさん:2009/01/22(木) 22:59:32
GoF以外のデザインパターンってありますよね?
ここのサイトでけっこうまとめられてるようですが。
ttp://www.tom.sfc.keio.ac.jp/~fjedi/wiki/index.php?%A4%BD%A4%CE%C2%BE%A4%CE%A5%C7%A5%B6%A5%A4%A5%F3%A5%D1%A5%BF%A1%BC%A5%F3

そういうのっていろんな人が好き勝手に作ってるものなんですか?
一つの本にまとめられていたりとかはしないんですかね


633 :628:2009/01/23(金) 02:45:12
>>629
ありがとうございます。参考になりました。必ずしもGOFってわけでもないですよね

>GOFのStateパターンに従った場合、OOぽいアプローチにできるが、遷移の流れを把握しにくくなるような気がする。
たしかに把握しにくいです。
とりあえず今回は、それぞれのStateに分散した処理をそのまま使い回したいので、
(泥沼な気もしますが)CarRunStateを例にとると
   void CarRunState::update(Context * context);
で読み込んだContextからCarContextにダウンキャスト可能なら、CarContextの遷移判定を行い、
ShipCarContextにダウンキャスト可能なら、ShipCarContextの遷移判定を行うように処理を分けようと思います

CarContextとShipCarContextで判定処理が混在するので、CarRunStateの処理があまりに膨れるようなら、
ダウンキャストではなく、CarRunStateから、CarRunStateForCarとCarRunStateForShipCar
に分けるという方針で行こうと思います

それやるくらいなら・・等、ご意見を頂ければとてもありがたいです

634 :デフォルトの名無しさん:2009/01/24(土) 20:58:05
デザインパターンなんてもんが存在してるってことは、オブジェクト指向はまだまだってことでは?と言ってみるテスト

635 :デフォルトの名無しさん:2009/01/24(土) 20:59:29
単なる護符だよ

636 :デフォルトの名無しさん:2009/01/24(土) 21:38:53
>>634
逆だよ デザインパターンが48個になったら完成

637 :デフォルトの名無しさん:2009/01/24(土) 22:10:55
>>636
kwsk

638 :デフォルトの名無しさん:2009/01/24(土) 22:17:29
48手だろ

639 :デフォルトの名無しさん:2009/01/25(日) 00:17:36
48のデザインパターンと52の関節技ですねわかります

640 :デフォルトの名無しさん:2009/01/25(日) 04:38:04
四苦八苦、4x9+8x9=108
で人間の煩悩の数だけでデザインパターンがあるのではないか

641 :デフォルトの名無しさん:2009/01/25(日) 06:35:53
>>632
結城さんのマルチスレッド編とか。
http://www.amazon.co.jp/dp/4797331623

642 :デフォルトの名無しさん:2009/02/09(月) 18:03:46
確認なんだけどハッシュはイテレータ作れないよね?

643 :デフォルトの名無しさん:2009/02/09(月) 19:15:02
要素に順番にアクセスできるのがイテレータだと思うんだけど、
ハッシュの場合のイテレータの『順番』ってのはどういうのを考えてるの?



644 :デフォルトの名無しさん:2009/02/09(月) 22:10:20
ハッシュド・ビーフが食いたくなった

645 :デフォルトの名無しさん:2009/02/10(火) 00:00:27
>>642
Map<K,V> m を iterate したいってことか?

for (Map.Entry<K,V> e : m.entrySet()) { K k = e.getKey(); V v = e.getValue(); }
for (K k : m.keySet()) { V v = m.getValue(k); }

用途に応じて好きな方を使え。
そういう意味の質問でないならお前の日本語が悪いから知らん

646 :デフォルトの名無しさん:2009/02/10(火) 01:18:54
なんだその暗号は

647 :デフォルトの名無しさん:2009/02/10(火) 01:44:32
アルファがベータをカッパらったらイプシロンした。なぜだろう

648 :デフォルトの名無しさん:2009/02/10(火) 10:02:27
range based for loop

649 :デフォルトの名無しさん:2009/02/11(水) 00:47:28
Uncopyableパターンってどういうときに使ってますか?


650 :デフォルトの名無しさん:2009/02/11(水) 01:03:38
あ、GetInstanceで参照を返すようなSingletonオブジェクトの場合は
受け取り側の変数に参照ではなく実体の変数を使われないようにするために使えますね


651 :デフォルトの名無しさん:2009/02/11(水) 01:39:42
>>649
面倒くさくてポインタそのまま扱ってるクラスが大量に扱われるときに
コピーコンストラクタを作らずに入れておくとか。

652 :デフォルトの名無しさん:2009/02/11(水) 05:39:11
>>650 わからん
文を書き直して

653 :デフォルトの名無しさん:2009/02/11(水) 07:14:15
class CSomethingManager
{
public :
CSomethingManager &GetInstance(){
static CSomethingManager instance;
return instance;
}

private :
CSomethingManager(){}
~CSomethingManager(){}
};

//CSomethingManager &instance = CSomethingManager::GetInstance();
CSomethingManager instance = CSomethingManager::GetInstance();
instance.DoSomething();

654 :デフォルトの名無しさん:2009/02/11(水) 07:17:09
ユーザーがついうっかり(もしくは何も考えずに)、&を書き忘れてしまうようなことが起こらないようにするために


655 :デフォルトの名無しさん:2009/02/11(水) 07:18:02
あ、つーかSingletonでコピーコンストラクタを禁止するから関係ないのかw


656 :デフォルトの名無しさん:2009/02/11(水) 07:25:47
>あ、つーかSingletonでコピーコンストラクタを禁止するから関係ないのかw

スマソ。日本語おかしすぎた
つまりUncopyableパターンでSingletonオブジェクトのコピーを出来なくする使い方があると思ったんだけど、
そもそもSingleton自体に(コピーコンストラクタをprivateで定義することで)そういう考え方が備わってるから
意味ないと気付いた


657 :デフォルトの名無しさん:2009/02/20(金) 00:33:02
10個位のクラスに、同じような処理を行う長〜い1個のメソッド(1000STEP超)があるのですが、
これを今度共通化するなりしてまとめようという話になり、うまくデザインパターンが利用できないかなと考えています。
(デザインパターンに当てはめる必要はないのですが・・・)

クラスA
処理1
処理2
処理3

クラスB
処理1
処理3

クラスC
処理2
処理3

とまぁ、同じような処理を行っているので、
共通クラス
処理1
処理2
処理3
と記述して、呼び出し元のクラスで通る処理を切り替えられないかなと思っているのですが、
こんな用件に対応するデザインパターンてございます?
AbstractFactoryやFactoryMethod、Templeteなどが使えないかなと思うのですが、
結局それぞれのクラスから共通している処理を抜き出しても元々のクラスと同じ数だけクラスが増えることになりそうな気がして、
それだと単に処理抜き出してクラス作っただけで終わりそうなので・・・。
デザインパターンの理解が出来てないのかとも思うので、何かやりようがあったらどなたかご教授ください。


658 :デフォルトの名無しさん:2009/02/20(金) 07:16:10
A、B、Cの処理ABCが全て同じならクラスは一個でいいだろ
クラス
処理A()
処理B()
処理C()

クラス a = new クラス()
クラス b = new クラス()
クラス c = new クラス()

微妙に違うならインタフェースを作って継承するだけじゃ?
クラスA:インタフェース
クラスB:インタフェース
クラスC:インタフェース

private test(Iインタフェース t)
{
t.処理A();
t.処理B();
t.処理C();

}

659 :デフォルトの名無しさん:2009/02/20(金) 10:01:15
template method

660 :デフォルトの名無しさん:2009/02/20(金) 19:55:47
>>657
オレもTemplateMethodに一票

後みんな、原本の翻訳はしないの?

661 :デフォルトの名無しさん:2009/02/20(金) 21:17:50
デザパタのパターン名なんてよく覚えられるな。
覚えてるやつって丸覚えしてんの?
ちゃんと意味わかって使ってる?

662 :デフォルトの名無しさん:2009/02/20(金) 21:25:00
design patterns by functional programming paradigm
とかないのかな?

663 :デフォルトの名無しさん:2009/02/20(金) 21:26:24
GoF 23パターンまでぐらいなら。
意味の方は、人と話すときはその都度ググってるw

664 :デフォルトの名無しさん:2009/02/20(金) 21:32:47
本当によく使うのは5個くらいだから名前も覚えてる。
その他は名前聞いてもああ聞いたことあるなくらいで
後からクラス図見れば十分間に合う。
暗記力のテストじゃないんだし。

665 :デフォルトの名無しさん:2009/02/20(金) 21:37:58
perlの演算子覚えるのに比べれば楽勝楽勝

666 :デフォルトの名無しさん:2009/02/20(金) 22:23:28
デザパタの生まれた経緯を考えると名前で呼び合うのが自然なんだろうな。
でもなんかしっくりこない。

667 :デフォルトの名無しさん:2009/02/21(土) 11:55:02
>>657
別の視点から。

処理1〜3が同じ引数を持つのであれば、各処理をそれぞれ一つのクラスのメソッドとした上で、
Decoratorで積み上げる、という考え方もあると思う。
Javaや.NET系のStreamをイメージしてもらうと分かりやすいかも。

668 :デフォルトの名無しさん:2009/02/25(水) 11:34:59
Decoratorで処理123を組み合わせで積み上げる場合
クラスABCを生成するためにSimpleFactoryでも用意してあげた方がいいのかな?

669 :デフォルトの名無しさん:2009/02/25(水) 16:51:48
http://codepad.org/KUsbGdYn
・基底クラスにfactoryを持たせてみた
・decoratorパターンってhookだなぁと思った
・大量のdecoratorを使うときは定義にマクロを使ったらいいかも
・posthookとprehookの形にできるようにすればもっと柔軟に扱えるかもしれない

670 :デフォルトの名無しさん:2009/02/25(水) 17:06:38
>>657
なんかすっごい、デザパタ以前の問題の気がw
OOPに嗜まずしてデザパタ適応は無理。

671 :デフォルトの名無しさん:2009/02/25(水) 20:37:44
卑下することは無いと思うけど、別のパラダイムだよな
宣言型のプログラミングじゃなくて、動的な奴

で、こう言うのってなんて言うんだ?

672 :669:2009/02/25(水) 20:53:45
ガーンこういうのdecoratorって言わないのかー
ちょっとゴフ見直してくるわ

673 :デフォルトの名無しさん:2009/02/25(水) 21:02:07
>>670
たぶんOOP以前の問題だろうな
答えてる方もあやしいな、Decoratorなんて目的が違いすぎる

674 :デフォルトの名無しさん:2009/02/25(水) 22:05:33
何でもかんでもデザパタ使えばいいと思ってる奴らが多そう。

675 :デフォルトの名無しさん:2009/02/25(水) 22:18:18
なんでもかんでもhookを使って実装しているemacsに対してひとこと

676 :デフォルトの名無しさん:2009/02/25(水) 23:16:05
>>674
オマエがそう思うならそうなんだろ オマエの頭の中では

現実は逆だ。コード設計の意図を次使う人に少しでも伝える為に
藁にもすがる思いでデザパタを入れておく

677 :デフォルトの名無しさん:2009/02/26(木) 02:15:13
>>674
同感だな
無理やり導入された名ばかりのパターンは害悪でしかない
>>657に対するDecoratorがいい例だし、Templete Methodも使うべきじゃないだろう

678 :デフォルトの名無しさん:2009/02/26(木) 02:27:43
静的に結合されるcommand patternのようなものを作ればいいんだな
よしやってみる

679 :デフォルトの名無しさん:2009/02/26(木) 03:03:58
いや>>669が最初からDecoratorでない

もういいよw
こういう流れ知ってるからw

わざと煽らなくていいし、いいたいことはいったし

680 :669:2009/02/26(木) 07:28:39
>>679
とりあえずどこがdecoratorじゃないか教えてよ

681 :デフォルトの名無しさん:2009/02/26(木) 09:52:32
>>657
FactoryMethodパターンは生成に関するパターンでつよw
AbstractFactoryパターンはオブジェクト郡の生成に関するパターンでつよw

AbstractFactoryパターンを勘違いしちゃってる人が多いでつ。

682 :デフォルトの名無しさん:2009/02/26(木) 10:25:05
657は、DecoratorかTemplete Methodでググって要求に合う物を使えば良いだろう


>>669はDecoratorになって無いと言うのがよく解らん
C++のobj->method()->method()の記述が何か別な意味でも持つのか?
OOP的な意味で

683 :デフォルトの名無しさん:2009/02/26(木) 18:45:17
>>680
>>679は↓だからスルーするがよし
http://blog.livedoor.jp/goldennews/archives/51222968.html

684 :デフォルトの名無しさん:2009/02/26(木) 20:16:39
>>681
>>657はたぶん処理1〜3の中にそれぞれクラスA〜Cに対応した処理の分岐があると
言っているんだろう。
だからクラスA1〜C3を作って、A1〜A3を生成するAファクトリ……のような感じで
AbstractFactoryパターンを適用し、その際の共通の部分に対しFactoryMethodや
TempleteMethodを適用しようと考えたんだろう。考え方自体はそれほど間違ってない。

685 :デフォルトの名無しさん:2009/02/27(金) 10:43:13
Factory Method パターンはインスタンス生成の抽象化を目的としているのに対して、
Abstract Factory パターンの目的はあくまでも関連するインスタンス群の生成 API の集約化である。
異なる目的を達成するための手段がたまたま似たような形となったに過ぎない。

686 :デフォルトの名無しさん:2009/02/28(土) 11:57:36
俺の好きなデザパタ。ベスト3+α。

1) Mediatorパターン
 相互作用をこいつに任せると爽快。
 相互作用の記述のみに特化したクラス、
 という明白な目的を持てるのも嬉しい。

2) FactoryMethodパターン
 今でもポツポツこれ使う。
 インスタンス化をサブクラスに任せる。自由なような不自由なような。
 このパターンが好きなのは某JavaMLなどで○木さんが暴れていたのを見るのが好きだったから。

3) Observerパターン
 通知する側される側、で分けちゃうのが何よりスカッとする。

3.1) Stateパターン
 これを知ったとき、「ああ、これがOOPか…」と感動した覚えが。

687 :デフォルトの名無しさん:2009/02/28(土) 12:16:18
>>686
俺も同意だな
初心者には魔法っぽく見えるのはこんなもんでしょ

ところで、SINGLETONは旨いのかな?
スコッチの話なんだが...

688 :デフォルトの名無しさん:2009/02/28(土) 20:37:06
この4つは魔法っぽく見えて他は見えないのか、その差が分からないな
Observerは割と人気がありそうだけど、他は結構変わった感性な気がする

689 :デフォルトの名無しさん:2009/03/01(日) 10:48:42
デザパタは初心者にとって魔法に見えるというより、
ムダなものに見えてると思う。実体験ではそう感じた。

1) ムダに仕組みを複雑にして、ワケのわからんクラスが増えてしまう
2) デザパタだのなんだの言うけど、こんなの前から似たようなのやってる。
 Cでも出来る(とか言ったり)、テンプレートでもできる(とか言ったり)、
 OOPLじゃなくてもできる(とても気軽に言う)、
 これって○○パターンの派生(気軽に定義をぼやかす)と言えるんじゃね(と言ったり)。

そう思うんなら、せめて無理矢理使うのだけはやめてほすぃ(´;ω;`)

690 :デフォルトの名無しさん:2009/03/01(日) 14:50:45
>>689
そりゃそうだろう。
極論すれば、よく見かけるのに名前を付けただけ。

691 :デフォルトの名無しさん:2009/03/01(日) 15:01:11
デザパタってクラス図とかも状況に応じて変化するんでしょ?
あんまり意識しすぎても意味ない気がするんだけど…



692 :デフォルトの名無しさん:2009/03/01(日) 16:37:27
それがどうした

693 :デフォルトの名無しさん:2009/03/03(火) 10:06:50
ぼく

694 :デフォルトの名無しさん:2009/03/03(火) 10:28:19
> デザパタだのなんだの言うけど、こんなの前から似たようなのやってる。

デザパタの本を渡した新人が9割9分返してくる言葉www

695 :デフォルトの名無しさん:2009/03/03(火) 10:49:24
結局のところ、デザパタは難しいんよ。
だから、知ったか大発生になるんよ。

デザパタの価値を知るのは、
「設計の困難>デザパタ学習の困難」
な場合だけだよ。

デザパタ適応で何が柔軟になるのか、
パターンをカタログ化して嬉しいのか、
そこがピンと来ないんよ。
設計で苦しんでないと、ピンと来ないんよ。

696 :デフォルトの名無しさん:2009/03/03(火) 11:42:11
デザパタ覚えたての新人が増えたようだな
悪い方に育ってないが、デザパタはそんな仰々しいもんじゃねーよw

697 :デフォルトの名無しさん:2009/03/04(水) 04:08:05
デザインとかいってるけどその名にふさわしいのって一部だけだろ
シングルトンなんてただのコーディングテクニックっていうレベルのものじゃん

698 :デフォルトの名無しさん:2009/03/04(水) 05:24:29
ところで、SINGLETONは旨いのかな?
スコッチの話なんだが...

699 :デフォルトの名無しさん:2009/03/05(木) 02:04:50
そのネタ定期的にみるな。

700 :デフォルトの名無しさん:2009/03/05(木) 09:49:09
>>697
>>690
> 極論すれば、よく見かけるのに名前を付けただけ。

701 :デフォルトの名無しさん:2009/03/05(木) 14:02:47
多分だが、>>697 は「デザイン」の意味をよく解ってない。

702 :デフォルトの名無しさん:2009/03/06(金) 03:22:16
どうでもいいわ

703 :デフォルトの名無しさん:2009/03/13(金) 03:37:19
Visitorはダブルディスパッチの模写だ、とかっていうんだけど、
ダブルディスパッチって要は2つのクラス階層で処理を分岐させることではないの?
Bridgeもそうだと思って検索してみたんだけど、なんかそうでもなさげ
なんか勘違いしてる?

704 :デフォルトの名無しさん:2009/03/13(金) 16:11:54
ダブルディスパッチはvisitされるオブジェクトがVisitorを兼ねる場合のパターンと
見なすこともできる。
どちらの方が都合が良いかは場合によるので一方が他方の模倣というわけではないな。

705 :デフォルトの名無しさん:2009/03/13(金) 23:44:51
憧れのアーキテクトに会いに行こうぜ
待ってる。
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx


706 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/03/14(土) 17:11:13
>705
MSはなぜ顔写真を載せようと思ったのか

708 :デフォルトの名無しさん:2009/03/14(土) 17:51:35
BridgeはむしろStrategyのContextクラスがインタフェース階層化された場合と
見ることが出来る。これはモジュールを疎結合にするための構造化の手法だが、
マルチプルディスパッチやVisitorは単純に複数の引数型を動的に解決する方法であり、
つまり条件分岐の上等なやつでしかない。

709 :デフォルトの名無しさん:2009/03/14(土) 17:56:16
Bridgeパターンよくわからんね。

710 :デフォルトの名無しさん:2009/03/14(土) 19:12:22
>>706
パターンの目的が知りたいのか構造が知りたいのか分からないからレスもしにくいんだが、

Visitorパターンの目的はダブルディスパッチで、ダブルディスパッチは関数のオーバーロードを実行時の型によって行う動作のこと
ポリモーフィズムを使ってどうやって実現するかを考えればだいたいの人はGoFの構造を考え付くと思う

Bridgeパターンの目的はクラスのある部分を分離してしまうこと
分離元クラスと分離されたクラスがそれぞれ1つずつならpimplみたいな形になるけど、それぞれがクラスツリーを形成する場合を考えればだいたいの人は(ry

711 :デフォルトの名無しさん:2009/03/14(土) 19:22:22
名前をつけることでイメージを固定化するというか共有するというか
大抵のパターンは解かってる人なら大抵思いつくことなんだと思う

解からん人や入門者にもイメージを伝えやすいし

712 :あぼーん:あぼーん
あぼーん

713 :デフォルトの名無しさん:2009/04/29(水) 20:48:01
http://namidame.2ch.net/test/read.cgi/mitemite/1239723288/530-534

714 :デフォルトの名無しさん:2009/05/12(火) 12:59:13
>3.1) Stateパターン
> これを知ったとき、「ああ、これがOOPか…」と感動した覚えが。
私は逆に、オブジェクトの振る舞いの実装がオブジェクトではなく
状態にあるってのが違和感あってだめだった
同じ「腹痛」状態でも、胃薬飲む人、我慢する人、病院行く人と
色々あるからオブジェクトそのものも状態の一つじゃないかと

715 :デフォルトの名無しさん:2009/05/12(火) 13:00:29
ああアンカー忘れ
>>686

716 :デフォルトの名無しさん:2009/05/12(火) 13:38:14
いや多分stateパターンの実装方法が「OOPっぽい」って思ったんじゃなかろうか

717 :デフォルトの名無しさん:2009/05/12(火) 15:50:39
BridgeってCで言うところの関数ポインタ渡しだよね?


718 :デフォルトの名無しさん:2009/05/12(火) 18:47:25
Stateで状態が組み合わせだった場合どうなるんだろ

719 :デフォルトの名無しさん:2009/05/12(火) 19:21:13
設計ミス

720 :デフォルトの名無しさん:2009/05/16(土) 16:10:06
>>717
関数ポインタ渡しはStrategyだろ

>>718
Boost.Statechart

>>710
何度見てもVisitorはキモいと思う
関数型言語のパターンマッチとかC++のtraitとかで何とかならんのか

721 :デフォルトの名無しさん:2009/05/16(土) 16:19:23
>Statechart
NFA->DFAの変換をしろということか

722 :デフォルトの名無しさん:2009/05/22(金) 13:47:08
C++のtraitsの方が何やってるのかさっぱり解らない
どうもテンプレートは苦手だ

723 :デフォルトの名無しさん:2009/05/22(金) 17:25:35
>>722
traitsはtemplate引数の型をコンパイラに自動判別させるための仕組み
イテレータは知っての通り5つの種類がある

これをいちいち型指定しなくてもコンパイラが判別してくれるようにする

724 :デフォルトの名無しさん:2009/05/22(金) 22:47:06
char_traitsのほうかもしれないぞ

725 :デフォルトの名無しさん:2009/05/26(火) 23:05:22
弾幕STG作るのに最適なデザインパターンって何でしょうか?
1.弾の描画処理と当たり判定を決めるクラスと
2.弾の動きを定義するクラス
を作ってコンストラクタで1.のクラスのポインタを渡すように
してみましたが使いづらいです・・。

726 :デフォルトの名無しさん:2009/05/27(水) 00:24:15
マイクロスレッド?
いや知らないけど

727 :デフォルトの名無しさん:2009/05/27(水) 03:58:38
STG作ったことないけど
弾、敵機、自機、当たり判定、描画処理
で分けちゃえば?
当たり判定と描画処理はmediatorで

728 :725:2009/05/28(木) 22:50:07
>>726
ググったら弾幕風講座がヒットしました。これ使うと複雑な弾幕も作りやすくなるとのことですが・・
C++で出来るんでしょうか?

729 :デフォルトの名無しさん:2009/05/29(金) 01:18:50
Windowsならfiberで
http://msdn.microsoft.com/en-us/library/aa915091.aspx
その他の環境はsetjmp・longjmpで実装

「マイクロスレッドを使えば」複雑な弾幕が作りやすくなるってのは
まぁ無いと思うがね

730 :デフォルトの名無しさん:2009/05/29(金) 05:04:05
コルーチンがあると意外とたのしい
そんな徹夜明けの今日

731 :デフォルトの名無しさん:2009/05/29(金) 06:29:37
コルーチンからはModula-2しか思いつかない私。

732 :725:2009/05/30(土) 23:45:55
>>729
OSによって変わったりするんですか?面倒そうですね・・
>「マイクロスレッドを使えば」複雑な弾幕が作りやすくなるってのは
>まぁ無いと思うがね
じゃあ使うのやめときます・・。

それよりMediatorパターンがどう役立つのかわかりません・・
「C++で読むデザインパターン」を読んでみましたが、MemberPtnが当たり判定用クラスで、
MessagePutで自機の座標を送るんでしょうか?
http://www.01-tec.com/document/cpp_design_pattern.html#Mediator


733 :デフォルトの名無しさん:2009/06/03(水) 18:54:04
>>732
弾、敵機、自機、当たり判定、描画処理とかクラスがあった時に
お互い直接やり取りはせずに必ずMediatorを通してやるのが
Mediatorパターン

734 :デフォルトの名無しさん:2009/06/04(木) 02:38:42
弾や機体といったActorが高機能でなければ、それぞれ単なる構造体にでもして
統一的なモジュール、つまりMediatorが管理するようにする。
Mediatorは内部処理が汚くなりやすいのが欠点だが
逆に泥臭い処理がどうしても必要な時にそれを閉じ込めるために使える。

735 :725:2009/06/04(木) 23:41:38
どういう風に便利なのか、よくイメージがわきませんがとりあえず組んでみます
組んでみればわかるかな

736 :デフォルトの名無しさん:2009/06/05(金) 02:07:12
シューティングなんて作るのは簡単なんだから、とにかくいろいろな組み方を試して
自分にあったやり方を見つけりゃいい
マイクロスレッドも一応試しとき

737 :デフォルトの名無しさん:2009/06/05(金) 18:54:54
それぞれのパターンに書いてあるクラス図は
必ずその通りにしなきゃならんのかね
心意気だけ同じじゃダメ?

visitorとかあのままだと使いにくくてたまらんのだが

738 :デフォルトの名無しさん:2009/06/06(土) 02:59:09
好きにいじくっておk。
しかしvisitorはあんまいじりようがないと思うんだが。

739 :デフォルトの名無しさん:2009/06/06(土) 09:09:03
いや
クラスをデータ部分と処理部分に分離したいのはパターン通りなんだけど
分けた後のクラスの両方、もしくは片一方が
抽象/具象に分けるまでも無いときとか

740 :デフォルトの名無しさん:2009/06/22(月) 23:17:31
絶対遵守のルールじゃないんだから、アレンジすればよろし。
あくまでも「よくあるパターン」を一般化したものなんだから。

741 :デフォルトの名無しさん:2009/06/23(火) 09:22:08
もっといいのはアレンジの前に、
ほんとにパターンが適合できるか、
使うべきかどうかを考え直すこと。

742 :デフォルトの名無しさん:2009/06/23(火) 20:52:03
デザインパターンって普通パターンの基底クラスを作って派生クラスから使うものなんですか?

743 :デフォルトの名無しさん:2009/06/23(火) 20:52:59
必要だからあるのです

744 :デフォルトの名無しさん:2009/07/03(金) 10:49:10
ただの用語セットだと思った方がいいんでね?

745 :デフォルトの名無しさん:2009/07/03(金) 19:16:05
検索機能でオプションの項目が沢山ある場合に使えるデザインパターンを教えてください

746 :デフォルトの名無しさん:2009/07/03(金) 19:19:32
>>745
オブション項目間の依存関係があるなら、
Mediatorパターン。

コレにチェック入ってる時だけこれとこれを有効、
ソレにチェック入っている時だけさらにこれらを画面に出す、とかそういう。

逆に言えば項目間の依存関係がなければ必要なし。

747 :デフォルトの名無しさん:2009/07/03(金) 19:59:20
助言ありがとうございます
理解を深めて挑戦したいと思います

748 :デフォルトの名無しさん:2009/07/10(金) 23:09:57
ぬこかわえ

749 :デフォルトの名無しさん:2009/07/10(金) 23:11:13
誤爆しました><

750 :デフォルトの名無しさん:2009/07/11(土) 19:15:48
>>741
「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法」
この本にはある程度つくってからパターンにあてはめりゃいいみたいなことが
書いてあるが。

751 :デフォルトの名無しさん:2009/07/11(土) 19:25:50
絵に描いた餅のウマさを説いたところでってゆう

752 :デフォルトの名無しさん:2009/07/13(月) 10:36:20
保守

753 :デフォルトの名無しさん:2009/08/14(金) 16:43:08
デザインパターンを意識しないで最適解を考えて作って見たら
デザインパターンだったって事も多い
ありふれてるからパターンなんだな

754 :デフォルトの名無しさん:2009/08/14(金) 17:18:57
>>753
まあ、そういうものでしょ。
すでにあったものを整理することで分かりやすくする
というのが要点なんだから。

755 :デフォルトの名無しさん:2009/08/14(金) 22:07:01
デザパタはよくあるパターンに名前をつけたことがすごい

756 :デフォルトの名無しさん:2009/08/15(土) 17:51:49
変な萌えネームつけられなくてよかったな
意思疎通するときに恥ずかしいし

757 :デフォルトの名無しさん:2009/08/17(月) 00:51:05
無味乾燥で疑念の挟みようのない命名なのは助かる。

758 :デフォルトの名無しさん:2009/08/17(月) 03:12:48
でもGoFじゃないデザパタには不思議なの混ざってたとおもう

759 :デフォルトの名無しさん:2009/08/17(月) 09:26:16
「Java実例プログラムによるデザインパターン入門講座」のSimple Factoryパターンとか?
パターンの名前でシンプルという単語を使っちゃうセンスとか。

しかもあの本、Factoryなのに、getXXXとしてて、元の、
Factory - create の美しい関係を軽視しちゃってる。

760 :デフォルトの名無しさん:2009/08/17(月) 09:42:02
はてな界隈で俺流パターンに
アニメや漫画から引用して名付けてんのはたまに見るな

761 :デフォルトの名無しさん:2009/08/19(水) 21:16:00
デザインパターンって非OOP言語にも適用可能なの?(C言語とか)

762 :デフォルトの名無しさん:2009/08/19(水) 21:28:44
>>761
GoFのデザパタなら、
「オブジェクト指向における再利用のためのデザインパターン」
とある。

非OOPLでもOOP出来る、と主張したり、実践しようとしたりする人がいるので、
そいういう人に聞いてみるのがいいかも。>非OOP言語にも適用可能なの?

763 :デフォルトの名無しさん:2009/08/19(水) 21:46:20
OOPは考え方であって別にCでもOOP出来るわな。
やりやすいかやりにくいかはさておき。

764 :デフォルトの名無しさん:2009/08/19(水) 23:29:02
CでOOPやると、C++が素晴らしい言語に見えるぞ。

765 :デフォルトの名無しさん:2009/08/20(木) 09:13:09
>>764
俺もそう思ったクチ。
非OOPLで夢見てもどうしたって煩雑になる。

だから、CでOOP「っぽく」という着地点になってしまったり、
恥ずかしいような虚しいような気分になる。

766 :デフォルトの名無しさん:2009/08/20(木) 14:45:33
stateとcommandってどうちがうんですか?


767 :デフォルトの名無しさん:2009/08/20(木) 19:48:28
何を以てstateとcommandを同じだと認識してるのかが全然わからんのだが

768 :デフォルトの名無しさん:2009/08/21(金) 09:22:31
>>766
あえて調べずに、テキトーなことを言うと、

1) commandパターンはアクションをパラメータ化する。
undoしたりもできるようにもやりやすいと思われ。

2) stateパターンはコンポジションでグルグル切り替える。
ゲームで言うと、
デモ画面、スタート画面、ゲーム中画面、ポーズ画面、エンディング、を切り替えたり。
それぞれの状態で、描画やキー入力、音楽などのそれぞれの処理を行う。
それらのインスタンスを並べて使っている側で、置き換えることで切り替える。

State state;が、state = titleになったり、 = demoになったりしつつ、
stateに対して、state.drowとかsate.playsoundとかしてみたりする。

以上、これらはすべてテキトーです。

769 :デフォルトの名無しさん:2009/08/21(金) 11:46:31
本でMediatorの項をみるとMediatorのほうには
Medi::changed(Coll*)しか通信手段が書かれてないんですが
ほかの通信よう関数(たとえば最寄の敵の座標をくれ、など)はつけたさないで全部
changed、アドレス比較、・・・というながれでやるのが普通なんでしょうか


770 :デフォルトの名無しさん:2009/08/25(火) 22:25:46
MFCとか.NET FrameworkとかってGoFのパターンがわかってたら理解早くなる?

771 :デフォルトの名無しさん:2009/08/25(火) 22:41:16
遅くはならないだろうな

772 :デフォルトの名無しさん:2009/08/28(金) 16:21:23
・XMLのエレメントツリーは既存の稼働中モジュールなので修正は最小限に
・ツリーに対してどのような操作があるかは未定
という状況を前提に、XMLのエレメントツリーを探索して、
特定のノードや属性値を探したり上書きしたり枝を追加したりしたいんですが、
Visitorパターンがお勧めなんでしょうか?

XMLエレメントの最上位superクラスに、再帰で自分自身と子供について
処理するメソッドを複数追加していくってのはあまりやりたくないのです。

773 :772:2009/08/28(金) 17:05:09
つらつら考えてたんですが、visitorで処理を追加する場合、visitorクラスの兄弟クラスというのか、
同じインタフェースを実装するクラスを追加するのが普通なんでしょうか?
1人1殺じゃない、1クラス1メソッドという感じで。
acceptからは決まったメソッドしか呼べませんよね。。。

accept時に呼んでほしいメソッド名を第2引数で渡しておいて、
それをvisitの第2引数で戻してもらって、
visitorのvisit内でリフレクションで自分自身の指定メソッドをコールするなんてのは…やらなそうだなあ。

774 :デフォルトの名無しさん:2009/08/28(金) 23:12:48
XSLTでやれば良いと思うんだけど。

775 :デフォルトの名無しさん:2009/09/01(火) 01:27:11
仕事で「なるべくデザインパターンとか使わずに、分かりやすいコードでお願いします。」
って言われた。
デザパタより分かりやすいコードってどんなだ…

776 :デフォルトの名無しさん:2009/09/01(火) 01:30:19
input, process, output の3つのメソッドだけが存在するコード

777 :デフォルトの名無しさん:2009/09/01(火) 01:54:31
>>775
一切使わずではなく、なるべく使わずなんだよね

Template Method, Strategy, class-side Factory
あたりにとどめておけばいいんじゃない?

上記3つすら理解出来ないと言われれば、お手上げだ

778 :デフォルトの名無しさん:2009/09/01(火) 02:04:57
>>775
クラスのことをモジュール、メソッドをサブルーチンと言って
相手が安心したような顔をしたら勘定系の書き方をしろということだろうな。

779 :デフォルトの名無しさん:2009/09/01(火) 11:05:52
メソッドを関数と言うとかそういったやつだなw

780 :デフォルトの名無しさん:2009/09/01(火) 11:21:17
マジレスだが、「わかりやすいコード」が力点だろ。
必要ならデザパタを理解させればいいじゃん。

781 :デフォルトの名無しさん:2009/09/01(火) 13:24:43
是非うちの老害どもに理解させてやってくれ。
猿に教える方がまだ楽だと思うがね。

782 :772:2009/09/01(火) 16:06:04
>>774
2つのXMLを両方チェックしながら操作したいのと、
XSLTはデバッグしにくいので…

783 :デフォルトの名無しさん:2009/09/10(木) 00:40:14
「Java言語で学ぶデザインパターン入門」という本を持っているのですが、それの第2版っぽい
「増補改訂版Java言語で学ぶデザインパターン入門」との差分って分かる方いますか?
今度、デザインパターンを勉強するのですが、増補改訂版を新しく買った方が良いでしょうか?

784 :デフォルトの名無しさん:2009/10/28(水) 00:54:06
GoFじゃないけど、DAOパターンについて質問。
DAOってWebサービスからXML取得してビーンにして返す処理も範疇?
パッケージレイアウトでそんな処理をdaoパッケージに入るべきか迷った。

785 :デフォルトの名無しさん:2009/10/29(木) 17:34:20
アダプタパターンべんりすなぁ


786 :デフォルトの名無しさん:2009/11/07(土) 23:27:55
StrategyパターンとTempleteMethodパターンの違いがよくわかりません。
教えてください。

787 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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×4で16通りの組み合わせになる。これはバリエーションが増えれば増えるほど、差が開くことになることを意味している。

デメリットは、処理をほかのクラスに任せてしまうため、Method()の処理を確認するのにあちこちをみなきゃならなくなる。

(つづく)



790 :デフォルトの名無しさん:2009/11/08(日) 13:48:51
>>789のつづき
逆にMethod_A(), Method_B()のそれぞれでバリエーションが現れるのではなく、その組み合わせでバリエーションが発生する場合は、Template Methodが向いているといえる。

例えば、各ファイルを読み込むクラスを考えると、テキストファイル、画像ファイルなど、オープン > 読み込み > クローズがファイルの種類のバリエーションとなるため、Template Method向きとなる。

これを、無理してStrategyにしてしまうと、逆に分かりづらくなる気がしない?

P.S.
>>787, 788はJavaの例っていってるけど、ぜんぜんJavaじゃないです。ってゆうかコレ何言語?。スマン


791 :デフォルトの名無しさん:2009/11/08(日) 14:00:52
最後に、StrategyとTemplate Methodの使い分けについて。

機能を分解する際、基本的にStrategyを使う。
ただし、上の例の様に、組み合わせでバリエーションが現れる場合は、Template Methodの適用も考える。


Tmplate Methodのほかの適用例として、Abstract Skelton Classってのもある。詳細はググってもらうとして、簡単に書くと

インターフェース > 抽象クラス > 実装クラスというようなクラス構成のこと

あと、Strategyが理解出来る様になると、委譲型Adapter, Decorator, Chain of Responsibilityなどの、派生するパターンも理解出来る様になると思う。

とりとめの無い文章なって、ごめんね。


792 :デフォルトの名無しさん:2009/11/08(日) 14:00:55
よくがんばった

793 :786:2009/11/08(日) 17:06:51
TemplateMethod とStrategyについて質問したものです。回答ありがとうございます。
でもわかりません。
「MethodA(),Method_B()のバリエーションが、4つずつだと」というのはStrategyパターンでは
IHogeをimplementsすつクラスが4あるということですよね。
一方TemplateパターンにおいてはSampleParentをextendsするクラスが4つあるということですよね。
そういうイメージの中、8通りとか16通りというのは何の数を表しているのでしょうか?
16通りというのはわかります。AB4つずつあるので全部を表現するには新たに16個のサブクラスが必要になる。
けれどもStrategyの方はよくわからないんです。interfaceクラスをAとBごとに2つ作るということですか?
(つづく)

794 :786:2009/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{//これが4つ
public void Method_A() {}
public void Method_B() {}
}
class HogeHoge implements IHogeB{//これが4つ
public void Method_A() {}
public void Method_B() {}
}

てことなのでしょうか?


795 :786:2009/11/08(日) 17:12:54
これなら新規に追加するのは8個とおもうのですが。


796 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/11/20(金) 04:49:20
Gof本の151ページに描いてある、Adapterパターンの「適用可能性」について、

・まったく無関係で予想もつかないようなクラス
(必ずしも互換性のあるインタフェースを持つとは限らない)とも協調していける、
再利用可能なクラスを作成したい場合。

って言うのがあるんですが、これの意味がわかる方っていらっしゃいますか?



800 :デフォルトの名無しさん:2009/11/20(金) 09:22:10
ラムダとか使えばあらかたのデザパタがいらなくなると聞きました。
まとめてエロイ人。

801 :デフォルトの名無しさん:2009/11/20(金) 12:13:47
>>800
とか が気になるけど
Lambdaで不要になるのはStrategyパターン

802 :デフォルトの名無しさん:2009/11/21(土) 08:22:02
Template系の半分はいらなくなるわな


803 :デフォルトの名無しさん:2009/11/21(土) 18:37:22
そうか?

804 :デフォルトの名無しさん:2009/11/21(土) 20:43:51
ファクトリーでサブクラスの生成を管理しようとしてるんだがこれサブクラスの数がめっちゃ増えてくると結局すごい大変な労力を支払わされない?
今のところ New<T>(){ return new T; } の関数ポインタとmap<TagType, NewType>を使って管理してるんだが、もっと楽な方法はないだろうか


805 :デフォルトの名無しさん:2009/11/21(土) 21:37:54
パッと思いつくのは map にしてしまっているのでファ
クトリ群を継承とか使って階層的に出来ない点かなぁ…。
ケースバイケースだろうけど。

806 :デフォルトの名無しさん:2009/11/23(月) 00:12:35
DataMapperパターン
ってどうやって実装すればいいのですか?

807 :デフォルトの名無しさん:2009/11/23(月) 10:37:09
>>806
節子、それGoFとちゃう。スレ違いや。

808 :デフォルトの名無しさん:2009/11/23(月) 10:52:17
ORマッパ?

809 :デフォルトの名無しさん:2009/11/23(月) 15:42:14
やーここはGoFに限定するスレではないべ?
とはいえ>>806はだいぶ狭いドメインの話題のようだが

810 :デフォルトの名無しさん:2009/11/25(水) 00:46:23
DataMapperパターン
もわからねぇのかこの腐れ外道供

811 :デフォルトの名無しさん:2009/11/25(水) 21:57:36
わかってるのはお前だけだからがんばれ

812 :デフォルトの名無しさん:2009/11/29(日) 16:56:36
C++の評議委員がGoに乗り換えするらしいぞ

813 :デフォルトの名無しさん:2010/01/23(土) 02:24:23
つうか、デザインパターンって流行らないよな
シンプルなことをわざわざ手間をかけて複雑にしてるのばかりだし

814 :デフォルトの名無しさん:2010/01/23(土) 02:42:48
最近では、言語やフレームワーク、ライブラリに組み込まれてるからね。
コーダーレベルなら、別に意識しなくても良いと思うよ。

815 :デフォルトの名無しさん:2010/02/06(土) 20:38:41
んなことないだろ。少し複雑なプログラムになれば、いくらでも使うだろ。
別に意識しなくとも自然とGoFのデザインパターンのようなものに行き着く。

816 :デフォルトの名無しさん:2010/02/06(土) 23:37:34
デザインパタンは、本来は複雑なものをシンプルにするためのものだよね。
その辺の感覚の分からない人の場合、複雑になったり無駄が増えても
とにかくデザインパターンを使えばよい設計になると勘違いしがち

817 :デフォルトの名無しさん:2010/02/07(日) 01:12:39
根本から理解してない奴増えたな・・・

818 :デフォルトの名無しさん:2010/02/07(日) 03:47:18
パターンに名前付けたのがすごいし

819 :デフォルトの名無しさん:2010/02/07(日) 14:43:35
言葉遊びがたまに役に立つこともある、っていう匙加減が難しい。
全く役に立たないと思ったり、逆に、口先だけで何でも解決すると思ったりする。

820 :デフォルトの名無しさん:2010/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 :デフォルトの名無しさん:2010/03/30(火) 03:19:26
どうて言われてもな。
CreateB()、CreateC()、CreateD(double)じゃ駄目なのか?

822 :デフォルトの名無しさん:2010/04/19(月) 11:49:40
>>820

このパターンで、わざわざファクトリーにしてる意味がわかんないんだが。

A b = new BA();
A c = new CA();
A d = new DA(double);

でいいんでない?

823 :デフォルトの名無しさん:2010/06/02(水) 21:16:41
デザインパターンまったくの初心者なんですが、
このパターンだけはやっておけってパターンありませんか?
Java始めたんですが、デザインパターンの必要性がわかりません。
きっかけとしてなにか一つでもやっておきたいんですが、
オススメのパターンとかありませんか?

http://www.hellohiro.com/pattern/

824 :デフォルトの名無しさん:2010/06/02(水) 22:06:30
Javaやってりゃ意識しなくともパターンのお世話になる
意識すればそれらの答は出る

825 :デフォルトの名無しさん:2010/06/03(木) 11:39:17
C++でデザパタやると汚くなるな

826 :デフォルトの名無しさん:2010/06/03(木) 16:21:51
>>823
ソースコードを読むのが一番いい。
デザインパターンは学ぶものではない。

827 :デフォルトの名無しさん:2010/06/06(日) 11:13:44
>>823
StrategyとTemplate Method

この2つをものに出来れば、ほかのGOFパターンの大半はおさえられる。

828 :デフォルトの名無しさん:2010/06/06(日) 11:46:21
>>827
なんというか、同意してやってもよいぞ。ほめてつかわす。

829 :デフォルトの名無しさん:2010/06/11(金) 23:48:22
インタフェース書いときゃそのうち使える

830 :デフォルトの名無しさん:2010/06/12(土) 00:54:10
デザインパターンを学ぶのもいいけど、
自分でパターンを考えるのも面白そうだよな!

831 :デフォルトの名無しさん:2010/06/12(土) 11:27:27
>>830
俺のなんちゃらパターンを言い出す前に、
しっかりGoFを押さえておかないと迷路に嵌まり込む。

832 :デフォルトの名無しさん:2010/06/12(土) 12:50:56
GoF以降新しいパターンの本は出てきていない
GoFに上がっているパターンのみで十分にプログラミングできる
すでに完成されたプログラミング戦略であって,
オレオレパターンが入り込む余地など無い

833 :デフォルトの名無しさん:2010/06/12(土) 13:32:53
GOFが十分完成されたものなので、
新たなパターンが入りこむ余地は無いと思う

GOFパターンの組み合わせにより、
なパターンを構成できるかも知れんが、
それはもはやアーキテクチャパターンの世界


834 :デフォルトの名無しさん:2010/06/12(土) 13:42:57
分割統治パターン
別名:サブルーチン、プロシージャ、関数、モジュール、クラス

835 :デフォルトの名無しさん:2010/06/12(土) 14:00:19
じゃあおれがとっておきを披露する。
基底クラスが派生クラスを知っている糞設計だが、
こういうことをしたいとき便利かもしれない。
二回ディスパッチパターン。

class Shape {
void intersect(Shape s) {}
void dispatch(Circle c, Shape s) {
s.intersect(c);
}
void dispatch(Box b, Shape s) {
s.intersect(b);
}
void intersect(Circle c) {}
void intersect(Box b) {}
}
class Circle extends Shape {
void intersect(Shape s) {
dispatch(this, s);
}
void intersect(Circle c) {
System.out.println("c-c");
}
void intersect(Box b) {
System.out.println("c-b");
}
}

836 :デフォルトの名無しさん:2010/06/12(土) 14:01:19
class Box extends Shape {
void intersect(Shape s) {
dispatch(this, s);
}
void intersect(Circle c) {
System.out.println("b-c");
}
void intersect(Box b) {
System.out.println("b-b");
}
}
class VisitorTest {
public static void main(String[] args) {
Shape b = new Box();
Shape c = new Circle();
b.intersect(b);
b.intersect(c);
c.intersect(c);
c.intersect(b);
}
}

837 :デフォルトの名無しさん:2010/06/12(土) 14:10:32
中二らしくもっとカッコイイなまえにしておく。
AlternateDispatch パターン。

838 :デフォルトの名無しさん:2010/06/12(土) 23:52:49
>>835
javaで頼む

839 :デフォルトの名無しさん:2010/06/12(土) 23:53:36
と思ったらjavaだった
インデントしてくれyo


840 :デフォルトの名無しさん:2010/06/13(日) 03:16:36
>>830
Gofで扱われている言語でなければその価値は十分にある。
でも、その言語ならではのパターンが確立していることが多いと思う。

841 :デフォルトの名無しさん:2010/06/13(日) 06:18:49
>>836
典型的なアンチパターン

842 :デフォルトの名無しさん:2010/06/13(日) 12:00:24
>>841
色んな形のオブジェクト群の間の衝突検出、
どうやって記述する?

843 :デフォルトの名無しさん:2010/06/13(日) 13:22:12
つModern C++ Design

>835-836は
・基底クラスのShapeが派生クラスのCircleやBoxを知っているのは色々望ましくない。
・派生クラスの数に応じてサイズが指数的に大きくなる

今はCircleとBoxしか派生してないからいいけど、
TriangleとかPentagonとか色々派生クラスが増えると悲惨になる。

844 :デフォルトの名無しさん:2010/06/13(日) 13:26:51
あ、>843はどう書くかについて言及したわけではなく、
設計上不味い所を一応指摘しただけ

845 :デフォルトの名無しさん:2010/06/13(日) 13:33:39
>>843
うむ。派生クラスが増えることで、糞さが露呈するのは同意。
さらに、兄弟クラスで知り合っているので、
新しい兄弟が出来れば、それを追記して回る必要もある。

ただ、一度ライブラリとして出揃ってしまえば、
それを使うクライアント側からしたら、
呼び出しは簡潔になってると思う。

どこかに便利さを出そうとして、
どこかが汚れるのはアリではなかろうか。

駄目? やっぱこんな糞パターン無し?

846 :デフォルトの名無しさん:2010/06/13(日) 13:40:41
list.add(new Triangle()); // 2D
list.add(new Circle()); // 2D
list.add(new Box());
list.add(new Sphere());
list.add(new Cone());

とかして、
for (int i = 0; i < list.sie; i++) {
 shape s1 = list.get(i);
 for (int j = i + 1; j < list.sie; h++) {
  shape s2 = list.get(j);
  if (s1.intersect(s2)) {}
 }
}
とShapeして一括処理できることは、旨みが無いだろうか。

847 :デフォルトの名無しさん:2010/06/13(日) 13:50:35
当たり判定って、それ専門のアルゴリズムが多々あるのに、力技やら汎用的なデザイン・パターンで処理しようって考えからして間違ってけどね。
もっと別のお題をどうぞ。

848 :デフォルトの名無しさん:2010/06/13(日) 17:36:16
「それダブルディスパッチじゃね?」って突っ込み待ちじゃなかったのかよ…

Lokiやmore effective c++に、ダブルディスパッチでクラス同士の
依存関係を絶つ方法が載ってるから見てみるといい。

849 :デフォルトの名無しさん:2010/06/13(日) 18:08:01
俺もそう思った。相当昔からある伝統的パターンだろと。

850 :デフォルトの名無しさん:2010/06/13(日) 19:56:14
車輪の再発見!

851 :デフォルトの名無しさん:2010/06/13(日) 20:32:03
JavaマにMCDを読めというのはあまりに酷

852 :デフォルトの名無しさん:2010/06/27(日) 18:48:16
>>845
デザインパターンは基本的にメンテナンス性を上げるためのもの。
むしろ下げてるという意味においては、少なくとも同列に並べるもんじゃない。

853 :デフォルトの名無しさん:2010/06/27(日) 21:45:32
具体的なクラスを定義したライブラリが出揃ってから〜
だと汎用性や拡張性が無いよね。デザインパターンと呼べるかどうか

オレはJavaはわからんし、ダブルディスパッチを使う場面に
遭遇したことないから、あまりまじめに考えてこなかったけど
これ考え出すと結構難しいね。
boost::variantで簡単にできないかと思ったけど今ひとつだった

http://codepad.org/m61Vic9c

854 :デフォルトの名無しさん:2010/06/27(日) 22:14:58
>>853
それだと型情報もったまま単にオーバーライドしてるだけでは?
(テンプレートだからオーバーライドですらないか?)

一旦Shape型になった変数群を、
実際の派生型を意識させずにintersectさせるには…
などといおうとしたけど、
boost::apply_visitor( IntersectVisitor(), vl, vr );
この部分はそうなってるな。
acceptさせてそっから始まるダブルディスパッチなんだろうな。

855 :デフォルトの名無しさん:2010/06/27(日) 22:23:07
痛恨orz
オーバーロードな…俺の顔は今まさに真っ赤。

856 :デフォルトの名無しさん:2010/09/17(金) 23:37:35
メディエーターって仲介するクラスが増えるとメンバー関数がどんどん増えて大きくなりすぎだと思うんだけど、それって普通なのかな?

mediator * pm;
pm->getInfoHogeOfA();
pm->getInfoFugaOfA();
pm->getInfoHogeOfB();
・・・
pm->getInfoPiyoC();

みたいな感じで登録したいクラスが増えるたび、知りたい情報が増えるたび無尽蔵にメンバ関数が増えていく・・・

857 :デフォルトの名無しさん:2010/09/18(土) 01:10:38
何をしたいのか良くわからんが、なぜ外部から mediator を介してメンバの情報を取得しようとしているの?
それは mediator の仕事じゃないよね。

858 :デフォルトの名無しさん:2010/09/18(土) 09:56:00
>>856
抽象化

859 :デフォルトの名無しさん:2010/09/18(土) 10:07:32
ちゅう、しょうか?

860 :デフォルトの名無しさん:2010/09/18(土) 10:20:26
>>856
一つのMediatorに全てを任せてしまうと、巨大クラスになって扱いづらくなるので、
可能ならMediatorで共有したい責務を細分化してみては?

861 :デフォルトの名無しさん:2010/09/18(土) 11:07:47
mediatorはオブジェクト間の相互作用を記述する。

だから「相互作用」以外のことは、他のものが担当すべき。
「登録」「クラスが増え」とか、ひょっとしたらオブザーバの担当かもしれない。

862 :デフォルトの名無しさん:2010/09/18(土) 12:07:42
うーんなかなかむずかしいっす

>>857
ひょっとして条件に一致する要素の名前をリストでくれ、とかそういうのはmediatorの仕事にしないほうがいいんですかね?
こういうケースはmediatorじゃ無くてリストの参照を普通に保持するだけのほうがいいのだろうか

>>860
直交性のある仕事ごとに1つのMediatorを作るってことですかね
それはそれでMediatorだらけになりそうだけどメンバ関数地獄よりましなのかな・・・

>>861
相互作用って言うのがどこまでのことを言うのかが自分の中であいまいなのかも
多粒子系のポテンシャル相互作用みたいなわかりやすい話だったらいいんだけど

863 :デフォルトの名無しさん:2010/09/18(土) 12:17:51
>>862
相互作用ってのは、GoF本の例を見なされ。
ダイアログの上の、コンボボックスとラジオボタンの関係(だっけか?)みたいなのを、
mediatorを使って書いてる。
インスタンスが特殊な状況になったとき、それを判断して、
他のインスタンスへ特殊な呼び出しをする。

こうのとき、こう。こうなったら、こう。

っていう、汎用化しにくい特殊な作用を書く。

864 :デフォルトの名無しさん:2010/09/18(土) 19:39:54
>>862
「(複雑な条件)に該当する値をちょうだい」 とかの仕事は Facade の役割。
Mediator と Facade を兼ねたオブジェクトを作ることはままあることだけど、本来は別物。

で、Mediator が扱う相互作用とは
「Mediator が保持しているオブジェクトの間だけで交わされるメッセージ」
のことを言っている。
Mediator の中に閉じないメッセージ交換は、すなわち Mediator が取り扱う相互作用じゃないよ。

865 :デフォルトの名無しさん:2010/09/19(日) 00:43:23
>862
Mediatorとは、所詮内部データの共有に対して、名付けただけだから

具体的には、フォームAの変更をフォームBに伝えたいとき、間に共有モデルを置き、直接の依存を避けるパターン

なぜ直接の依存を避けるのか?
UIは、変更されることが多く、モデルはUIほどは変更されないから。

つまり、互いの変更が少なければ、わざわざ複雑な構造を取らなくても、直接依存しあったって構わない。

「条件に一致する要素」というのがどうゆうものか分からなけど、
例えば、子フォームで検索条件を入れると、親フォームがインクリメンタルに絞り込まれるものだったら、
子フォーム->モデル:条件に従いモデルデータの絞り込み。
モデル->親フォーム:変更したことを通知。

つまり、Mediatorなんて使わず、Strategy+Observerだって構わない

866 :デフォルトの名無しさん:2010/09/19(日) 01:42:14
>>865
Mediator を 「モデル」 にしなければいけないわけではない。扱うものを UI に限定しなければいけないわけでもない。
具体例を出すと分かりやすいけど、反面変なところに嵌りやすいよ。

要は、オブジェクト間ネットワークがフルコネクト型トポロジになると管理しにくくなるので、
それを解決するためにスター型にし、その中継点として Mediator を設置しました、という流れが必要。

フルコネクト型を選択するならば、Observer を進める。
スター型なら Mediator になる。

867 :デフォルトの名無しさん:2010/09/19(日) 12:35:04
みなさんどうもっす。まとめると
オブジェクト間に互いの情報を直接知らせない(参照させない)
複数のオブジェクトを協調させて、ひとつの仕事を実行させる
仕事が増えたら別のmediatorを作る
って感じですかね。言われてみるとメンバが増えまくるのはオカシイですね
なんとなくつかめてきたような気がします

868 :デフォルトの名無しさん:2010/09/19(日) 13:59:11
> 言われてみるとメンバが増えまくるのはオカシイですね

うん、そうそう。増えまくって、特定のインスタンスではなく、
特定の型に対して処理するんなら、
mediator以外の方法がマシに見えてくる。
他のやり方で抽象化できそうに見えてくる。

869 :デフォルトの名無しさん:2010/10/04(月) 00:32:35
質問です。
Visitor パターンで、Acceptor が膨大で Visitor 側が肥大化するのを何とかする方法ってありますか?
もしあれば、その方法を伝授いただきたいです。

870 :デフォルトの名無しさん:2010/10/04(月) 23:42:47
>>869
Visitorパターンは、各々のAcceptorが具体的にどのように処理されるかを意識することなく、
Visitorに一元管理させるものなので、肥大化を防ぐことはできません。諦めてください。


と、回答しただけではひどすぎるので、一応妥協案を。
例えば、各々のファイル拡張子をAcceptorにすると、Visitorは相当肥大化するでしょう。
しかし、ファイルは、テキスト、画像、楽曲、動画のようにある程度グループ化することができます。
グループごとにVisitorを作れば、多少肥大化を防ぐことはできるでしょう。

Acceptメソッドに渡すVisitorオブジェクトの検索は、Acceptor - Visitor間のlook-upテーブルをもつLocatorクラスを用意しておけば良いでしょう。

Java風に書くとこんな感じ
class VisitorLocator {
HashMap table;

public Visitor lookup(Class acceptorClass) {
return table[acceptorClass];
}
}

look-upテーブルの初期化は、派生クラスで行うもよし、依存性を注入するもよし、お好きにどうぞ。


871 :デフォルトの名無しさん:2010/10/13(水) 13:26:41
Visitorつかうには、データが再帰的処理できるような構造を持っていることが前提ですよね?

872 :デフォルトの名無しさん:2010/10/13(水) 13:31:11
MVCに関しての質問です。

wikipediaのMVC項目、「MVCのシナリオ」で、下記の疑問をもちました。

・Vにイベントハンドらを関連付ける人はこのモデルの上位に当たるオブジェクトが担当する?
・Cはオブザーバー的な役割を持っている?
・VはMを参照として持っている?なのでVが直接Mからデータを参照するのだろうか?
・Cは入力のオブザーバー的な役割のようだが、出力は担当しないのだろうか?

記事の下部にありますシナリオですが、
私としては以下のように読み取りました。

1. ユーザがviewに入力を行う
2. viewからの入力により、Vに登録したcontrollerのイベントハンドラやコールバック等がよばれる。
3. controllerが必要に応じたmodelのメソッドを呼び、ステータスを更新する。
4. 3の結果を表示する為にviewがmodelから必要なデータを取得し出力する。

また、概念図では相互残照を行っているように見受けられます・・・。

873 :デフォルトの名無しさん:2010/10/13(水) 13:32:56
http://hibari.2ch.net/test/read.cgi/tech/1284115490/745

874 :デフォルトの名無しさん:2010/10/13(水) 13:38:58
>>873そちらはお礼を書いて閉めてありますよ。

875 :デフォルトの名無しさん:2010/10/13(水) 13:41:30
http://hibari.2ch.net/test/read.cgi/tech/1284115490/746-748

876 :デフォルトの名無しさん:2010/10/13(水) 13:44:17
>>871
そうでもない

877 :デフォルトの名無しさん:2010/10/13(水) 13:54:07
>>876
調べていくために必要なメソッドさえあればデータごとに逐一書いてもできるよってことかな?

878 :デフォルトの名無しさん:2010/10/13(水) 14:11:36
Visitorってダブルディスパッチの高尚な呼び方じゃねーの?

879 :デフォルトの名無しさん:2010/10/13(水) 14:13:51
違うよ

880 :デフォルトの名無しさん:2010/10/14(木) 11:52:49
>>872
個々に答えるのは面倒なので、MVCに関する参考書だけを紹介。

・オブジェクト指向とGUI - オブジェクト指向システム分析設計入門, ソフト・リサーチ・センター
 http://aokilab.kyoto-su.ac.jp/documents/IntroductionToOOAOOD/chapter3/index-j.html#3-5
・使わないと損をするModel-View-Controller
 http://aokilab.kyoto-su.ac.jp/documents/MVC/page1.html
・ソフトウェアアーキテクチャ - ソフトウェア開発のためのパターン体系, 近代科学社
 http://direct.ips.co.jp/book/Template/Goods/go_BookstempKindai.cfm?GM_ID=KD0283&CM_ID=004300307&SPM_ID=1115&HN_NO=00430

余計に混乱するかもしれないけどねw

881 :デフォルトの名無しさん:2010/10/14(木) 12:02:06
Visitorの流れで質問させてください。
今ググると最初出てくる ttp://www.aerith.net/design/Visitor-j.html でVisitorが集合を扱うパターンのように書かれてますけど、
Visitorってダブルディスパッチが本質で、集合を扱うのは関係ないと思うんですけど間違ってます?
現に、wikipediaの方では集合なんて一切出てこないし。
どうなんでしょ?

>>878
ダブルディスパッチがない言語でダブルディスパッチを実現するためのパターンだと思いますけど違いますかね?

882 :デフォルトの名無しさん:2010/10/14(木) 13:51:18
>>880
レスありがとうございます。
さっそく読んでみます。

883 :デフォルトの名無しさん:2010/10/15(金) 17:49:59
>>880
MVCのついでに
DCIの参考書も紹介してください

884 :デフォルトの名無しさん:2010/10/18(月) 04:29:25
MVCってそんなにいいデザパタかな?
viewが圧倒的にでかいし、modelなんてあんまりいらないどころか、変に冗長なコードを
正当化するようで害の方が大きい
とか、正直思うんだが。


885 :デフォルトの名無しさん:2010/10/18(月) 07:05:21
別に使う必要が無ければ使わなくてもいい。

886 :デフォルトの名無しさん:2010/10/18(月) 11:37:03
>>884
PHPやっている人ですか?w

887 :デフォルトの名無しさん:2010/10/18(月) 21:51:46
>>884
それは自分が肥大化したViewを作っちゃってるだけだろ
適切なコードの場所を考えることを放棄して、なんでもかんでも
Viewに書いてしまっているという


888 :デフォルトの名無しさん:2010/10/19(火) 07:17:55
>>884
節子、それMVCやない

889 :デフォルトの名無しさん:2010/10/20(水) 16:42:08
でかい=面積比ででかい

890 :デフォルトの名無しさん:2010/10/23(土) 17:05:43
コントロールが一番よくわからん。
何でか懐かしのDoc-Viewになっちまう。

891 :デフォルトの名無しさん:2010/10/23(土) 19:14:54
方法にはそれぞれ適切な規模というものがある。
Document-Viewで十分まかなえているなら、無理にMVCにする必要はないと思うよ。

892 :デフォルトの名無しさん:2010/10/23(土) 19:38:06
Cは入力をどうの、らしいんだよな。
MVCの中でハッキリしてるのはMだけ。
VはMを知らないといけないし、
VはCをも知るという。
Cも同じくVとMを知り、インプットまで受け付けるという。

rubyのまつもとさんが書いた図(俺はこの図が一番シックリくる):

(アウトプット)→ユーザ→(インプット)
     ↑           ↓
「    V    」←→「    C    」
     ↓           ↓
     →「    M    」←

893 :デフォルトの名無しさん:2010/10/25(月) 01:57:03
VとCがちょっけ・・・つ?

894 :デフォルトの名無しさん:2010/10/25(月) 06:22:12
>>892は理解していない

895 :デフォルトの名無しさん:2010/10/25(月) 13:18:11
MVCのモデル図だと、MがVに値を渡しているような感じで矢印がむいてるけど、
このやじるに違和感をおぼえるんだよな。

M←→C←→Vで、Cが橋渡し約の方がMがVに直接値を渡すよりよいとおもうんだけどな。

896 :デフォルトの名無しさん:2010/10/25(月) 19:29:39
Javaでグローバル変数が使いたいから、Singleton使っているけど、
この使い方ってあまり良くないの?

897 :デフォルトの名無しさん:2010/10/25(月) 19:58:37
ショートカット目的のシングルトンはクソの山です。

898 :デフォルトの名無しさん:2010/10/26(火) 00:06:56
グローバル変数使いたくないから使わないっていうのも
なんだかなぁって感じ

899 :デフォルトの名無しさん:2010/10/26(火) 01:05:28
>>896
singleton使って、DB接続のような外部リソースにアクセスさせたいというような用途なら、辞めといたほうがいいと思うよ。
unit-test frameworkで、テストしずらくなるから。

900 :デフォルトの名無しさん:2010/10/26(火) 02:47:53
シングルトンはメインウィンドウとか描画デバイスとかそのへんで使うかなぁ
まあそれにしてもファイルローカル変数でいいかって感じだし
ほんとうに使いどころが見つからないよねシングルトン

901 :デフォルトの名無しさん:2010/10/26(火) 07:07:01
NullObjectとリソースプールになら使ってる>シングルトン


902 :デフォルトの名無しさん:2010/10/26(火) 13:11:14
どなたか>>895にご意見をいただきたい・・・。

903 :デフォルトの名無しさん:2010/10/26(火) 20:49:17
>>895はMVPだな
ModelとViewが明確に分離されるのが特徴で
最近ではMVCよりも評価が高い

904 :デフォルトの名無しさん:2010/10/26(火) 22:03:21
>>903
MVP・・・そんなのもあるのか。
ちょっと調べてきます。

905 :デフォルトの名無しさん:2010/10/27(水) 01:39:19
ちょっと調べてみたら、最近はPMとかMVVMなんてのもあるんだね

906 :デフォルトの名無しさん:2010/10/27(水) 03:26:15
MVCパターンの例を作ってみた。
Webのアレではないので注意。

とりあえずC++で書いてみたが見えるか?
http://codepad.org/0fr9ZZRh

やってることは簡単なイメージビューアだ。

 Controller::Applicationというコントローラに
ウィンドウやボタン,イメージビューを持たせている。
View::Imageはモデルとしては、Model::Imageしかとらないが
ここでは、Model::Imageの実装であるModel::ImageSeekListを
渡している。

 Model::ImageSeekListは1枚の画像のように
見せかけるが、実際は画像のリストで、Next,Previousが
呼ばれると別の画像になったかのように振る舞う。

 また、Next,Previous他Set〜が呼ばれると対応するビューに
Updateのメッセージが伝播される。これによりモデルの
更新だけで、ビューが最新の状態に書き換わる。

 今回のコードでは書いていないが、ビューがTextBoxなんかのとき
ビューに文字入力があるとそれに登録されたモデルが更新される形式がある。
そのような方式をプラガブルMVCというそうな。この形の場M-VCという構造に
なるんだそうな。

907 :デフォルトの名無しさん:2010/10/27(水) 08:15:17
>>906
ImageとImageSeekListのあたりが工夫なんだろうけど
とりあえずこんな設計はねぇよ

908 :デフォルトの名無しさん:2010/10/27(水) 13:02:14
>>907
付けなくていいスマポにCONST付けたり
Controller::Applicationで親クラスに
モデル渡してなかったりとコーディング上には
粗があるが、設計で問題あるか?
まぁこういう作りはあまりみないけど。

909 :デフォルトの名無しさん:2010/10/27(水) 21:08:17
>>908
一言で書けば、必要のないパターンを無駄に使っているということ。
たぶんCompositeの応用のつもりだろうけど、もともと階層構造になっていないものに
適用しようというのに無理がある。

こういう不自然な設計をしていると分かりづらく、仕様変更にも弱くなる。
例えばビューアの下にサムネールのリストを表示させたくなったとして、この設計だと
メインの画像と一貫性のある方法では実現が難しい。

そもそも『簡単なイメージビューア』と書いているように、とてもシンプルな例のはず。
トリッキーな事をする必要は全くないし、MVCの例としてならなおさらするべきじゃない。

910 :907:2010/10/27(水) 22:04:00
>>909
へー。
でも、この例だと
1,サムネール追加するんならサムネールビュー追加する
2.Model::ApplicationのからImageListを取得できるようにする
3.Model::Application内でImageListとImageSeekListを結合
4.サムネールビューのアクションで送られてきたIndexをImageSeekListのJumpに引き渡す
これだけで改修済むけど。メンテナンス性悪いか?

改善案があればおせーて。


911 :デフォルトの名無しさん:2010/10/27(水) 22:05:00
>>910
間違えた906です。

912 :デフォルトの名無しさん:2010/10/27(水) 22:32:28
>>910
"一貫性のある方法"では難しいと書いたんだけどな
910の改修でのやり方がまぁ普通の方法だが、メイン画像の方法と比べて一貫性があるかどうか
もう一度よく考えてほしい(単体とコレクションの違いは別として)

913 :デフォルトの名無しさん:2010/10/27(水) 23:14:29
>>912
んー。Model::Applicationとしてアプリケーション固有部分を
ぶち込んでるところ?
Model::ImageとModel::Applicationが階層になっていると。
今の構造だと、Model::Imageに位置するモデルにも
さらに中にモデルを持たせてるよ。複数のビューを
まとめて作った再利用可能なビューにモデルを引き
渡すためにね。ビュー自体が階層構造になってる。
これがヤバいの?

914 :913:2010/10/27(水) 23:23:45
補足。
Model::Application自体は使い捨てのモデル。
Controller::Applicationも使い捨て。
1つのアプリケーションにつき1つのみ。
その中に入ってるモデルは再利用可能なんだけどね。
ビューのUpdateによる更新プロセスを一般化させたくてしてる。

915 :デフォルトの名無しさん:2010/10/27(水) 23:59:10
>>913
なんかあんまり通じてないな。
ずっとImageとImageSeekListについてだけ書いていたんだけど。
とにかく言いたいことは(※ImageとImageSeekListについて書いた)909だけで、
要するに何でそんなに無駄に複雑にしてるのか?ってことだけだ。

916 :デフォルトの名無しさん:2010/10/28(木) 00:07:39
>>915
 ImageSeekListなんかにせず、ImageList使ってアクション起きたら
単純にビューに差し込めってこと?

917 :916:2010/10/28(木) 00:13:28
 言葉足らずだったので書き直します。

 ImageSeekListなんか使わず、ImageList使ってアクション起きたら
単純にImageList内のImageをビューに差し込めってこと?

※そうすると、indexの管理をコントローラーがする事になるよね?

918 :デフォルトの名無しさん:2010/10/28(木) 00:29:47
>>917
いや、Imageを継承するなっていうだけ
910のサムネイル画像と同じように単純に取得メソッドを設ければ済む話

919 :デフォルトの名無しさん:2010/10/28(木) 00:37:57
>>918
ああ、ImageSeekListにGetImageを持たせるのか。
なるほどね。

920 :919:2010/10/28(木) 00:55:35
問題点を整理するとこうか。

例えばImageSeekListのNextが呼び出される。
すると今までは、ImageList[index]のImageの
メンバーを全て移譲してビューに見せていた。
(Imageが変更を受けると移譲を構成しなおす必要がある)

GetImageを使う事になると、ビューとImageSeekListで
共有用のImageを一つ持っておく。んで、ImageSeekListが
変化した場合は、共有用Imageを上書きしてやる。
(Imageに複製用関数を用意しておけばImageメンバの整合性に
ついて面倒をみずに済む)

921 :デフォルトの名無しさん:2010/10/28(木) 01:32:38
「Imageが静的な画像を表す」ってが根底にあって、ImageSeekListで動的に切り替えることが可能ってことにしたの?

そもそも論だけど、システム全体でImageが静的な画像を表すのを前提にしていたら、
ImageSeekListでnext呼んだら画像が変わって、その変わった画像の「更新」をシステム全体が対応しないといけないよな
これは考えてた?

逆にImageが動的な画像を表せたり、画像の更新がシステム全体で対応しているなら、
そもそもImageとImageを扱うこと自体がImageSeekListの様なものであって
新たにImageSeekListを作り直すのがわからね

922 :デフォルトの名無しさん:2010/10/28(木) 01:33:27
まあ動けばいいんですけどね!

923 :デフォルトの名無しさん:2010/10/28(木) 02:36:34
>>921
 ん?よくわからんな。
 Image自体は、書き換えられるオブジェクトだよ。(具体的には線を書き込めたり)
静的動的ってのはそういう意味?まさか動画とかって意味じゃないよね。

Imageが変更されると、関連付けられたビュー全てに更新メッセージが飛ぶ。
さらに、モデル内で依存しているものも存在するのでそっちにも更新メッセージが飛ぶ。
システム全体の更新ってこういうことだよね?

>そもそもImageとImageを扱うこと自体がImageSeekListの様なものであって
>新たにImageSeekListを作り直すのがわからね
ここの意味がよくわからない。
作り直すってのは、ImageSeekListがImageの継承をやめる事を言ってるの?

924 :デフォルトの名無しさん:2010/10/28(木) 08:43:10
Imageの中で閉じろという意味だろ
元々の設計がおかしいということ

925 :デフォルトの名無しさん:2010/10/28(木) 08:43:10
Imageの中で閉じろという意味だろ
元々の設計がおかしいということ

926 :デフォルトの名無しさん:2010/10/28(木) 08:44:11
どうでもいいことなのに2回書いてしまった
吊ってくる

927 :デフォルトの名無しさん:2010/10/28(木) 13:30:55
>>924
意味が分かったなる程ね。
そうすると単純な静的画像にも
動的動作可能な機構が付くわけだ。

View::Imageがツールバーとかの切り替わらない画像に
使われたら無駄な気がするがどうなんだろ。
ま、その場合MVC機構事態もデッドウェイトだけど。


928 :906:2010/10/28(木) 21:36:44
 色々指摘された点を踏まえて改修してみた。
 あと、コントローラーの中にビューの実態があるのが気に入らなかったんで
外で結合するようにしてみました。ぱっと見、Smalltalkの原点回帰ぽい。
この修正で、ControlerをViewに継ぎ足すだけで既存の動作を再利用
できるようになったように思う。

http://codepad.org/uRylNEZ9

 ただ、ここで一つ悩みが。Viewの構成メンバはSet、Get両方つけるべきか?
Setをつければ、Set〜を呼び出すコントローラでビューの切り替えが出きるようになる。
果たしてコントローラーがそんな事していいのか?あと、ビューの構成が変わった時
同じビューの一部を参照している別のコントローラーはどうすべきか?
モデルと同じく、ビューの構成が変わったら、参照しているコントローラー全体に
Updateのメッセージを送信すべきなのか?

929 :デフォルトの名無しさん:2010/10/28(木) 23:46:32
907だけど、なんで余計おかしくなってんだよ…
>>921>>924の言ってることもよく分からない
>>928であってるの?
ImageにSetImageListとかNextとかありえないだろ
これなら最初のコードの方がずっとましだ

930 :デフォルトの名無しさん:2010/10/29(金) 00:26:26
俺もスレだけ読んでて今初めてソース見たけど、
これならMVCを全く意識せずに書いた方がシンプルなコードになりそうだ。

931 :906:2010/10/29(金) 01:12:32
>>929

SetImageListをそのままImageにもって行ったのは俺が悪いわ。
たぶん>>921とかの意見に合わせるならFileListとかFilePathListとか
データソース系になるんだろうと思う。あと、動的に画像を生成するオブジェクトとか。

そもそも、ImageSeekListの中身を機能をImageに統合したのは自分でも
正しいかよくわからん。言ってるからしてみただけ。

932 :デフォルトの名無しさん:2010/10/29(金) 01:55:54
>>907の当初の意見で修正してみた。多分反映できてると思う。

http://codepad.org/E4gqIFxA

で、問題はビューなんだよビュー。ビューの中に突っ込んだモデルの管理とか
どうすんの?ビューの中にコントローラーから別のビュー突っ込まれたら、
親のビューが差し込まれたビューに自分のモデル差し込み直すのか?
それとも、コントローラーであらかじめモデルを突っ込んだビューを作って
ビューに突っ込むのか?

結局子ビュー管理は生産から廃棄まで親ビューが面倒みるしかないんじゃないか?
どうなんだ?

933 :デフォルトの名無しさん:2010/10/29(金) 02:10:30
また、ミスしてた。ImageSeekListからのモデルの取り出しだけ修正。

http://codepad.org/93tnX9Ad

934 :デフォルトの名無しさん:2010/10/29(金) 10:29:38
rubyやってるとC++なんかでよくやるわって思えてくる

935 :デフォルトの名無しさん:2010/10/29(金) 18:58:09
だからImageを継承するなって
まぁこれは書きミスだろうけど、よく見るとなんか全体的におかしいな
始めの指摘が重箱の隅に見えるわ

あと今更だけどSystem::ModelとかSimpleVC, Share, Sharedって何?
C++は詳しくないんだけど標準的に用意されてる機構なの?

936 :デフォルトの名無しさん:2010/10/29(金) 21:37:52
>>935
ああ済まんImageは消し忘れ
ShareとSharedも表記揺れミス。
Sharedはboost::shared_ptrで良かったんだけど
一度使ったらboost好きの奴らからboostのアレ使えこれ使えって
余計なレス付きそうだったからやめてた。
SimpleVCとかSystem::Modelとかは勝手に書いた。
実装上整合性を保つのに必要だったからね。なにも継承しない
クラスがメンバーに無い関数を呼べるのは不自然だしね。
一応この管理系のクラスには実際に動く自作コードがあってそれを元にしてる。
そっちじゃ管理系のクラスは全部MVCって名前空間に入ってるけど。

937 :デフォルトの名無しさん:2010/10/29(金) 22:16:10
>>935
MVC管理系クラスの宣言codepadに上げようか?サンプルコードの本位から
外れるけど、なんなら実装部まで上げようか?
あとboostに書き換えられるとこも書き換えるか?

938 :デフォルトの名無しさん:2010/10/29(金) 22:33:07
>>936,937
「サンプルコードとは…」というとこから始めなきゃ駄目か?
こういっちゃ何だけど、MVCだのデザインパターンだのという以前の問題
GoF本も読んでいないか、読んでも理解できないだろ
もうちょっと勉強してこい
今はこれ以上続けるつもりはないよ

939 :デフォルトの名無しさん:2010/10/29(金) 22:34:36
・・・とバカ糞が申しております

940 :デフォルトの名無しさん:2010/10/29(金) 23:01:43
>>938
そうね未知なものいれちゃいかんね。
あと、理屈が完成までいってないもんサンプルと言うのも無いね。
スマンかった。

941 :デフォルトの名無しさん:2010/10/30(土) 09:37:45
MVCってGoFじゃなくね?

942 :デフォルトの名無しさん:2010/10/30(土) 09:51:35
少なくともGoF本にはMVCパターンというものは存在してないね。
MVCはデザインパターンというよりアーキテクチャパターンの一種だから。
というか、xxxパターンというのは(UMLと同様な)共通言語という方便にすぎないものなんだから、
「パターンに沿っていないから(私には)議論できません、(私は)議論に参加しません」というのは、
まあ、何と言うかアレだね....。

943 :デフォルトの名無しさん:2010/10/30(土) 09:56:01
MVCはGoFを組み合わせて応用したものだからGoFと言えるような言えないようなそんな感じ

944 :デフォルトの名無しさん:2010/10/30(土) 10:59:34
>>942
「パターンに沿っていないから(私には)議論できません」って何だよ。どこからそんな話が出てきた?
パターンに沿ってないならスレ違いだろ。

945 :デフォルトの名無しさん:2010/10/30(土) 12:19:29
確かにスレ違いでは有ると思うが、
それを許容するか否かは別の問題。
許容する人だけがレスをつける。

946 :デフォルトの名無しさん:2010/10/30(土) 14:01:43
>>942
おまえは腹切って死ね

947 :デフォルトの名無しさん:2010/10/30(土) 15:07:45
GoFもMVCを組み合わせて応用したものだからMVCといえないような言えるようなそんな感じ。

948 :デフォルトの名無しさん:2010/10/30(土) 15:40:17
みなさんに質問なんだけど、

949 :デフォルトの名無しさん:2010/10/30(土) 17:09:33
誰でもスレは立てられるんだよ・・・?

950 :デフォルトの名無しさん:2010/10/30(土) 21:30:12
なんで今頃GoFが伸びてんの?

951 :デフォルトの名無しさん:2010/10/30(土) 22:03:26
なんでだなんでだろー

952 :デフォルトの名無しさん:2010/10/31(日) 11:09:38
ひょっとしてデザインパターンってテンプレートとかでライブラリにするようなものじゃないんですか?

953 :デフォルトの名無しさん:2010/10/31(日) 13:15:57
↑デザインパターンの由来って知ってる?

954 :デフォルトの名無しさん:2010/10/31(日) 19:42:04
設計パターンとでも訳せばこの手の勘違いは減っただろう

955 :デフォルトの名無しさん:2010/11/05(金) 16:16:01
機能側の例でループ処理でインターフェースの呼び出しとかしかやってないから身に付かないんだよな。。。

956 :デフォルトの名無しさん:2010/11/16(火) 13:08:31
テンプレートメソッドパターンなんだけど、一部の子クラスで定義する
テンプレートメソッドに共通の処理をあとで加えたくなったんだ。
こういうときどうするのがいいのかなぁ。

class P {
abstract function f();
}

class C1 extends P {
function f() {
}
}
...

とりあえずぱっと思いつくのは中間にMというクラスをはさんで
必要な子クラスのfの定義をgに置き換えていくというのだけど

abstract class M extends P {
function f() {
共通の処理
g();
}
abstract function g();
}

class C1 extends M {
function g() {
}
}

なんかもっとうまい書き方ないかな。

957 :デフォルトの名無しさん:2010/11/17(水) 00:31:32
>>956
まぁ、それが妥当じゃない

必須ではないが、Template Meghodを適用するときは、

interface I {function f()}

abstract class A implements I {
override function f() {
// 共通処理を書く
this.f_sub();
//共通処理を書く
}

abstract function f_sub();
}

class C extends A {
override function f_sub() {
// 固有の処理を書く
}
}

みたいにすると、つぶしが利きやすくなるよ

958 :デフォルトの名無しさん:2011/01/26(水) 20:47:55
リファクタリングをしていて、グローバルな設定を保持するクラスを見つけました。
これを引数にして3階層程引きずっていたので、Singletonにしようと思ったのですが、
.getInstance()を必要になったクラスそれぞれで呼ぶ必要があります(当然ですが)。
結合度を何とか下げられないかと考えているのですが、
何か妙案があれば教えていただければと思います。

959 :デフォルトの名無しさん:2011/01/26(水) 21:27:59
データを渡すってことは、データと処理が離れてるってことで、
ひょっとしたらその処理は、もっとデータ側に持たせたほうが自然かもしれないね。

設定オブジェクト、みたいなものってどうしても出来てしまうけど、
やっぱりそれって、使いにくくていろいろ足引っ張ってる。妙案は…思いつかない。

960 :958:2011/01/27(木) 22:48:28
>>959
ありがとうございます。

>ひょっとしたらその処理は、もっとデータ側に持たせたほうが自然かもしれないね。
理想としては設定の粒度を細かくして、ドメインオブジェクトとして見ることだと思います。
ただ、こういう設定管理系は、いったんそれが出来てしまうと、
便利な箱のような扱いになってしまうことが多いですし、
といって、そこの改善に注力してしまうのも大げさではないかと思ってしまうのも事実です。
時間があれば突き詰めたい部分ではありますが、
今更俺俺フレームワークを作ってもなぁというのもありますし。

961 :デフォルトの名無しさん:2011/04/07(木) 13:54:18.82
visitorパターンの本質って何でしょうか?
ダブルディスパッチは関係ない気がしました

962 :デフォルトの名無しさん:2011/04/07(木) 14:39:23.46
switchが整数値で分岐するのに対し、visitorは型で分岐する。
型を整数で表せばswitchが使えるが、整数で表したくないならvisitorを使う。

963 :デフォルトの名無しさん:2011/04/07(木) 14:55:26.56
>>961
新幹線でワゴンの売り子さんが世話しにきてくれるだろ。
自分が行かなくても世話してくれる人が引数によって向こうからやってきてくれるのがビジターパターン。

964 :デフォルトの名無しさん:2011/04/07(木) 14:58:48.85
>>962
なるほど

>>963
処理の対象が処理をしてくれるクラスを指定するみたいなことでしょうか

965 :デフォルトの名無しさん:2011/05/15(日) 12:59:35.70
オブザーバーやその他の相互参照の形になる場合はどっちを強参照にするか迷う

966 :デフォルトの名無しさん:2011/06/02(木) 12:24:13.98
ストラテジーパターンについてですが、
結局、どこかでif文でどのコンテクストかを判定する必要がありますよね?
この判定についてほ
Strategy s = StrategyFactory.create(parameter);
みたいな形でファクトリーに押し込んでしまうという考えでいいでしょうか。
parameterによって、返ってくるConcrete Strategyが異なるという形です。

967 :デフォルトの名無しさん:2011/06/02(木) 12:25:55.35
すみませんageます

968 :デフォルトの名無しさん:2011/06/02(木) 13:16:16.01
>>966
concrete strategyを選択する処理はストラテジーパターンの範囲外。自分で決めればいい
factoryに押し込むのもアリ

それと、結局どこかでif……というのはちょっと違う気がする
concrete strategyを動的に選択する場面というのはほとんどないと思う

969 :デフォルトの名無しさん:2011/06/02(木) 20:55:55.75
>>966
ちょっと大げさかもだけと、都度生成するものなら、Prototypeパターンを適用。一度生成して、使い回すのなら、Flyweightを適用すると、if文の排除は可能。

970 :966:2011/06/02(木) 22:05:38.02
>>968,969
ありがとうございます。

>それと、結局どこかでif……というのはちょっと違う気がする
すみません、僕の認識が間違っているのかも知れません。
実現したかったのは
switch (pattern){
 case : Pattern.A : doA();
 case : Pattern.B : doB();
 ...
}
において、メインの処理上からswitch文を消したかったのです。そこで、

interface MyStrategy { void execute(); }
class StrategyA implements MyStrategy... //doA()に相当
class StrategyB implements MyStrategy... //doB()に相当

としたのですが、結局、patternを判定する処理は必要になると思ったのです。
そこでファクトリークラスを作って、判定と生成を任せようと考えました。
Prototypeはどちらのcloneを用いるかを、やはり判定する必要があるように思います。

今思いつきましたが、Map<Pattern, MyStrategy>を最初にシングルトンで作っておけば、
MyStrategyMap.get(pattern).execute();
みたいな感じでいけなくもないですね。
あ、でもStrategyが増えるたびに、このMapの初期化処理をメンテする必要があるので微妙ですね。
すみません、お知恵を拝借できればと思います。

971 :デフォルトの名無しさん:2011/06/02(木) 22:30:18.64
>>970
class A implements Controler{};
class B implements Controler{};

Map<Pattern,Controler> table = new Map<Pattern,Controler>();
PatternPool pool = new PatternPool();

table.put(pool.get("^private .*"), new A());
table.put(pool.get("^ public .*"), new B());

table.get(pool.match("private int value"))..action(); // Aのactionが起動
table.get(pool.match("public int age"))..action(); // Bのactionが起動

単にswitchを消したいならこういう風にできる。
これをなにパターンというのかは知らんけどな。

972 :971:2011/06/02(木) 22:32:00.73
AとBの実装空にしてたわ、あそこactionの実装を書いとくんな。


973 :デフォルトの名無しさん:2011/06/05(日) 01:23:42.46
MapをシングルトンにしてMyStrategyコンストラクタで登録させるとかどうか
StrategyAとStrategyBもシングルトンにする

974 :デフォルトの名無しさん:2011/06/05(日) 03:09:24.10
>>973
 安易にシングルトンを推めるな。
基本的に、interfaceと委譲で凌げる。
シングルトンは絶対にインスタンスが2つ存在しては
いけない場合のみの最終手段。
 何らかの調停を行わなければならず、
それを1つのインスタンスで処理しなければ破綻する場合だ。
例えば現在アクセス中のファイルリストとか。
シングルトンからアクセス権を得たインスタンスのみ操作できるようにする。

975 :デフォルトの名無しさん:2011/06/06(月) 01:49:55.89
俺はそろそろ夜食の辛ラーメンを食って寝ますよお前ら
舌が慣れてしまって全然辛いと思わなくなった
ビールの〆に飲むと辛いけどただ食うと平気

976 :デフォルトの名無しさん:2011/06/06(月) 23:44:04.19
>>971
最初に一回だけ初期化しといて、そこから利用してるので、lightweightか、それに類するパターンになると思う。

977 :デフォルトの名無しさん:2011/06/07(火) 00:04:20.40
>>970
>Prototypeはどちらのcloneを用いるかを、やはり判定する必要があるように思います。

swichの所で書いてるpatternで取り出せば、判定いらなくね?

>今思いつきましたが、Map<Pattern, MyStrategy>を最初にシングルトンで作っておけば、
他の人も言ってるけど、Singletonは最終手段にしとけ。特に外部リソース(dbとか)にアクセスするのなら。モックによる入れ替えが困難になるから、テストしづらくなるぞ。

>あ、でもStrategyが増えるたびに、このMapの初期化処理をメンテする必要があるので微妙ですね。
設定ファイルに書き出すか、javaなら、特定のフォルダにあるクラス名を取得してくるとか


978 :デフォルトの名無しさん:2011/06/07(火) 01:45:12.55
>>設定ファイル
それって結局便利なのか?
ifのほうがましだ。

979 :デフォルトの名無しさん:2011/06/23(木) 15:38:31.08
このスレ息してないな


980 :デフォルトの名無しさん:2011/06/24(金) 17:23:51.51
リファクタリングしなくてもいい良質なコードを書いているからね

981 :デフォルトの名無しさん:2011/06/24(金) 19:00:59.95
ここデザパタだぞ

982 :デフォルトの名無しさん:2011/06/25(土) 19:02:52.45
リファクタリングw

294 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)