06/03/12 02:21:34
GoF本読んでSmalltalk好きになった
といっても、GoF本のサンプルってほとんどC++なんだよね
で、SmalltalkでといえばDesign Patterns Smalltalk Companion
マジおすすめ
17:デフォルトの名無しさん
06/03/12 13:58:40
>>16
＞GoF本読んでSmalltalk好きになった
おっ、その心は？
Smalltalkって標準クラスの設計がいいの？
18:デフォルトの名無しさん
06/03/13 00:52:53
『･･･こころ』
買っちゃった
♪明日届く～
19:デフォルトの名無しさん
06/03/13 02:32:32
>>17
そうね～やっぱクラスライブラリの設計ですね
デザインパターンの固まりって感じなんですよ
Smalltalkを調べていくと、言語仕様が非常にシンプルで
言語で規定されるようなこと（制御文とか）すらクラスに
メソッドで定義されている、ってのにちょっと感動。
20:デフォルトの名無しさん
06/03/15 00:05:06
このスレでもよく言われるけどデザインパターンは設計の話じゃないってどういうこと？
あきらかに設計の話だと思うんだけど。
21:デフォルトの名無しさん
06/03/15 00:07:01
実装レベルでしか理解してない奴がまだまだ多いってこった
22:デフォルトの名無しさん
06/03/15 00:23:55
>>20
リファクタリング(この言葉もテストの修正を許容するものから
許容しないものまで幅があって一概には使いにくいな)を前提
にボトムアップで見ると実装の話になる。
テストにしろリファクリングにしろデザパタにしろ、幅がありす
ぎて各自がバラバラの思惑で使うもんだからグダグダになっ
てる。
23:デフォルトの名無しさん
06/03/15 01:28:26
今日、java.io.*のクラス図を初めてjudeで自動生成してみたんだが
・・・いや、美しいな。
（こいつぁArtだ。）
クラス設計とはかくありたいなと思ったよ。
あんまりかっこよかったんで、ついA3で印刷して部屋に貼っといたぜ。
24:デフォルトの名無しさん
06/03/15 01:34:25
>>23
うｐ
25:デフォルトの名無しさん
06/03/15 01:53:19
日頃どういったクラス設計に携わっているかの違いなんだろうか
格段に美しいとは思わない。当たり前の設計だと思うんだが・・・
26:NAME IS NULL
06/03/15 01:57:20
デザパタ入門とＪＡＶＡの格言買ってしまった。
良書ということで一週間読み込むとする。
27:デフォルトの名無しさん
06/03/15 06:29:22
>>20
実装だろ？
じゃなきゃあんなソースばっか載ってる本になるのはおかしい。
28:デフォルトの名無しさん
06/03/15 07:55:55
そもそも実装という作業は、設計作業の一部なんだが。
このことをわかってないﾔｼが多すぎ。
29:デフォルトの名無しさん
06/03/15 09:02:49
設計のデザインパターンと実装のデザインパターンをごっちゃにしてる奴が多いだけでしょ。
デザインパターン＝クラス構造とか思い込むからそうなる。
30:勉強中
06/03/15 10:54:03
設計ってしかことないけど（というかOOPってしたことないけど）、どれをクラスにするのかを決めて、
実装設計でデザパタを使う。実装がうまくいきそうにない（エレガントでないとか）ので、再度クラスを
考え直す。
っていうのを繰り返すのかな？
31:デフォルトの名無しさん
06/03/15 12:36:49
>>20
設計の話だと思うよ。設計というと↓のように大きく分けて２つに分類されると思う。
■設計┬→基本設計
└→詳細設計（プログラム設計）
デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
ＳＥレベルでの「基本設計」ではない。
以前、俺も「「設計の話じゃない」みたいなニュアンスで登校したことがあるのでフォロー。
えと、知ってたらごめんなさいごめんなさいごめんなさいなのですが。
32:デフォルトの名無しさん
06/03/15 12:52:11
>>23
java.io.* のクラスは素敵だよな。あの汎用性と拡張性。
いつも通りに入出力処理してるだけで勝手にMD5チェックサムが取れる、
DigestInput/OutputStreamとかもう天才の発想だよな。あれは感動した。
java.io.* は拡張のしやすさから結構、外部の人間が有益なライブラリ作ったりしてるよね。
↓ここの外人のクラス設計も素敵とおもた。ParallelWriterとかSequenceIteratorとか。
URLﾘﾝｸ(www.symbic.net)
33:デフォルトの名無しさん
06/03/15 19:13:01
>>31
＞ デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
＞ ＳＥレベルでの「基本設計」ではない。
ＳＥという定義をどう捉えているのかは不明だが、保守性を考えたシステムを作ろうと
した場合，基本設計はおろか要求の洗い出しの段階から考慮する必要があるのだが
どうだろうか？
そういった点から考えると、デザパタが詳細設計という枠に収まるかどうかは極めて
疑問だと思うぞ。
P.S.
それから、基本設計はＳＥがやるものだなんて考え方をしてＳＥとＰＧの間に溝を作る
こと自体が問題を生みだしてるんじゃないか？
34:デフォルトの名無しさん
06/03/16 11:03:32
>>33
まず、基本設計書の認識がお互いあってるか確認したいんだけど、
顧客からの要件を受けて、その要件をコンピュータ上では、
このような形で満たせます。っていう話を顧客に説明するために、
作成する資料が基本設計書という認識でお互いあってるんだよね？
顧客側は一般人だろうし、ただやりたいこと（要件）だけがあるだけで、
それがどんな形でコンピュータ上で実現されるのかわからない。
まずはそれを説明しなくちゃならないんだけど、
それは、例えば「要件」として出勤退勤のタイムカードをパソコンでやりたいとか。
実現方式として例えばOSはWINDOWSです。とか
そして、VBのEXE起動して「出勤ボタン」を押しますとか
Accessのファイル開いて「出勤ボタン」を押しますとか
ブラウザ起動して出勤退勤のページに移動して「出勤ボタン」を押しますとか
そんなものだと思うんだけど、そこにデザパタが入っていけるか？
35:34
06/03/16 11:10:17
ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな？
しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
または、その変更になる確立が高い箇所も、デザパタでは吸収できないかもしれないし、
最終的に、それを書くにしても詳細設計書だと思う。
36:34
06/03/16 11:17:07
＞それから、基本設計はＳＥがやるものだなんて考え方をしてＳＥとＰＧの間に溝を作る
＞こと自体が問題を生みだしてるんじゃないか？
それはあるね。SEしてる人間の連絡不足で、よくPGが仕様とは違うものを作ってしまったりする。
その責任がPGの責任になってしまったりするし。
仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。
でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。
37:33
06/03/16 13:04:26
>>34
それは私の言っている基本設計書ではありません。
＞ それは、例えば「要件」として出勤退勤のタイムカードをパソコンでやりたいとか。
＞ 実現方式として例えばOSはWINDOWSです。とか
これは「要求定義書」になりますね。
要求定義書っていうのは顧客の要求だけが書き連ねられているドキュメントではなく、
利害関係者（顧客，投資者，開発チーム等）の一致した要求が書き連ねられるもの
です。 このため OS は Windows で、というのも投資者（開発側企業）の思惑だったり
顧客の要望だったりする。
最近の開発だと、OSの選定が設計扱いされることは少ないんじゃないか？
なお、要求定義書にデザパタが出てくることはまずありません（変更に強いシステムという
要求はあるけど）。
＞ そして、VBのEXE起動して「出勤ボタン」を押しますとか
＞ Accessのファイル開いて「出勤ボタン」を押しますとか
＞ ブラウザ起動して出勤退勤のページに移動して「出勤ボタン」を押しますとか
これは画面設計書でしょう。 画面設計にいわゆる GoF のデザパタが出てくることは
ありません（芸術的なデザインのパターンはあるでしょうが）。
-----
＞ ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな？
＞ しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
関係ないことありませんぜ。 こういった作業はデザパタを適用する上で大きな布石となります。
「オブジェクト指向のこころ」に載っている共通性/可変性分析ってーのは、かなり上流工程の
作業になり、こういった行為を通じて構築対象のインタフェースをクローズアップしていくこと
ができます。 ということで、この工程を実施する時点でもうデザパタを意識することになるのです。
38:33
06/03/16 13:11:16
＞ 仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。
＞ でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。
そうなんだよな～。
仕事の面白さを取って責任を取るか、仕事の面白さを捨てて責任逃れをするかってとこで、
みんな後者を取っちゃうんだよなぁ。
39:デフォルトの名無しさん
06/03/16 23:51:12
なんかごちゃごちゃしてるけど、
結論としてはデザインパターンは設計の話ってことでいいの？
40:デフォルトの名無しさん
06/03/17 01:00:51
どこまでを設計と呼ぶべきかによる、って結論に落ち着くはず。
41:デフォルトの名無しさん
06/03/17 01:15:14
デザインパターンは内部設計の話です
42:デフォルトの名無しさん
06/03/17 01:27:53
やっぱり、設計段階でソースが出てくるのは同考えてもおかしい。
43:デフォルトの名無しさん
06/03/17 01:30:59
こういうフローチャートを書くとこんなソースになるんだよ
っていう教え方はわりとありふれてると思うのです
44:デフォルトの名無しさん
06/03/17 01:57:34
アブストラクトファクトリとシングルトンが
同じ設計レベルで出てくることってあるんかいな？
45:デフォルトの名無しさん
06/03/17 06:52:58
>>44
シングルトンを「インスタンスの個数を一定数にする」ものだと考えると
アブストラクトファクトリと同じ設計レベルになる。
もっともシングルトンは「インスタンスの個数を１個にする」という上述した
要求の特殊解なんだが。
46:デフォルトの名無しさん
06/03/17 06:55:15
>>42
ヒント： ソースコード＝設計図
つ URLﾘﾝｸ(www.biwa.ne.jp)
47:34
06/03/17 11:25:30
>>37-38
おー、びっくりした。基本設計で「これは○○パターンが適用できますよ！」とかを売り文句にするのかと思った。
＞これは画面設計書でしょう。 画面設計にいわゆる GoF のデザパタが出てくることは
ここで伝えたかったことはあれです。あれあれ。
「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。
＞関係ないことありませんぜ。 こういった作業はデザパタを適用する上で大きな布石となります。
んー、まぁ、要件によって実装は変わるから、デザパタを適用するか、しないかも確かに変わってくるし、
基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？
48:34
06/03/17 11:46:10
>>38
(;´-`)。o(そ、そうか！あいつら責任逃れのためか！あのやろう！)
まあ、そこで責任逃れしても、仕様と違うもの作って、
結局は作り直しさせられて残業の責任を負うはめになると思うけどね。
49:33
06/03/17 12:40:57
>>47
＞ ここで伝えたかったことはあれです。あれあれ。
＞ 「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
＞ システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。
悪い。 ここんところの日本語がまったく理解できなかった。
文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
というのは要求定義書の役割であって、画面設計書とは別物という認識なのだが。
基本設計というのは要求定義が完了してから始まる工程であり、そこからデザパタは適用できる
と主張しているわけっす。
＞ 基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？
オブジェクト指向技術を採用して開発を行う、、、となった時点で、変更容易性とかの話しに直結
するのが普通だと思うぞ。
基本設計ってーのは、平たく言えばシステム化対象となる問題領域に境界線を引いていく作業だと
思っている。 その時にどの部分をカプセル化して変更を封じ込められるようにするのかを検討する
ことは当然のことじゃないか？
50:34
06/03/17 13:33:09
＞文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
＞というのは要求定義書の役割であって、
あっ。そりゃそうだ。まあその、手順だね。システム化することによってどんな手順・操作になるかとか。
＞オブジェクト指向技術を採用して開発を行う、となった時点で、変更容易性とかの話しに直結するのが普通だと思うぞ。
ある部分の処理が、将来変更するか否か、柔軟性を持たせるべきか否か、重要度が高いか否か、
それはデザパタや、オブジェクト指向を意識せずに開発を進めた場合でも考慮することじゃないか？
それで内部設計の段階で、ここはこうなる可能性があるから柔軟性を持たせようって話になると思うんだけど。
まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
なんか違う気がする。
51:33
06/03/17 14:06:42
>>50
私の頭の中にある基本設計ってーのは、要求定義書が終わってから始まる一連の作業であり，
ユーザーのシナリオを一つ一つ分析しながら、サブシステムに分割していき、最終的には大まか
なクラス設計が完了するところまでと思っています。
で、サブシステムの分割や大まかなクラス設計を行う時点では、洗い出したサブシステムや
クラスの責務を決めないといけないので、この時点でインタフェースに着目する必要があるわけです。
そして、インタフェースという観点で設計を行い始めた時点でデザパタの適用というものは視野に
入っているというのが私の考えです。
＞ まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
＞ なんか違う気がする。
確かにまぁ、「どこかでデザインパターン使えないか？」といった感じで目を皿のようにして探しながら
基本設計するというイメージではなく、インタフェースを主にして考えながら「どういった切り口で
インタフェースを考えたら、うまくまとめられるのか？」といった観点で作業することになる。
しかし、デザパタを知っておくことで考え方の道筋が整理されるから、ここでのヒラメキが得やすくなる
ということが言いたい。
そう言う意味じゃ「デザパタを適用すること」が目的だと言っているのではなく，「デザパタの知識を利用
することでインタフェースを使った考え方ができるようになること」が重要なのだと思っている。
そして、それが基本設計にも適用できると主張している根拠になっているわけ。
52:デフォルトの名無しさん
06/03/17 20:35:31
>>51
GoFの23パターンだとそのレベルで適用するのってあったか？
パターンという括りならわかるけど
俺はそのレベルで適用可能なものってデザパタって言葉とずれてると感じるのだが
53:33
06/03/17 21:03:37
>>52
おおまかなクラス設計を行うと言っても、頭の中に実現可能性を想い描くことが
できなければ絵に描いた餅になる。 そういった点で GoF の23パターンを見た場合、
適用できないものの方が少ないと思う。
私の場合、よく使うのはBridge、AbstractFactory、Strategy、Observer、Visitor、等々
54:52
06/03/17 21:18:37
>>53
なんか俺はちょっと違うことを考えていたらしい
実現可能か考えずに、より適切なモデリングするぐらいのものかと思ってた
言語まである程度意識してるクラス設計まで ってことでいい？
55:33
06/03/17 21:51:21
>>54
いいっす。
そもそも、言語を考えずにモデリングするってーのは、はなはだ危険な行為だと思う。
だいたいクラス設計と言った瞬間に、オブジェクト指向言語の採用が前提となってるので
言語を意識しないモデリングなんてあり得ないと思うが。
基本設計時に詳細にとらわれて詳細の海に溺れてしまうのはいけないことだが、詳細に
立ち入ってはいけないということではない。 むしろ詳細を（頭の片隅ででも）考慮すること
なしに作った基本設計など、実現可能性のあやふやなゴミと同じだと思う。 上流工程は
下流工程のことを考えた上でないと成果物を作ってはならないと思っている。
蛇足だが、この辺りのことを理解してないSEが多く、下流工程を意識することなくモデリング
しようとするSEがいるためにSEとPGがいがみ合ってるということもあると思う。
クラス設計時に名詞と動詞を抽出するなんてアプローチを使ってちゃ、下流工程を意識しよう
にも意識できないわな。 そんな設計だと実装時にギャップで苦しむのは目に見えている。
56:52
06/03/17 22:05:51
>>55
アナパタは言語意識しないよね あのレベルなのかと思ってた
ソフトウェアを作るためのモデリングじゃなくて、現状把握のためのモデリングかと
基本設計って結構範囲が広いんだな
57:デフォルトの名無しさん
06/03/17 22:18:08
設計段階からデザインパターンを使いまくろうなんて考えていると、
アンチパターンになるぞ。
実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。
58:33
06/03/17 22:20:45
アナパタは結構毛色が違うよね。
あれは要求定義書を作る際に使うものだと認識してまふ。
要求定義＝Whatの定義、設計＝Howの定義なのでどうしても切り口は違って
くるかな。
ということで今日はボチボチ帰って寝るわ～。
59:デフォルトの名無しさん
06/03/18 00:42:04
>>57
それ単に設計が不十分なだけじゃん。
60:デフォルトの名無しさん
06/03/18 01:28:46
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい。
61:デフォルトの名無しさん
06/03/18 03:58:40
俺がGoFのデザパタ意識するのは
・(ツールレベルの)フレームワークの設計/実装をしてる時
・実装コードのリファクタリングをする時
だけ。
設計か実装かと言われれば、俺の意識だと実装。
前者は人によっては設計と呼ぶかもしれない。
アプリレベルのフレームワーク設計してる時には
とたとえばJ2EEデザインパターンや
アンチパターンは大いに意識するけど
GoFを意識することはない。
62:デフォルトの名無しさん
06/03/18 07:55:20
>>57
＞ 設計段階からデザインパターンを使いまくろうなんて考えていると、
＞ アンチパターンになるぞ。
＞ 実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。
リファクタリング時にデザパタが有用であることは認める。 しかし、設計時にも間違い
なく有効だ。
リファクタリングの時にしかデザパタを使わないという考え方が成立するのは、XPのように
必要最小限のシステムを作った後、各サイクルを1週間程度で回していくというプロセスを
採用した時だけだと思うぞ。 ある程度の大きさのシステムを数ヶ月単位で回していく場合、
その考え方では初回のリファクタリングの作業量が莫大なものとなって破綻してしまう。
それから、アンチパターンについてだが、確かにアンチパターンというものは常に頭に
置いておく必要がある。 しかしアンチパターンのほとんどは「ものごとのバランスをとるため」
に存在するのだ。
「分析地獄」というアンチパターンがあるからといって、分析はやらないでおこう、、、なんて
ことにならないのと同じことだ。
>>60
つ >>46
>>61
アプリレベルの設計でも Bridge パターンはよく使うぞ。
このパターンは、日本で最も過小評価されているパターンなんじゃないかと思う。
俺も「こころ」本を読むまで Bridge を正しく認識していなかったが。w
（他にも当たり前のように Strategy とか使うけど。）
63:デフォルトの名無しさん
06/03/18 10:44:09
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい
64:デフォルトの名無しさん
06/03/18 10:47:48
うちだとアプリレベルの設計はもっと大枠で捉えてしまうんすよ。
プロセス・スレッド間の通信には何使うとか、
他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおうとか、
DAO層はあのやり方で実装しようとか、
その程度だけ決めて実装(含むプロトタイプ作成)に入っちゃう。
小規模で言わなくても分かってる同士だからうまく行ってるけど
大規模になったらきちんとフレームワーク設計やらなならんのだろうなぁ、とは感じる。
どうやら「こころ」が良本らしいので読んでみようかな。
65:デフォルトの名無しさん
06/03/18 12:05:09
>>64
「プロセス・スレッド間の通信には何使う」や「他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおう」ってーのは、大枠で捉えているという
よりも、「そこにあるものを使う」っていういわばボトムアップの発想じゃないかな。
「DAO層はあのやり方で実装しよう」というのも、レイヤーありきの発想でボトムアップ
に近いと思う。
こういった「あるものを流用」したり「技術からの要求を主」にする設計は、顧客の要求する
ものを取り込むタイミングが難しく、顧客ニーズからブレたものができる危険性がある。
大規模開発をする予定があるのなら、トップダウンの視点は身につけておいた方がいいと
思うぞ。 この視点は小規模開発でも有効だし。
66:34
06/03/18 13:14:44
>>51
うーむ、詳細設計をしつつ基本設計をする。って感じに聞こえてしまうなぁ。
基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？
それだと俺が働いてきた会社の基本設計とは違うかもしれない。
というか基本設計とかって働いてる場所によって意味合いが変わってくるかもね。
「こころ」か。良本らしいので俺も読んでみようかな。Bridgeはいいパターンだよね。
漏れがよく使うのはDecorator、Bridge、Factory Method、Strategy、Flyweightとか。
他のは理解はできるけど、いい使い所が思いつかなかったりする orz
それぞれのパターンのうまい使い方の情報交換とかしたい。
67:デフォルトの名無しさん
06/03/18 13:50:37
こころ たけーよ こころ orz
昨日、本買ったばっかりなのに
68:33
06/03/18 14:46:19
>>66
＞ 基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？
いや、クラス設計は完了しないっす。 業務オブジェクトのモデリングが主な目的で、
主要なクラスと主要なメソッドだけを記述したクラス図ができるだけです（あっ、パッケージ
関連図も成果物です）。
詳細設計では、さまざまな内部メソッドを追加し、クラスが追加されることも当然あります。
シーケンス図も詳細設計で考えますかね。
＞ それぞれのパターンのうまい使い方の情報交換とかしたい。
いいですねー、それ。 どんな感じでやりゃいいのか、イメージはできてないけど。
69:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:16:45
TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
70:デフォルトの名無しさん
06/03/19 02:54:15
俺は Template Method が一番利用頻度高い。
その次に来るのは Adapter や Decorator、Singleton。
DIコンテナ使うことが殆どなので
潜在的には Factory パターンの利用回数がダントツなんだろうか。
Template Method はDIコンテナと親和性が高いので多用してしまう。
71:デフォルトの名無しさん
06/03/19 12:36:24
なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしいよな
72:デフォルトの名無しさん
06/03/19 17:01:07
>>71
釣れますか～？
73:デフォルトの名無しさん
06/03/19 17:49:49
>>72
釣られちゃってますね。
74:デフォルトの名無しさん
06/03/19 19:44:20
>>73
おっ、釣れた釣れた。
75:デフォルトの名無しさん
06/03/19 22:21:03
>>74
これをメタフィッシングパターンと命名する。
76:デフォルトの名無しさん
06/03/20 01:23:29
＞ それぞれのパターンのうまい使い方の情報交換とかしたい。
とか言っちゃったけど、言いだしっぺの俺がまずなんか書かねば…。
77:デフォルトの名無しさん
06/03/20 21:22:18
俺がプロトタイプ作成→リファクタリング→Template Method適用に至るよくある手順
(1) 詳細は無視して大まかな流れだけを実装する。
(2) 細部に肉付けして簡単なテストが通ることを確認する。
(3) 一部の処理が特定の条件下では異なるため、その処理と、条件分岐の部分を書く。
テストが通ることを確認する。
(4) 別の条件だと別の処理を書かなくてはならず、いい加減面倒になってくる。
もっとスマートに書けないものかと思案する。
どう考えても Template Method パターンです。本当にありがとうございました。
(5) という事で書き直す。テストも通る。
78:デフォルトの名無しさん
06/03/20 22:29:11
構造に関するパターンは設計段階でも話が出る可能性はある。
振る舞いに関するパターンはほとんどでない。
79:デフォルトの名無しさん
06/03/21 08:07:30
>>77
よくある手順って…おまいは毎回そんなことを考えてるのか。
いい加減、最初からわかれよ。
80:デフォルトの名無しさん
06/03/21 08:37:57
>>78
振る舞いに関するパターンでも Command，Interpreter，Observer，Visitor なんかは
大まかな設計レベルでも十分考慮対象だったぞ。 それ以外はちょっと詳細な設計
レベルになるかもしれんが。
あと、生成に関するパターンも構造に関するパターンと対にして設計時点で使うわな。
81:デフォルトの名無しさん
06/03/21 10:39:52
>79
最初は動くものを作って、だんだん仕上げてく。
こっちの方が最終的に早く出来上がるし、
変な設計に振り回されないので見通しも良くなる。
別フレームワーク作るわけじゃないんだから。
82:デフォルトの名無しさん
06/03/21 13:10:21
>>81
曳光弾形式の開発ができる現場だとそれもいいんじゃない？
83:デフォルトの名無しさん
06/03/21 13:46:40
行き当たりばったりなだけじゃん
84:デフォルトの名無しさん
06/03/21 13:58:20
>>83
悪く言えばそうだけど、XPなんて正にそれじゃん。
行き当たりばったりだったとしても、そのプロセスに顧客を巻き込めれば無問題。
スパイラル開発で各サイクルを早く回そうとするのもまったく同じこと。
ただ、そういったプロセスを使えない開発の場合には、まったくもって指摘通りになる。
そしてこの場合、デザパタはリファクタリング時だけでなく、設計時にも活用することになる。
そんだけのことじゃない？
85:デフォルトの名無しさん
06/03/22 00:43:07
俺は84じゃないが、最初は出来るとこまで作って、
後からどんどん洗練してくやり方なんて最近じゃ普通の考え方だと思うんだけど。
むしろ、一気に完成形を目指さず、変更されることを意識しつつ、
少しづつ仕上げていくやり方の方が変更に強いもんができるんじゃないかと。
最近のアジャイル開発とか言われてるのもこんな感じの考え方でしょ？
86:デフォルトの名無しさん
06/03/22 02:16:46
設計する時だってプロトタイプ作成を並行して
頭で考えたことが実際に実現可能か調べながら進めていく。
んで一発で完璧な設計にたどり着くことなんて稀で
いろいろ試行錯誤しながら進めていく。
このプロトタイプ作成作業を実装フェーズにカウントすると
行き当たりばったりだと罵られて、
設計フェーズにカウントするとお咎め無し？
俺には同じものに見える。
87:デフォルトの名無しさん
06/03/22 08:10:28
>>86
＞ 俺には同じものに見える。
同じものだ。
しかしプロトタイプを実装フェーズだと考え、それをそのままの形で成果物に
してしまうと成果物が無茶苦茶汚くなることがある。
もちろんそれはプロセス側で対処すべき問題なのだが、そういった対処が
なされていなければ、「行き当たりばったりで作った汚いコード」という謗りを
受けることになる。
プロトタイプを設計フェーズだと考える場合、そのプロトタイプは実装フェーズ
に引き継がれないという暗黙の前提が生まれるため「行き当たりばったり」という
表現は妥当ではなくなる。 ってーか設計フェーズは試行錯誤するのが当たり前。
88:デフォルトの名無しさん
06/03/23 15:41:57
なるほど。
89:デフォルトの名無しさん
06/04/07 16:41:51
このスレではわりと好意的な評価のようなので
こころを買ってみた。
最初は眠くなる話が多い気がする。
良さが分かるまでにしばらくかかりそうだ。
90:デフォルトの名無しさん
06/04/08 01:15:39
>>89
もしや、他にデザパタの本読んだ経験無い？
91:デフォルトの名無しさん
06/04/08 01:17:44
結城本でFAかと思ってた
92:デフォルトの名無しさん
06/04/08 01:21:13
結城本はかなりメジャーだからむしろ宣伝するやつが少ない
93:デフォルトの名無しさん
06/04/08 07:13:58
「ここは○×パターンでコーディングする」と書かれた仕様書が上から落ちてくる
のであれば、結城本でも十分だろう。
しかし自分で適用可能なデザインパターンを見つけ出す（＝自分で仕様書を書く）場合、
結城本だけではツライと思う。
（練習問題を飛ばさずに真面目にじっくりやってれば、できるかもしれんが。）
94:デフォルトの名無しさん
06/04/08 12:47:40
>90
結城本は持ってる。
デザパタそのものの有用性は自分なりに理解してる。
結城本の感想は93氏に近い。
過程すっ飛ばして天からデザパタが降ってくるスタイル。
パターンの暗記は出来ても理解はありえないなと。
「こころ」は前書き読む限りだと過程を重視してるようなので期待。
まだ第一部読んでるあたりで、UMLがなんちゃらとかそんな話。
非常に眠くなる。読み飛ばせばいいのだけど、それが出来ない性分。
95:デフォルトの名無しさん
06/04/08 13:08:32
ある程度パターンを暗記したら、あとは実際にデザパタを意識したコードを読むのが良いと思う。
クラスライブラリを勉強するのがいいかもしれない。
Ｃ＃とかJavaのクラスライブラリリファレンスをみると勉強になったりする。
あとは使ったことないオブジェクト指向言語の勉強するといいかもしれない。RubyとかD言語とか。
後はフレームワークとかも。Log4jとかRailsとか。
論を勉強するのもいいけど、やっぱり証拠もないと理解しにくいかと。
96:デフォルトの名無しさん
06/04/09 02:30:58
てっきりあの「あなたの考えを広げるためのヒント」が
結城本の特徴なのかと思ってた。
あれの域にとどまらず、もっと応用の指針について
解説されてる本があるのね。
97:デフォルトの名無しさん
06/04/09 10:33:45
結城本はGOFの劣化版でしかない
GOFのわかりやすいところ(結城が理解できたところ)を
初心者向けに言い直しただけ
それ以上の情報はいっさいなし
オブジェクト指向のこころとアジャイルソフトウェア開発の奥義を読んで、
リファレンスとしてGOFを手元においておけばいいと思う
98:デフォルトの名無しさん
06/04/09 10:40:03
GOFはなんでC++を選んだのだろう
99:デフォルトの名無しさん
06/04/09 11:14:05
どういうこと？
Smalltalkで全編書けってこと？
GoF本オリジナルは1995年だからJavaはありえんよ
100:デフォルトの名無しさん
06/04/09 14:18:36
日本語版なら付属CDにJavaソースあるしね。
確か、SmalltalkとC++のうち話したいことがわかりやすいほうで例示する、みたいなこと
書いてなかったっけ。
101:デフォルトの名無しさん
06/04/09 14:21:47
>>99
単純になんでだろう、と思っただけなんだ。
そうか、Javaなかったのか。そりゃ仕方ない。
102:デフォルトの名無しさん
06/04/09 15:43:01
結城さんに抽象的なモノを説明させるとかなりヤバい。
例とか背景とかなしで、方法だけを詳しく掘り下げる。
同マルチスレッド編もそんなスタイル。途中で読むの止めた。
具体的な内容だとすごく分かりやすい・読みやすいもの書いてくれるんだけど。
HOW TO 本が彼の本来のフィールドだと思う。
103:デフォルトの名無しさん
06/04/13 01:17:07
あるシステムのGUIコンポーネントを表示する部分の設計をしているんだけど、
綺麗な設計が浮かばなくて悩んでます。
Componentは0～複数個のFrameを持っていて、
Frameには0個か1個のComponentが入り、描画の仕方はComponent自身が知っている、
というのが基本設計で、
「WindowコンポーネントはMenuBarフレームとStatusBarフレームを持っている」
「MenuBarフレームにはMenuコンポーネントが入る」
という感じで定義されていく予定なんだけど、
フレームの大きさに合わせて描画するコンポーネントが一般的なのはいいけど、
フレームの中に入ったコンポーネントの大きさによって描画が変化するコンポーネントがあって、
一度の再描画で全部綺麗に更新するためにはトップダウンでもボトムアップでも駄目で困ってます。
こういう場合、どういうパターンが有用だと思いますか？
104:デフォルトの名無しさん
06/04/13 02:13:37
Composite
105:デフォルトの名無しさん
06/04/13 23:20:57
トップダウンでできんじゃないの？
>>104のいうとおりCompositeで。
106:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/04/14 08:12:06
そういうのはパターンと言うよりアルゴリズムの話
108:デフォルトの名無しさん
06/04/14 08:27:37
>>107
本質的には同じなんだけどな
109:デフォルトの名無しさん
06/04/14 08:32:24
二回走査しなければいけない原因を分析
アルゴリズムの問題
構造の問題
一回走査で代替するにはどう走査すべきか
新しい手法はどのパターンを適用できるか（できなくても問題ない。銀の弾ではない）
と手順踏めば良いだけのこと
いきなりパターンに解を求めるのは違うよ
110:デフォルトの名無しさん
06/04/14 08:36:45
>>109
108じゃないけど本質的には同じじゃないか ＾＾；
111:デフォルトの名無しさん
06/04/14 08:43:37
本質は同じだけど、視野が狭くなるでしょ
元の課題の本質が理解できていない人がとるべき行動ではない
112:デフォルトの名無しさん
06/04/14 08:53:08
>>111
そりゃそうだ
113:デフォルトの名無しさん
06/04/17 08:55:15
まあ、そんなこと言ってると、このスレの視野が狭くなって話題が無くなるけどな
いいじゃん本質は似たようなもんなんだから。そこからパターンの話が広がってくかも試練氏。
114:デフォルトの名無しさん
06/04/18 11:22:22
そろそろJ2EE5.0パターンとか出てこないものか…と思う。
115:デフォルトの名無しさん
06/05/08 14:39:08
シングルトンのgetInstanceに引数があるのはおかしいでしょうか。
ファイルを複数管理するクラスで、
アプリ起動時に必要なファイルを読み込み、
メソッドに応じて読み込んだファイルの内容を返すという処理をさせます。
初期化の段階でファイルのルートパスが必要になるので
getInstance(String path)のようなパターンをオーバーロードしようと思っています。
getInstance(String path)はアプリの初期化処理内で1度だけ呼び出し、
ほかはgetInstance()を呼び出すようにしようと考えています。
116:デフォルトの名無しさん
06/05/08 16:03:28
>>115
シングルトンって言われると違和感が多少あるけど、処理自体は変じゃないと思いますよ。
117:デフォルトの名無しさん
06/05/08 18:56:14
>>115
オレなら初期化用のメソッドを作るかな。
118:デフォルトの名無しさん
06/05/08 23:54:26
>115
getInstance(String) の呼び出しを
一回に限定しないとならんわけだけど
それはどのように実現するつもり？
ファイルパスだけでいいのなら、
プロパティファイルなりで指定して
静的初期化ブロックで処理してしまえば良いのでは。
(javaじゃないなら環境変数などで渡す)
119:デフォルトの名無しさん
06/05/09 09:53:43
そんなかんじでよさげ。
ハッシュ（マップ）みたいなものにファイルパスをキーにして
自分のインスタンスを複数保持すればいいんでね？
ハッシュから取り出せなかったら場合に、同期で初期化すればよいかと。
120:デフォルトの名無しさん
06/05/09 11:12:06
>>116-119
お忙しい中、良レスありがとうございます。
今まではプロパティファイルに絶対パスを指定しておいて初期化メソッドの中で読み込むようなことをしていました。
Webアプリだと環境によってデプロイされる場所が変わってしまい、環境毎にプロパティファイルを設定するのがたいへんでした。
ファイル自体はWEB-INF/fileの位置においてあるので
ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。
121:デフォルトの名無しさん
06/05/09 15:21:04
デザパタとは外れますが
＞環境毎にプロパティファイルを設定するのがたいへんでした。
war作るたびに設定編集するのは大変なんで
・環境の数だけ設定ファイルディレクトリ作成
・環境依存の設定ファイルを全てぶちこむ
・環境の数だけwar作成
・warを作成する時には環境に適した設定ファイルを使用する
・warの作成は設定の選択も含めてantで行う。
にしてみてはどうでしょうか。
122:デフォルトの名無しさん
06/05/09 16:35:08
>ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。
個人的には
・クラスパス直下に、設定ファイルへのパス一覧を記述した.propertiesファイルを置く。
もしくは
・web.xmlに設定ファイルへパス一覧を記述する。
が好き。
コードがすっきりするよ。
123:デフォルトの名無しさん
06/06/04 02:34:27
デザインパターン勉強してるんですけど。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
ここのStateパターンがいまいち理解できません。
if文なんか使いませんと書いてますけど、currentStateを変えるには
結局ifなりswitchなりが必要に思えるんですけど…
どうか教えて下さい！
124:デフォルトの名無しさん
06/06/04 02:49:21
if文はあんまりつかいません
と言い換えればOK？
説明文で躓いてるならそれで十分だけど
内容で躓いてるなら
「状態を変更するif文は必要」
「状態を判断するif文は不要」
と考えれば少しは納得いくかも
125:デフォルトの名無しさん
06/06/04 03:12:51
switch(状態){
case 朝:
currentState = mornig;
break;
case 昼:
currentState = day;
break;
case 夜:
currentState = night;
break;
}
currentState.showMessage();
こうしか思いつかないんですけど、なにか根本的に間違ってますか？
126:デフォルトの名無しさん
06/06/04 03:18:07
>>123
意味的な話をすると、State パターンってのは、表示メソッドが showMessage01 ～ showMessage03 まであったときに、
showMessage01──┐ showMessage02──┐ showMessage03──┐
│ 朝表示するメッセージ │ │ 朝表示するメッセージ │ │ 朝表示するメッセージ │
│ 夜表示するメッセージ │ │ 昼表示するメッセージ │ │ 昼表示するメッセージ │
│ 夜表示するメッセージ │ │ 夜表示するメッセージ │ │ 夜表示するメッセージ │
└─────┘ └─────┘ └─────┘
と
朝表示するメッセージ─┐ 夜表示するメッセージ─┐ 夜表示するメッセージ─┐
│ showMessage01 │ │ showMessage01 │ │ showMessage01 │
│ showMessage02 │ │ showMessage02 │ │ showMessage02 │
│ showMessage03 │ │ showMessage03 │ │ showMessage03 │
└─────┘ └─────┘ └─────┘
のどっちが使いやすいかーって話にも関連してくる。ちなみに下が State パターン
127:デフォルトの名無しさん
06/06/04 03:19:31
>>125
違う違う。状態は予めセットしておくの。
んで showMessage したいときに currentState.showMessage()
128:123
06/06/04 03:33:02
>>126
なんとなくわかりますが…
>>127
その状態はいつセットするんですか？
123のサイトの説明ではさっぱり。
currentStateには状態がかわった時にmornigなりdayなりがはいるんですよね？
実装がわからないです。
バカでもうしわけないです。
129:デフォルトの名無しさん
06/06/04 03:46:21
>>128
いつセットするか……。
少なくとも showMessage の直前までには正しい状態がセットされてる必要があるね。
逆に考えると、『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
ってのも、メリットの１つじゃないかと。
130:デフォルトの名無しさん
06/06/04 03:46:30
状態は変わったときだから
その場合は時間が経過した時になるかな？
showMessage()しかないから利点が見え難いかもしれない
朝・昼・夜にできることがshowMessage以外にも10種類あって
Timerで時間がたったときに状態を変更すると考えるといいかも
すると状態変更はTimerの監視部分だけになって
あとはstateを呼ぶだけで勝手に動作が切り替わる
131:デフォルトの名無しさん
06/06/04 03:49:00
『状態がセット』 というより、『状態を判断するタイミング』 って言ったほうが良いかな。
タイミングってのは、コード上の箇所も含むよ。
先に状態を判断しておいて、後からその状態に従った動作を行わせるってのも State パターンで行えるし。
132:123
06/06/04 03:56:15
うーん、いまいちよくわからないですね。
朝.showMessage();
昼.showMessage();
夜.showMessage();
の３つのメソッドを作って状態みてどれかのメソッドを呼び出す。
このやり方とサイトの説明の差は>>129さんの
『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
しかないように思えます。
今日はもう寝ます。明日また考えたいと思います。
みなさんありがとうございました。
133:123
06/06/04 03:58:09
>>130さんのがなんとなくわかるかも…
明日その辺も考えてみます。
134:デフォルトの名無しさん
06/06/04 04:13:05
>>132
ちなみに、こういうメリットもある。
State パターンってのは、『状態』 と 『その状態のときに行う動作』 を ”１つに” まとめておくから、 (>>126)
currentState.showMessage() するときには、currentState に何がセットされてて、どういう動作を行うのか考える必要はないんよ。
ただ showMessage() すれば、その状態に合った動作が行えるってことは保障されてる。
だから、勝手に MyState のサブクラスを自作して、それを currentState にセットしても動くかもね。
135:デフォルトの名無しさん
06/06/04 20:30:10
たとえば後からStateに夕方を追加したくなったとすると
Stateを使わない方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．showMessageの中のifやswitchに夕方の場合を追加
showMessage以外にも似たメソッドがあったらそれら全ての中のswitch文を更新しなきゃならん。
つまり２の作業があちこちに散らばっていて見落としが起こりがちだし
ちょっと間違えると既存の朝昼夜の動作にもに影響が出かねない。
Stateクラスとしてまとまっている方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．夕方クラスを追加
クラスを増やすぶん、追加すべきコード量自体はむしろStateを使わない場合より多くなりそうだが
２の作業については変更箇所が新規クラスの追加という形で一箇所にまとまっているため
既存の朝昼夜は基本的に触らなくてすむ。
136:135
06/06/04 21:22:31
補足。
状態ではなくメソッドのほうを増やしたくなったとき
Stateを使う場合では朝、昼、夜クラスのメソッドをそれぞれ追加する必要がある。
状態の種別のほうが追加や変更を受けることが多そうならStateを使うといい。
137:123
06/06/05 11:43:58
いろいろと説明ありがとうございます。
・朝、昼、夜の状態で行いたい処理が複数ある場合はStateパターンを使う意味がある。
朝、昼、夜クラスとそれらを使うクラスの４つ
夕方が増えた場合の変更箇所 夕方クラス追加。使うクラスの分岐追加の２箇所。
・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
（状態が増える可能性はあるが処理が増える可能性はない。）
朝、昼、夜のshowMessage()メソッド３つ。
スイッチで各showMessage()をよびだす。
夕方が増えた場合の変更箇所 夕方メソッドの追加、スイッチの分岐追加の２箇所。
とゆう認識でよろしいでしょうか？
でもまだ疑問が。
いろいろサイトをみてまわったんだけど、ほとんどの所でStateパターンはifは使わないと書いてます。
でも今までのやり方だと状態を変える時結局ifが必要で、
ただのポリモルフィズムの説明に思えるんですが…
138:デフォルトの名無しさん
06/06/05 12:01:57
>>137
＞・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
割とそうではない場合も。このあたりはケースバイケース。
＞でも今までのやり方だと状態を変える時結局ifが必要で、
>>124
＞ただのポリモルフィズムの説明に思えるんですが…
認識としては全く正しい。多態を使用して、”オブジェクトで状態を表す”のが State パターン
139:デフォルトの名無しさん
06/06/05 13:04:39
>>137
１．状態を変えるための判断としてのif
２．（今現在の）状態を判断するためのif
がごっちゃになってない？
Stateパターンだとifは使わないというのはおそらく後者のほうかと
前者はどうしようもないよね。
140:123
06/06/05 13:35:35
りょうかいです。
すっきりすることができました。これでやっと次に進めます。
ありがとうございました。
141:デフォルトの名無しさん
06/06/06 00:53:15
>>135
コード量では後者の方がむしろ追加分量が増えるという所が何とも吐き気がするんだが…ｗ
142:デフォルトの名無しさん
06/06/06 22:10:57
インデントとか改行みたいなもんだよ
コードの見通しを良くするために使う。
また、見通しが良くならないのであれば使うべきではない。
143:デフォルトの名無しさん
06/06/06 22:18:34
一番大事なことは
状態のような概念をオブジェクトとして扱うという考え方
なんじゃないかと思う
144:デフォルトの名無しさん
06/06/07 10:04:36
一昔前はオブジェクト＝モノ。
モノに操作を与える＝クラス。
だったすからねえ。
ていうかオブジェクト指向のオブジェクトって言葉が
もう時代にそぐわない気すらするですよ。
145:デフォルトの名無しさん
06/06/07 10:30:27
エンティティのほうがまだまし？DBのほうで既成の用語なんで使いづらいけど
146:デフォルトの名無しさん
06/06/28 20:36:15
この調子で幸せになれる議論をお願いします
147:デフォルトの名無しさん
06/06/28 21:52:49
しかしやっぱ、そんなに議論する内容ってないよねこのスレ。
148:デフォルトの名無しさん
06/07/07 23:17:05
commandパターンとstateパターンの違いがよく分からん。
commandパターンは、命令をクラス化して、その派生クラス
のexecute()を呼んで処理させる。
stateパターンは、状態をクラス化して、その派生クラスの
hogehoge()とか、fugafuga()を呼んで処理させる。
結局、名前が違うだけで考え方は一緒のような気がするんだ
が・・・という俺の愚痴。
149:デフォルトの名無しさん
06/07/07 23:37:55
>>148
Strategy と State と Command は、どれも多態で処理を切り替えてるから、
おそらく知らない人が見れば同じに見えると思う。
ただ、意味的な物は随分異なる。重点はそこかと。
150:デフォルトの名無しさん
06/07/07 23:44:15
そうかそうか。よーくわかったぞ。
151:デフォルトの名無しさん
06/07/08 00:42:23
考え方は一緒だけど、使う箇所が違うってだけで分けられたパターンって結構あるよね。
前々スレあたりでGoFも一部の似たようなパターンは無くすとかいってなかったっけ？
152:デフォルトの名無しさん
06/07/08 01:22:41
>>141
テストケースのコード量も加味して考えるといいのでは。
153:デフォルトの名無しさん
06/07/08 02:29:05
StateとStrategyは構造は同じだけど、意味の区別がやや不明瞭。
Commandは意味も構造も違う。
GoFの原典を読むとそんな感じだな。
154:デフォルトの名無しさん
06/07/08 02:58:41
そんな事いったらChainOfResponsibilityだってたんなるtree構造じゃん
155:デフォルトの名無しさん
06/07/08 03:20:10
そうか。なるほど。うん。お前の言いたい事はよくわかったぞ。
156:デフォルトの名無しさん
06/07/08 04:29:30
何がtree構造だ？馬鹿。
157:デフォルトの名無しさん
06/07/08 19:50:03
どうやるとこのスレ盛り上がるのかな。
158:デフォルトの名無しさん
06/07/08 22:03:22
なるほど。GoF信奉者は馬鹿ばっかりだという事がよくわかったぞ。
159:デフォルトの名無しさん
06/07/08 22:04:42
ごめん。
オレが。
フェブってた。
160:デフォルトの名無しさん
06/07/10 23:17:09
フェブってたという言葉がググレません。
トミーフェブラリーのことかー！
161:デフォルトの名無しさん
06/07/10 23:24:07
ファブってたのtypoじゃないか
162:デフォルトの名無しさん
06/07/10 23:30:05
ファブリーズのことかー！
それは言うならファビョるじゃないかな、たしか。
163:デフォルトの名無しさん
06/07/10 23:31:22
>>162
残念、そこは落とすところだ
164:デフォルトの名無しさん
06/10/21 01:39:05
現在ゲームをつくっていてどういうパターンを使えばいいか悩んでいます
アドバイスをお願いします。
空で変な生き物（まある種の鳥）が動き回るという部分を作っているのですが、
ここで鳥Aと鳥Bはお互いに相手の位置を参照して動きを決めます。
そのため、
空Skyのオブジェクトが鳥A,鳥Bへのオブジェクト参照していて、
同時に鳥Aと鳥BもSkyオブジェクトを参照するというデータ構造にしています。
このようなものを実装するのに適したデザインパターンを教えてください。
165:デフォルトの名無しさん
06/10/21 01:40:01
age
166:デフォルトの名無しさん
06/10/21 03:09:11
>>164
あえて言うなら Mediator
167:デフォルトの名無しさん
06/11/01 21:48:53
>>164
表示という親クラスを作って
空、鳥Ａ、鳥Ｂをそのメンバにする。
鳥Ａと鳥Ｂの相互作用が絶対に必要なら
Birdsという鳥全体の動きを仕切るクラスを作って、
そこに鳥Ａと鳥Ｂを入れる。
168:デフォルトの名無しさん
06/11/03 19:06:17
>>164
Observer
はどうでしょう。
鳥Aは鳥Bの位置を監視し、その値がかわったら、自分（鳥A）の座標をupdateする。
鳥Bも同様。
169:デフォルトの名無しさん
06/11/03 19:11:56
>>168
無限ループに突入しないようにしないとな
170:デフォルトの名無しさん
06/11/17 12:34:28
まだ結城本読了＆自分のプログラムにいくつか採り入れる
っていうレベルで、まだGoFのカタログ読んでないです。
結城本のBridgeの「関連しているパターン」に
AbstractFactoryが載ってるんですけど
引用：
Bridgeパターンに登場するConcreteImplementor役を
環境にあわせて適切に構築するために、
AbstractFactoryパターンが用いられる場合があります
Implementorが「抽象的な工場」、ConcreteImplementorが「具体的な工場」
なのか
ConcreteImplementorが「抽象的な工場」で、それを継承して「具体的な工場」
なのか
状況次第なんですかね？
そろそろGoF読まなきゃと思いつつ、なかなかとっつきにくい
171:デフォルトの名無しさん
06/11/17 23:07:26
そもそも
>Bridgeパターンに登場するConcreteImplementor役を
>環境にあわせて適切に構築するために、
構築されるものが ConcreteImplementor なんじゃないの？
172:デフォルトの名無しさん
06/11/21 10:07:44
>>171
BridgeパターンのConcreteImplementorが
AbstractFactoryの「抽象的な工場(AbstractFactgory)」を構築するのか
「具体的な工場(ConcreteFactory)」を構築するのか
ということがわからんのです(；´Д`)
173:デフォルトの名無しさん
06/11/21 21:52:55
>>172
AbstractFactory パターンを使って、ConcreteImplementor を作る、
だと思うよ。クラス図を書けばすっきりする予感。
174:デフォルトの名無しさん
06/11/22 01:34:32
>>173
なるほど、そういうことだったんですか。。。
やっと頭の中でクラス図がぼんやりできてきました。
デザパタを教条的に使うだけじゃ、いかんですな。＜自分
ありがとうございます
175:デフォルトの名無しさん
06/11/24 16:24:47
URLﾘﾝｸ(www.01-tec.com)
これってふつうに
class Apple
{
public:
void NamePuts()
{
puts( "りんご" ) ;
}
void ColorPuts()()
{
puts( "赤" ) ;
}
} ;
class Banana
{
public:
void NamePuts()
{
puts( "バナナ" ) ;
}
void ColorPuts()()
{
puts( "黄" ) ;
}
} ;
って書き換えればいいのでは？
176:デフォルトの名無しさん
06/11/24 16:39:37
>>175
書き換えられなかったらどうするのか、って話だ。
177:デフォルトの名無しさん
06/11/27 16:52:58
>>175の天才ぶりにびびった。
178:デフォルトの名無しさん
06/11/28 00:49:44
void ColorPuts()()
179:デフォルトの名無しさん
06/11/28 10:45:59
>>175
あなた程の天才がなぜこんなスレを見てるのですか
180:デフォルトの名無しさん
06/11/28 11:56:28
Adaptor - 貴方は委譲しますか？継承しますか？
漏れは原則委譲派
181:デフォルトの名無しさん
06/11/28 20:42:59
>>180
case by case だけど、俺は継承だな……
182:デフォルトの名無しさん
06/11/28 23:47:27
委譲(包含+転送)しか使ったことないです。
継承の方が優れてるケースってどんな時でしょうか。
基本的に adapter is a adaptee な状態にはならんので
継承使おうと言う気が起きないです。
183:181
06/11/29 01:17:07
あ、ごめん。普通に勘違いした。委譲だ委譲。
よく考えなくとも Adapter クラスを継承することは大前提なんだよな。
すまね orz
184:デフォルトの名無しさん
06/12/11 04:55:44
結局継承によるアダプターは誰も実践してない罠。
でもアダプターパターンの解説見てると
継承による方法が先の場合が多いのはなぜなんだぜ。
185:デフォルトの名無しさん
06/12/11 09:15:54
委譲よりも継承の方が、初心者にはOOっぽく見えるんだぜ？
186:デフォルトの名無しさん
06/12/11 23:52:47
継承による場合は override によって処理を上書きすることで
完全にコントロール出来ることが利点だと説明するサイトがあったが
コントロールしちゃったらアダプタでもなんでもないと思った。
187:デフォルトの名無しさん
06/12/28 20:59:47
質問なんですが、ファクトリパターンってインスタンスが一つあればいいってのはわかるんですが、
メソッドをstaticじゃなくて、シングルトンパターンにする必要があるのですか？
どうせなら、インスタンス作らないで、staticメソッドにしてアクセスした方がいい気がするのですが
インスタンスを生成するかstaticにアクセスするかどちらの方がいいのですか？
188:デフォルトの名無しさん
06/12/29 00:06:43
一概には言えまい
staticにしてしまうとファクトリ事態を抽象化することが出来んからな
189:デフォルトの名無しさん
06/12/29 00:46:41
>>188
なるほど
190:デフォルトの名無しさん
06/12/29 00:52:45
>>182
adapter has a adaptee？
191:デフォルトの名無しさん
06/12/29 00:58:56
client → Target
△
|
Adapter→Adaptee
TargetはClientに対するInterfaceだからAdapterがTargetを継承するのは当然なのでは？
AdapterはAdapteeに委譲するのは当然だし
192:デフォルトの名無しさん
06/12/29 06:29:05
>>191
当然だと思う。
でも世のデザパタ解説サイトだと
「継承」「委譲」の2種類を例として出してる場合、
「継承」ではTargetはクラス、Adapterはそれを継承する形になってて
「委譲」ではTargetはインターフェース、Adapterはそれを実装する形になってる。
本質を考えれば継承の場合でもTargetはインターフェースだろ？と思うんだけど。
(というか継承はいらねえと思われ。)
オリジナルのGoF本を読んでないので分からんけど。
193:デフォルトの名無しさん
06/12/29 08:14:40
>>192
クラスでもいいのでは？
Targetとしての振る舞いに共通なものがあるのだとしたら
抽象クラスとする事もアリだと思うけど
Client → Target
△
;
AbstractTarget
△
|
Adaptar → Adaptee
194:デフォルトの名無しさん
06/12/29 08:29:13
まあ、↑みたいにするAdapterパターンの説明としては複雑になるから
省略してTargetをクラスにしてるんだと思うけど
195:デフォルトの名無しさん
06/12/29 09:00:04
クラスが悪いとかクラスじゃできないとか言ってるんじゃなくて。
Client からは統一的に扱える、同じように見えるって側面を強調するなら
インターフェースでいいじゃねえかと。
委譲のパターンでもTargetはインターフェースで説明できるのに
そっちの方がより無駄のない本質的な説明になるのに、
なんでクラスなの？と。
(>>192では委譲・継承とクラス・インターフェースの組み合わせが逆だった。)
↓これが一般例で、他はもう特殊例でしょ？
<<interface>>
client → Target <|・・・・・Adapter ・・・・・|> Adaptee
implements uses
ひどいところでは
継承使うパターンがデフォですよ、
単一継承でいかんともしがたい時には
委譲使うパターンで回避ですよ、
に近い説明すら行ってる。
なんかもうコードが共有されるなら継承が最高の解なんだよ、みたいな。
それは15年前に通ってきた道だろう、と。
196:デフォルトの名無しさん
06/12/29 09:07:58
それをいったらデザインパターン自体が出てからだいぶ時間がたってるから
当時の説明をそのまま鵜呑みにしてもしょうがないでしょ。
もし初心者がそれ見て今の時代にアンマッチな知識をインプットしてしまう
事に懸念を感じるなら、自分で「こう解釈するのがいいですよ」って説明する
サイトでも立ち上げてみればいいｗ
197:デフォルトの名無しさん
06/12/29 09:14:16
>>195
＞↓これが一般例で、他はもう特殊例でしょ？
それは少し乱暴だと思うが・・・・・
そう熱くなるなよｗ
198:デフォルトの名無しさん
06/12/29 16:58:29
>>195
っていうか、「委譲」って言葉の使い方間違ってね？
199:デフォルトの名無しさん
06/12/29 21:21:49
Effective C++ みたいに、時代に合わせて新しくなるデザパタ本があればいいのにな。
200:デフォルトの名無しさん
06/12/29 22:04:55
GoFのデザインパターンは、モデリングの世界の"Hello World"
見たいな物になってしまったンだと思うね
201:デフォルトの名無しさん
07/01/02 19:42:57
ほす
202:デフォルトの名無しさん
07/01/02 20:07:12
「それはパターンから外れているから駄目だ」とかは全然駄目なセリフの例ですね
203:デフォルトの名無しさん
07/01/04 23:41:05
ほす
204:デフォルトの名無しさん
07/01/13 13:53:11
いまさらデザインパターンを語ることはあるまい
205:デフォルトの名無しさん
07/01/13 15:24:09
デザインパターンってもう語りつくされたん？
206:デフォルトの名無しさん
07/01/13 15:36:31
語れるほど言葉を持たないというのが正確なところかｗ
207:デフォルトの名無しさん
07/01/18 18:06:31
これはよく使うパターンって何？
208:デフォルトの名無しさん
07/01/19 03:12:29
Iterator
209:デフォルトの名無しさん
07/01/19 07:26:27
Singleton、Factory、Template あたりかなぁ。
210:デフォルトの名無しさん
07/01/19 23:45:02
こんぽじっと
211:デフォルトの名無しさん
07/01/19 23:47:05
こーるばっく、こまんど、
212:デフォルトの名無しさん
07/01/20 01:28:34
微細主義，機能分割，集団無能化・・・
213:デフォルトの名無しさん
07/02/10 20:34:33
結城さんのMLってどうやって送信先メールアドレスを変えるんだ？
進級２つ登録したから古い方だけ購読解除できればいいんだが
まぁ４月になればアドレスが使えなくなるから放置でもいいんだけど
214:デフォルトの名無しさん
07/02/10 22:10:48
>>213
それって面白い？
215:デフォルトの名無しさん
07/02/11 01:12:50
NullObjectのような、GoFの23には含まれていないパターンについて勉強したいのですが、
みなさんはどのように勉強されましたか？
個人的には本で勉強したいので、参考になる書籍などを示してほしいです。
216:デフォルトの名無しさん
07/02/12 19:33:51
age
217:デフォルトの名無しさん
07/02/12 19:38:25
boostのコードを読むと、すごい勉強になった
218:デフォルトの名無しさん
07/02/12 20:29:48
>>217
kwsk
219:デフォルトの名無しさん
07/02/12 20:55:12
デザインパターンを勉強すると、
自分が頭良くなってスゴイSEなったってカン違いするヤツ、
多いよな・・・
220:デフォルトの名無しさん
07/02/12 20:59:00
一人前のSEって感じでしょ
221:デフォルトの名無しさん
07/02/13 11:29:01
GOFデザインパターンはマイクロアーキテクチャーの一種に分類され、
その対象領域は一般にプログラムと呼ばれている、いわゆる動作単位であるから、
どの様に考えてもプログラマの職域に属する事項であるかと
222:デフォルトの名無しさん
07/02/13 23:23:41
>>221
「マイクロアーキテクチャー」って一体何の事だか、
分かっている？
223:デフォルトの名無しさん
07/02/13 23:58:25
SEではないな
224:デフォルトの名無しさん
07/02/14 08:14:40
半導体設計が思い浮かんだ。
225:デフォルトの名無しさん
07/02/19 23:50:05
>>219
結局デザインパターンって、フレームワーク作る時にしかあんまし使わないかなあ
226:デフォルトの名無しさん
07/02/19 23:54:41
勉強が足らんな
227:デフォルトの名無しさん
07/02/20 00:13:46
>>226
kwsk
228:デフォルトの名無しさん
07/02/20 00:24:41
フレームワーク使う側でも使う。
java.lan.io.* なんてデコレータパターンの塊だし
コレクションフレームワークはそのままイテレータパターンの実装だし。
フレームワークが面倒見てくれない粒度の細かいオブジェクトの組み立てには
それはもうファクトリやらテンプレートやらのオンパレードさ。
229:デフォルトの名無しさん
07/02/20 00:33:57
>>228
ｉｏ自身がデコレータでしょ
使ってる側は意識しないはず
イテレータは素人でも使うよ
230:デフォルトの名無しさん
07/02/20 00:43:25
イテこまし…いやなんでもない
231:デフォルトの名無しさん
07/02/20 05:36:30
つーか、あるものを利用するだけで自分では使わないんだｗ
232:デフォルトの名無しさん
07/02/20 15:50:13
プログラマなんてみんなあるものを利用するだけでしょ
アセンブラでもマシン語でも。
233:デフォルトの名無しさん
07/02/20 23:18:29
いんや
234:デフォルトの名無しさん
07/02/22 13:22:45
ｺﾞﾌ！
235:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/24 19:14:56
他のクラス ─→ AIクラス
△
┌──┼──┐
│ │ │
タイプA タイプB タイプC
だろ普通
237:デフォルトの名無しさん
07/02/24 19:17:20
>>235
＞キャラクタークラスは内部にAI処理を担当するクラスZをコンポジションでもっていたとします
これ、Composition とは言わないだろう……
＞AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジション
だから、Composition じゃなくて Strategy
＞からそのキャラクターのAIの動作を変更するために
今度は State？
＞にもそれに応じたメンバ関数を
どういうメンバ関数？ それほど増えるとも思えないが。
＞もっとスマートなやり方は無いものでしょうか？
無い。これが上限であり下限。
割りきりが必要。極端に変な動作はさせないほうが吉。
238:デフォルトの名無しさん
07/02/24 19:48:00
ｴｴェェェ・・・？
239:デフォルトの名無しさん
07/02/24 22:40:37
>>235
他のクラスオブジェクトへの参照を持つ事をコンポジションというのではないのですか？
ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、
いっそZへの参照を利用側に渡してしまおうかと思ったのですが、内部のオブジェクトの参照を
外部に渡してしまうのは好ましくないようなので、どうしようかと思ったのです。
Zのメンバ関数のいくつかは、キャラクタクラス以外のクラスから呼んで欲しくないものがあるので・・・。
240:デフォルトの名無しさん
07/02/24 22:48:58
書き間違えました。
誤：ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、
正：キャラクタークラスにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、
です。
241:デフォルトの名無しさん
07/02/24 23:35:06
>>240
ABCがAIだろうがキャラクターだろうが同じじゃハゲ
242:デフォルトの名無しさん
07/02/24 23:44:26
┌─→AIクラス
│ ◇
他のクラス ─┤ │
│ ↓ ┌→キャラクターA
├─→キャラクター ＜|───┼→キャラクターB
│ └→キャラクたーC
│ ┌→キャラクターA用のセッター
└─→プロパティセッター＜|──┼→キャラクターB
└→キャラクターA用のセッター
243:デフォルトの名無しさん
07/02/24 23:45:17
まちがいたｗ
┌─→AIクラス
│ ◇
他のクラス ─┤ │
│ ↓ ┌→キャラクターA
├─→キャラクター ＜|───┼→キャラクターB
│ └→キャラクたーC
│ ┌→キャラクターA用のセッター
└─→プロパティセッター＜|──┼→キャラクターB用のセッター
└→キャラクターC用のセッター
244:デフォルトの名無しさん
07/02/24 23:49:25
Javaで書くとこんな感じ
AICharactor iaChar = ai.getCharactor();
PropertySetter setter = PropertySetterFacotory.getSetter(aiChar);
setter.set(iaChar,otherObject);
245:デフォルトの名無しさん
07/02/24 23:53:52
プロパティじゃなくてパラメータだなｗ
246:デフォルトの名無しさん
07/02/25 03:01:46
>>235
そういうときこそ継承使えばいいじゃない
247:デフォルトの名無しさん
07/02/25 11:37:58
全 AI が必要とするパラメータを一つの巨大なクラスに集めて、それを渡すことにするとか。
各 AI はそのオブジェクトを一つ受け取って、自分に関係するメンバだけ触ることにすれば、インターフェイスは共通化できる。
AI が増えても、そのクラスにメンバを増やすだけで、他は一切書き換えずに済む。
再コンパイルは必要だろうけど。
248:デフォルトの名無しさん
07/02/25 15:49:22
みなさん、ありがとうございます。
>>247
その方法も考えていました。なんかオブジェクト指向的に完璧な解決策じゃない
気がしていたんですが、それが一番手っ取り早いのかもしれませんね。
249:デフォルトの名無しさん
07/02/25 16:03:31
・・・・・・・・
250:デフォルトの名無しさん
07/02/25 18:16:05
パラメータをいじる権利のある人がAIを生成して
もしも途中でパラメータを変更する必要があるならそのままそいつが参照を持ちつづけ
キャラクタは自分が生成されるときにAIへの参照を貰い受けるような形のほうがいいと思う
パラメータを設定できないtickするだけのインターフェイスで貰えるならなお結構
251:デフォルトの名無しさん
07/02/25 23:45:05
>>235
なんかよくわからんけど、直感的にBridgeパターンが頭に浮かんだ。違うかな。
252:デフォルトの名無しさん
07/02/25 23:59:31
オブジェクト指向ってホントウに垣根が高いんだな・・・・
253:デフォルトの名無しさん
07/02/26 01:18:21
たぶんずれると思うけど。
・ゲーム進行はキャラとAiBuilderを知ってる。キャラへAiをセットする
・キャラはAIだけ知ってる
・AiとABCTypeはAiBuilderによって生成される
ゲーム進行 ----> AiBuilder-------
↓ ↓ |
キャラクタ ----> <Interface>Ai |
△ |
| ↓
AType BType CType
254:デフォルトの名無しさん
07/02/26 01:20:08
ずれすぎてだめだった。
ABCはAiのサブクラスね。
255:デフォルトの名無しさん
07/02/26 09:15:43
全角スペースを使い玉へ
半角スペースは続けて使うと一つにまとめられちゃうのだ
256:デフォルトの名無しさん
07/02/26 10:19:21
テスト
あああ
257:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/27 00:52:10
>>256
これは専ブラが半角スペースをユニコードに変換するタイプなんでおｋなんだよ
259:デフォルトの名無しさん
07/02/27 09:53:49
キャラクターなんていうデカイ括りがなんで必要なのかわからん
まずキャラクターありきでデザインするのよそうよ
260:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/02 23:54:31
最近はaspectあるからVisitor要らなくね？
262:デフォルトの名無しさん
07/03/03 00:40:04
なわけないだろ。
aspectとかＤＩって害虫だろ。
そんな迷走してるより、
とっととクロージャ取り入れて、正常進化して欲しい。
263:デフォルトの名無しさん
07/03/03 00:47:05
なわけないだろ。aspectとDIは本流だろ。
264:デフォルトの名無しさん
07/03/03 03:17:43
AOP&DIの文脈でクロージャの話が出る理由が分からん。
265:デフォルトの名無しさん
07/03/03 07:14:09
それが正常進化とも思えん
266:デフォルトの名無しさん
07/03/03 09:17:01
クロージャはＤにもあるし、Javaにもいずれ実装されるからだろ。
267:デフォルトの名無しさん
07/03/03 15:14:26
Javasist 系は、VM が後方互換のないバージョンアップをしたとき、
手の打ちようがないよな。
Aspect がうまい具合に言語仕様に入るなんてこともなさそうだしな。
268:デフォルトの名無しさん
07/03/04 15:52:16
ランタイムでウィービングすりゃいいじゃん。
269:デフォルトの名無しさん
07/03/14 21:49:37
２ちゃんで煽りながらデザパタ学習した池沼が
古い話題を壊れたレコードのように繰り返すスレ
270:デフォルトの名無しさん
07/03/14 22:07:11
ま
敢えて言うほどの事でもないがの
271:269
07/03/14 22:13:31
こんなスレ未だに見てる奴が居る事実に感動
元お豆のｓずきさんかな
272:デフォルトの名無しさん
07/03/16 02:19:28
たかひろくんのデザパタ幼稚園
273:デフォルトの名無しさん
07/03/16 10:43:46
>>33の発言は間違い。
274:デフォルトの名無しさん
07/03/21 09:22:19
ごふっ
275:デフォルトの名無しさん
07/03/26 17:59:37
質問です。
テンプレートメソッドパターンを適用しようとして気になったのですが、
ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう？
（内容が同じになるものが複数組あります）
内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、
このままでは冗長です。
ぱっと思いつくのは、組ごとに共通のクラスを作っておいて
各コンクリートクラスは共通クラスのただのラッパーになる、という設計ですがおかしいでしょうか？
使っているのはPHP5なので多重継承はできません。
276:デフォルトの名無しさん
07/03/26 18:21:23
age!
277:デフォルトの名無しさん
07/03/26 19:05:42
ConcreteClassのユーザーから見て、
その「処理が同一だけど異なるクラス」とやらは
「全く同じクラス」にしてはいけないものなの？
278:275
07/03/26 19:18:30
微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。
例えば、
URLﾘﾝｸ(www.techscore.com)
ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に
public class TanakasWoodCutPrint extends WoodCutPrint{}
と
public class SuzukisWoodCutPrint extends WoodCutPrint{}
の二つが同じ内容になってしまう、という場合にどうすれば良いのか？という事です。
279:デフォルトの名無しさん
07/03/26 22:00:25
木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？
280:デフォルトの名無しさん
07/03/26 22:44:58
差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。
もう一階層挟んだら綺麗にまとまったりしないかとか。
281:デフォルトの名無しさん
07/03/26 23:44:55
メモリが必要になったときに一度だけ生成されて、それ以降の記述では
必ず最初に確保されたメモリが使われるようなパターンは何というの？
C++風に描けば
if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る
aを使った処理…
全部グローバル変数にすればいいんだろうけど、使わない領域は
確保したくないって時にやる（a が不要になったときは回収してもOK）
282:デフォルトの名無しさん
07/03/26 23:46:53
>>281
しんぐるとんだろ？
283:デフォルトの名無しさん
07/03/26 23:49:00
>281
Singleton
284:275
07/03/27 12:17:40
>>279
>>275で書いた共通クラスというのはそういうイメージなのですが、
タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？
>>280
symfonyでモデルクラスをＤＢスキーマから自動生成後、
各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。
285:デフォルトの名無しさん
07/03/27 22:52:26
っていうか、そのモデルは何を表してるモデルなのよ？
DBから生成されたものに後付で持たせたい機能って言う意味がわからん
モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな
286:デフォルトの名無しさん
07/03/27 23:18:27
なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。
287:デフォルトの名無しさん
07/03/28 07:29:58
>>280
まず、モデルの定義を明確にしろ。
・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、
・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。
後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。
次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。
版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、
cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。
具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。
ここで、テンプレートパターンを使う。
ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass
ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass
となるようにする。
もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、
同じConcreteStrategyクラスを生成して呼び出せば良い。
違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。
それだけの話ではないか
288:２８７
07/03/28 07:36:24
>>280ではなく>>275
289:デフォルトの名無しさん
07/03/28 10:14:53
symfonyってのをちらっと眺めた感じだと
＞・DBエンティティをそのまま表したクラス(状態)
どうもこっちみたいだから、
そもそも適用するレイヤを間違ってる説が有力。
290:デフォルトの名無しさん
07/03/28 10:51:39
ODBMS屋乙。
> そもそも適用するレイヤを間違ってる説が有力。
それは前提を勝手に仮定した偏った意見に見える。
>>275の話が
・どのようなアプリケーション・アーキテクチャ～レイヤ構成を前提としているか
・一つのレイヤ限定の話なのか
・複数のレイヤにまたがった話なのか
によって、いくらでも回答の仕方があるだろう。
例えば、
下のレイヤで、オブジェクトの静的状態をDBMSに格納し、
上のレイヤで、オブジェクトの振る舞いをどう扱うか
という問題を仮定した場合にも、
・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法
・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態
を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法
の二通りが考えられる。
>>287は、後者の立場から説明した。
291:デフォルトの名無しさん
07/03/28 10:58:15
補足：
前者の立場でも
DBMSエンティティ＝静的状態＝ドメインオブジェクト
と呼ぶことがあるが、
オブジェクト指向本来のドメインオブジェクトは、後者。
292:275
07/03/28 12:42:19
symfonyは一つのテーブルから二つのクラスを生成する。
テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる）
問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。
なのでそのクラスにそのデータを使うメソッドを書こうかと。
今、>>287の方法でやっていますがこれで良さそうです。
ありがとうございました。
293:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/29 00:34:25
×；DrawProcessor drawProcessor = coodinator.getCutProcessor();
○：DrawProcessor drawProcessor = coodinator.getDrawProcessor();
w
295:デフォルトの名無しさん
07/03/29 12:59:19
>>293-294
> public void doWoodCutPrint(){
身元バレバレっすよ兄貴ぃ
閑話休題
他の言語、他のフレームワークを使っている人間に
余計なコメントをつけても混乱するだけだ。
もしアドバイスをつけたいなら、Javaではなく
PHP5+symfonyの例に即したアドバイスをしろ。
例えば、
・ データクラスの生成(検索、保存)
・ データクラスの処理(計算、処理)
はべき乗パターンに則って別クラスにすべきだ、などという説は
そのような冗長な設計が「PHP5＋symfony」に適しているかどうか、
という観点で議論すべきである。
だが、俺はそこまで突っ込むつもりはない。
そんな事をいちいち調べるつもりはないし、
質問者も困惑するだけだからだ。
296:デフォルトの名無しさん
07/03/29 13:11:21
>>293
つか、今気付いた。
おまいは TemplateMethod Patternを共用したい
という質問に対して、全然別の回答をつけている。
特に、クラスの命名がデタラメだ。
×× public WoodCutPrintContext{ ... }
× public class WoodCutPrintContext{ ... }
○ public class WoodCutPrintProcess { ... }
297:デフォルトの名無しさん
07/03/29 14:58:49
----------------------------------------------------------------------------
デザインパターンにおける Contextの用例
1. Interpreterパターン
URLﾘﾝｸ(www.hellohiro.com)
言語に対して、文法表現(Expressionクラス)と、
文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。
(注： Inerpreterクラスは付帯的に、言語の束縛～副作用を表す評価環境(Context)を持つ)
2. Stateパターン
URLﾘﾝｸ(www.hellohiro.com)
オブジェクトの内部状態が変化したときに
オブジェクトの処理内容を変えられるようにする。
(注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
----------------------------------------------------------------------------
>>293のクラス名 WoodCutPrintContext は、
クラスの役割を表現しておらず不適切な命名と言える。
298:デフォルトの名無しさん
07/03/29 15:32:52
----------------------------------------------------------------------------
デザインパターンにおける Contextの用例 【追加と訂正】
2. Stateパターン 【訂正】
× (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
○ (注： ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。 ←【訂正】
個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
3. Strategyパターン 【追加】
URLﾘﾝｸ(www.hellohiro.com)
Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。
それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。
(注： ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。
個々のアルゴリズムは、個別のConcreteStrategyクラス (～A, ～B, ～C)に記述する。
個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。)
----------------------------------------------------------------------------
もしかして >>293は、
鈴木、田中 ＝＝ StrategyパターンのConcreteStrategyクラス、
WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス)
と言いたかったのか？
だが、それでは
・鈴木と田中が同じ手順(Strategy)で版画を彫る
・鈴木が田中の手を借りて版画を彫る
が全く同じ表現になってしまう。これは不適切だ。
299:デフォルトの名無しさん
07/03/29 16:59:49
↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。
「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。
300:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/29 17:44:38
■正しい表現 「鈴木と田中が全く同じやり方で版画を彫る」
public class 鈴木君 {
// 鈴木君には版画を彫るスキルがある。
public WoodCutPrintStrategy getWoodCutPrintStrategy() {
// 鈴木君のスキルは、一般にAと呼ばれるスキルである。
return WoodCutPrintConcreteStrategyA.getInstance();
}
// 版画を彫る
public Hanzai createWoodCutPrint() {
// 鈴木君は自分のスキルで版画を彫り、成果を提出する。
return getWoodCutPrintStrategy().doWoodCutPrint();
}
}
302:デフォルトの名無しさん
07/03/29 18:00:19
>>300
バグを発見しますた。
鈴木君の一人プロジェクトが無限ループを起していて
いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ
/* 「手配師が鈴木君本人しか集められなかった場合」の *
* 等価コード */
public class 鈴木君 { // ConcreteStrategy
// 版画を彫る
public Hanzai createWoodCutPrint() {
// 鈴木君が自分を拉致る
鈴木君 agent = 鈴木君.getInstance();
// 鈴木君はいつものようにメンバーに強制労働をさせて、
// 成果だけ横取りするつもりだったが、
// 結局自分一人では何もできずに
// 貯え(VMスタック)を消費しつくして終了
return agent.createWoodCutPrint(); // 無限ループで throw RuntimeException("スタックオーバフロー")
}
}
303:デフォルトの名無しさん
07/03/29 18:38:56
エロゲで使われているパターン
Singleton
他なんかある？
304:300
07/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:デフォルトの名無しさん
07/03/29 19:46:45
まとめると、
>>275＝>>284の質問(>>292で解決済)
テンプレートメソッドで、処理が同じものがある場合に、
(注： 同じなのは、TemplateMethod単位か、個々のメソッド単位か不明)
どのようなクラス設計をしたら良いか？
>>279-280、>>285-290の回答
TemplateMethod単位で同じものがあったら、
それをStrategyパターンで外出しして共用すれば良い。
※ここまではOK
>>293の回答
TemplateMethodの個々のメソッド単位で同じものがあったら、
それをStrategyパターンで外出しして共用すれば良い。
※>>293の実装コードは
ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割
Coordinatorインタフェースを割り付けている点がおかしい。
鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。
306:305
07/03/29 19:47:36
>>293の実装コードの問題点
分析/設計で得たモデルの特性として、
「手順を構成する複数の工程について、
各工程の処理方法にバリエーションがあり、
なおかつ、各処理方法は互いに交換可能」
な事が明らかならば、>>293の実装もありえる。
しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、
不吉な匂いがする。・・・数100人月のシステムで、
このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。
どのような場合にこの実装/設計が破綻するかと言うと、
設計/初期実装に見落としがあって、
Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合
である。この場合、Hanzaiインタフェースのバリエーションに関して、
各処理方法は互いに交換可能でなくなる。
正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは
なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ～
307:デフォルトの名無しさん
07/03/29 20:14:36
デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。
プロトタイプ作成時は、「版画」は１種類だけ考えれば済むから、
その版画作成に使う版材も、処理手順も、詳細処理方法も１種類ずつで済む。
・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、
開発もバッチグーね？とお気楽モード。
ところが開発展開になってから、
「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、
「異なる版画には、異なるサイズや材質の版材が必要」な事とか
「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」
ってな事にも、おそまきながら気付く。
アーキテクチャ設計ﾊﾀｰﾝｗｗｗｗ
・・・いや、気付いてても気付かないフリしたんだろう、
アーキテクチャ設計のボンクラ共は。
じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・
幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。
その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったｗｗｗ
共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。
それでは、正しい解決方法はどこにあるのか
それを私は知っているが、このレスにはもう余白がないので書けないｗ
308:鈴木
07/03/29 22:31:38
おまいら、俺の名前を気安く使うな、不愉快だぞ
続きは「佐藤クン」で
309:デフォルトの名無しさん
07/03/29 22:37:17
上がダメなら、下の名前ならおｋ？
例えばひろゆきとかゆきひろとかたかゆきとかあと
310:デフォルトの名無しさん
07/03/29 22:49:30
問題はドメイン・モデリングの欠落だなｗ
311:デフォルトの名無しさん
07/03/29 22:55:01
問題領域が「版画作成」なら、最終目的は「版画」だけど、
問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ～よなｗ
つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話
312:デフォルトの名無しさん
07/03/29 22:57:26
「業務処理」の目的は、DB更新と電文(w。
313:デフォルトの名無しさん
07/03/29 22:58:09
>>312
それはありえん
314:鈴木
07/03/29 22:59:24
>>309
それもダメだ、かすってる
鈴木の続きは「都築」でどうだ
315:デフォルトの名無しさん
07/03/29 23:03:13
>>314
じゃニックネームで手を打とうぜ。
例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ
316:デフォルトの名無しさん
07/03/29 23:05:28
>>309、>>315
見事なまでのプロダクトラインだなｗ
317:デフォルトの名無しさん
07/03/29 23:07:17
閑話休題
318:デフォルトの名無しさん
07/03/29 23:10:48
>>312
ある種の基幹系業務システムは、
構築難易度を下げて抽象化すると、
結局、マスタメンテ型アプリに帰着する。
すると、最終目的がマスタ更新ってのも
そんなにずれていない。
するとオブジェクト指向で書く必要ないんだな、これが。
（終了）
319:デフォルトの名無しさん
07/03/29 23:13:24
)再開(
320:デフォルトの名無しさん
07/03/29 23:17:09
GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ
321:デフォルトの名無しさん
07/03/29 23:17:18
ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。
322:デフォルトの名無しさん
07/03/29 23:22:56
>>321
M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。
CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、
所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ）
ちょっと後悔（ｳﾂｳﾂｳﾂｳﾂｼｸｳﾂｳﾂｼｸｼｸｳﾂｳﾂｳﾂｳﾂｳﾂｼｸｼｸｼｸｼｸｳﾂｳﾂｳﾂ
そんな事じゃいかん。俺はCMU/SEIはともかくとして、
日本のCMMI連中とは全然話が合わないんだったｗ
なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆
323:デフォルトの名無しさん
07/03/29 23:29:25
>>322
特に無い。
324:デフォルトの名無しさん
07/03/29 23:38:44
>>320
確かに飽きてきたのも事実
だが使いこなせてる奴が意外と少ないのも事実
325:デフォルトの名無しさん
07/03/29 23:45:29
だが使いこなせてる奴は１０年前から退屈してるのも事実
326:デフォルトの名無しさん
07/03/29 23:49:47
2PLoP (2ch Pattern Language of Programming)報告：
Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、
まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。
彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。
トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、
Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。
ｽﾚﾘﾝｸ(tech板)