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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 05/09 16:29 / Filesize : 193 KB / Number-of Response : 612
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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

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

〔隔離〕デザインパターンは本当に必要か？〔スレ〕
pc8.2ch.net/test/read.cgi/tech/1119348596/
2 名前：デフォルトの名無しさん [2006/03/09(木) 04:34:12 ]: 【神プログラム】
ex14.2ch.net/test/read.cgi/news4vip/1141838441/
にてﾈ申プログラムの実体にせまる！！

>>管理人さんがｽﾊﾟｰﾊｶｰみたいで、画廊のｲﾗｽﾄを無断で持っていくとPCが壊れちゃうらしい。
>>ｺﾜｲﾖｰ(((；･д･)))
>>ttp://tenkai-asyu.net/
3 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 15:27:59 ]: 過去スレ
デザインパターンの単純そうな質問 - (1)
pc5.2ch.net/test/read.cgi/tech/994836140/
【GOF】デザインパターン - (2)
pc5.2ch.net/test/read.cgi/tech/1087050664/
【GoF】デザインパターン 3
pc8.2ch.net/test/read.cgi/tech/1095388499/
【GoF】デザインパターン 4
pc8.2ch.net/test/read.cgi/tech/1116122102/
【GoF】デザインパターン5
pc8.2ch.net/test/read.cgi/tech/1119158274/
〔隔離〕デザインパターンは本当に必要か？〔スレ〕
pc8.2ch.net/test/read.cgi/tech/1119348596/

関連スレ
デザインパターン
piza.2ch.net/tech/kako/976/976074878.html
リファクタリング、させてくれ
pc5.2ch.net/test/read.cgi/tech/1081863662/l50
【XP】Agile Process 第2イテレーション【UP】
pc5.2ch.net/test/read.cgi/tech/1091773629/l50
【綺麗】デザインパターンは美しい！【究極の美】＠プログラマー板
pc5.2ch.net/test/read.cgi/prog/1089077456/l50
4 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 15:28:46 ]: Web Page [ja]
Javaプログラマのためのデザインパターン入門
objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.html
C++で読むデザインパターン
www.01-tec.com/document/cpp_design_pattern.html
Javaなページ
home.catv.ne.jp/dd/chiba/ken/Java/JavaMain.html
デザインパターン入門 (ちとわかりずらい…)
www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html
Inversion of Control コンテナと Dependency Injection パターン
www.kakutani.com/trans/fowler/injection.html
Inversion of Control
wiki.bmedianode.com/Spring/?Inversion+of+Control
デザインパターンF.A.Q.
www.hyuki.com/dp/dpfaq.html
デザインパターンを読み解く
hp.vector.co.jp/authors/VA020635/system/dpattern.html
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm
5 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 15:29:36 ]: Web Page [en]
Patterns Home Page
hillside.net/patterns/
Design pattern (computer science) - Wikipedia, the free encyclopedia
en.wikipedia.org/wiki/Design_pattern_(computer_science)
C#によるデザインパターン
www.dofactory.com/Patterns/Patterns.aspx
6 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 15:30:23 ]: 書籍
オブジェクト指向における再利用のためのデザインパターン
www.amazon.co.jp/exec/obidos/ASIN/4797311126/
増補改訂版Java言語で学ぶデザインパターン入門
www.hyuki.com/dp/index.html
Java言語で学ぶデザインパターン入門マルチスレッド編
www.hyuki.com/dp/dp2.html
独習デザインパターン
www.amazon.co.jp/exec/obidos/ASIN/4798104450/
Javaデザインパターン徹底攻略標準プログラマーズライブラリ
www.amazon.co.jp/exec/obidos/ASIN/4774115797/
デザインパターンによるJava実践プログラミング
www.amazon.co.jp/exec/obidos/ASIN/4756141552/
Java実践プログラムによるデザインパターン入門講座
- Swingプログラムで体得する23のパターン
www.amazon.co.jp/exec/obidos/ASIN/4894712563/
J2EEデザインパターン
www.amazon.co.jp/exec/obidos/ASIN/4873111781/
C#デザインパターン
www.amazon.co.jp/exec/obidos/ASIN/4822281698/
7 名前：3-6 mailto:sage [2006/03/09(木) 16:21:29 ]: ういっす。テンプラ貼って見ました。
まったりと語り合いましょうぜ。
8 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 16:29:42 ]: お姉ちゃん本ってどれ？
9 名前：3-6 mailto:sage [2006/03/09(木) 16:31:58 ]: >>8
俺も気になります。お姉ちゃんの部分が気になります。
10 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 19:48:07 ]: お仕着せのパターンで解決できるものばかりなのかね？
11 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 19:57:21 ]: レゴブロックで作れないものはない
12 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 20:50:32 ]: 23個のオナニーパターン。
13 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 20:58:10 ]: これ↓人気があるみたいだけど。

デザインパターンとともに学ぶオブジェクト指向のこころ
www.amazon.co.jp/exec/obidos/ASIN/4894716844/
14 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 21:33:53 ]: >>8
www.amazon.co.jp/exec/obidos/ASIN/4873112494/

O・O・P！O・O・P！と連呼すると・・・・
15 名前：デフォルトの名無しさん mailto:age [2006/03/12(日) 02:00:17 ]: 結城先生あげ。
16 名前：デフォルトの名無しさん mailto:sage [2006/03/12(日) 02:21:34 ]: GoF本読んでSmalltalk好きになった
といっても、GoF本のサンプルってほとんどC++なんだよね
で、SmalltalkでといえばDesign Patterns Smalltalk Companion
マジおすすめ
17 名前：デフォルトの名無しさん mailto:sage [2006/03/12(日) 13:58:40 ]: >>16
＞GoF本読んでSmalltalk好きになった
おっ、その心は？
Smalltalkって標準クラスの設計がいいの？
18 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 00:52:53 ]: 『･･･こころ』
買っちゃった
♪明日届く～
19 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 02:32:32 ]: >>17
そうね～やっぱクラスライブラリの設計ですね
デザインパターンの固まりって感じなんですよ

Smalltalkを調べていくと、言語仕様が非常にシンプルで
言語で規定されるようなこと（制御文とか）すらクラスに
メソッドで定義されている、ってのにちょっと感動。
20 名前：デフォルトの名無しさん [2006/03/15(水) 00:05:06 ]: このスレでもよく言われるけどデザインパターンは設計の話じゃないってどういうこと？
あきらかに設計の話だと思うんだけど。
21 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:07:01 ]: 実装レベルでしか理解してない奴がまだまだ多いってこった
22 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:23:55 ]: >>20
リファクタリング(この言葉もテストの修正を許容するものから
許容しないものまで幅があって一概には使いにくいな)を前提
にボトムアップで見ると実装の話になる。
テストにしろリファクリングにしろデザパタにしろ、幅がありす
ぎて各自がバラバラの思惑で使うもんだからグダグダになっ
てる。
23 名前：デフォルトの名無しさん mailto:ｓage [2006/03/15(水) 01:28:26 ]: 今日、java.io.*のクラス図を初めてjudeで自動生成してみたんだが
・・・いや、美しいな。
（こいつぁArtだ。）
クラス設計とはかくありたいなと思ったよ。

あんまりかっこよかったんで、ついA3で印刷して部屋に貼っといたぜ。
24 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 01:34:25 ]: >>23
うｐ
25 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 01:53:19 ]: 日頃どういったクラス設計に携わっているかの違いなんだろうか
格段に美しいとは思わない。当たり前の設計だと思うんだが・・・
26 名前：NAME IS NULL [2006/03/15(水) 01:57:20 ]: デザパタ入門とＪＡＶＡの格言買ってしまった。
良書ということで一週間読み込むとする。
27 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 06:29:22 ]: >>20
実装だろ？
じゃなきゃあんなソースばっか載ってる本になるのはおかしい。
28 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 07:55:55 ]: そもそも実装という作業は、設計作業の一部なんだが。
このことをわかってないﾔｼが多すぎ。
29 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 09:02:49 ]: 設計のデザインパターンと実装のデザインパターンをごっちゃにしてる奴が多いだけでしょ。
デザインパターン＝クラス構造とか思い込むからそうなる。
30 名前：勉強中 mailto:sage [2006/03/15(水) 10:54:03 ]: 設計ってしかことないけど（というかOOPってしたことないけど）、どれをクラスにするのかを決めて、
実装設計でデザパタを使う。実装がうまくいきそうにない（エレガントでないとか）ので、再度クラスを
考え直す。

っていうのを繰り返すのかな？
31 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 12:36:49 ]: >>20
設計の話だと思うよ。設計というと↓のように大きく分けて２つに分類されると思う。

■設計┬→基本設計
　　　　 └→詳細設計（プログラム設計）

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

以前、俺も「「設計の話じゃない」みたいなニュアンスで登校したことがあるのでフォロー。
えと、知ってたらごめんなさいごめんなさいごめんなさいなのですが。
32 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 12:52:11 ]: >>23
java.io.* のクラスは素敵だよな。あの汎用性と拡張性。
いつも通りに入出力処理してるだけで勝手にMD5チェックサムが取れる、
DigestInput/OutputStreamとかもう天才の発想だよな。あれは感動した。

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

↓ここの外人のクラス設計も素敵とおもた。ParallelWriterとかSequenceIteratorとか。
www.symbic.net/orbital/Orbital-doc/api/index.html
33 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 19:13:01 ]: >>31
＞デザパタは設計という部類の中の「詳細設計」。または「プログラム設計」の部分。
＞ＳＥレベルでの「基本設計」ではない。

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

P.S.
それから、基本設計はＳＥがやるものだなんて考え方をしてＳＥとＰＧの間に溝を作る
こと自体が問題を生みだしてるんじゃないか？
34 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 11:03:32 ]: >>33
まず、基本設計書の認識がお互いあってるか確認したいんだけど、

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

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

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

そんなものだと思うんだけど、そこにデザパタが入っていけるか？
35 名前：34 mailto:sage [2006/03/16(木) 11:10:17 ]: ああ、要求の洗い出しの段階で「変更されそうなところは予め聞いておく」っていう意味かな？
しかし、変更箇所を予め考慮しておくっていう作業自体はデザパタとは関係がないし、
または、その変更になる確立が高い箇所も、デザパタでは吸収できないかもしれないし、
最終的に、それを書くにしても詳細設計書だと思う。
36 名前：34 mailto:sage [2006/03/16(木) 11:17:07 ]: ＞それから、基本設計はＳＥがやるものだなんて考え方をしてＳＥとＰＧの間に溝を作る
＞こと自体が問題を生みだしてるんじゃないか？
それはあるね。SEしてる人間の連絡不足で、よくPGが仕様とは違うものを作ってしまったりする。
その責任がPGの責任になってしまったりするし。
仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。

でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。
37 名前：33 mailto:sage [2006/03/16(木) 13:04:26 ]: >>34
それは私の言っている基本設計書ではありません。

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

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

「オブジェクト指向のこころ」に載っている共通性/可変性分析ってーのは、かなり上流工程の
作業になり、こういった行為を通じて構築対象のインタフェースをクローズアップしていくこと
ができます。　ということで、この工程を実施する時点でもうデザパタを意識することになるのです。
38 名前：33 mailto:sage [2006/03/16(木) 13:11:16 ]: ＞仕様の打ち合わせの段階からＳＥとＰＧ、両方が参加すればいいのにとか思ったりするわな。
＞でも、一緒に打ち合わせ行こうよとかいうと「えー、いやです」とか言い出すＰＧも多いんだけど。
そうなんだよな～。
仕事の面白さを取って責任を取るか、仕事の面白さを捨てて責任逃れをするかってとこで、
みんな後者を取っちゃうんだよなぁ。
39 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 23:51:12 ]: なんかごちゃごちゃしてるけど、
結論としてはデザインパターンは設計の話ってことでいいの？
40 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:00:51 ]: どこまでを設計と呼ぶべきかによる、って結論に落ち着くはず。
41 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:15:14 ]: デザインパターンは内部設計の話です
42 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:27:53 ]: やっぱり、設計段階でソースが出てくるのは同考えてもおかしい。
43 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:30:59 ]: こういうフローチャートを書くとこんなソースになるんだよ
っていう教え方はわりとありふれてると思うのです
44 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 01:57:34 ]: アブストラクトファクトリとシングルトンが
同じ設計レベルで出てくることってあるんかいな？
45 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 06:52:58 ]: >>44
シングルトンを「インスタンスの個数を一定数にする」ものだと考えると
アブストラクトファクトリと同じ設計レベルになる。
もっともシングルトンは「インスタンスの個数を１個にする」という上述した
要求の特殊解なんだが。
46 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 06:55:15 ]: >>42
ヒント：ソースコード＝設計図

つ ttp://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
47 名前：34 mailto:sage [2006/03/17(金) 11:25:30 ]: >>37-38
おー、びっくりした。基本設計で「これは○○パターンが適用できますよ！」とかを売り文句にするのかと思った。

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

＞関係ないことありませんぜ。　こういった作業はデザパタを適用する上で大きな布石となります。
んー、まぁ、要件によって実装は変わるから、デザパタを適用するか、しないかも確かに変わってくるし、
基本設計時点でも関係あるっちゃあるが、ないっちゃない感じじゃないか？
48 名前：34 mailto:sage [2006/03/17(金) 11:46:10 ]: >>38
(;´-`)。o(そ、そうか！あいつら責任逃れのためか！あのやろう！)

まあ、そこで責任逃れしても、仕様と違うもの作って、
結局は作り直しさせられて残業の責任を負うはめになると思うけどね。
49 名前：33 mailto:sage [2006/03/17(金) 12:40:57 ]: >>47
＞ここで伝えたかったことはあれです。あれあれ。
＞「コンピュータで実現すれば今までの手作業がこの程度の手間で実現できますよ！」とか売り文句みたいなもんです。
＞システム化することによってメリットがあるのかを明確にするため、そんなことも書くでしょう。

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

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

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

オブジェクト指向技術を採用して開発を行う、、、となった時点で、変更容易性とかの話しに直結
するのが普通だと思うぞ。　
基本設計ってーのは、平たく言えばシステム化対象となる問題領域に境界線を引いていく作業だと
思っている。　その時にどの部分をカプセル化して変更を封じ込められるようにするのかを検討する
ことは当然のことじゃないか？
50 名前：34 mailto:sage [2006/03/17(金) 13:33:09 ]: ＞文章の断片に反応するが、「システム化することによってメリットがあるのかを明確にする」
＞というのは要求定義書の役割であって、
あっ。そりゃそうだ。まあその、手順だね。システム化することによってどんな手順・操作になるかとか。

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

まあ、デザパタを適用することを考えながら基本設計していくと確かに違ってくるんだろうけど・・・
なんか違う気がする。
51 名前：33 mailto:sage [2006/03/17(金) 14:06:42 ]: >>50
私の頭の中にある基本設計ってーのは、要求定義書が終わってから始まる一連の作業であり，
ユーザーのシナリオを一つ一つ分析しながら、サブシステムに分割していき、最終的には大まか
なクラス設計が完了するところまでと思っています。

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

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

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

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

そう言う意味じゃ「デザパタを適用すること」が目的だと言っているのではなく，「デザパタの知識を利用
することでインタフェースを使った考え方ができるようになること」が重要なのだと思っている。
そして、それが基本設計にも適用できると主張している根拠になっているわけ。
52 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 20:35:31 ]: >>51
GoFの23パターンだとそのレベルで適用するのってあったか？
パターンという括りならわかるけど
俺はそのレベルで適用可能なものってデザパタって言葉とずれてると感じるのだが
53 名前：33 mailto:sage [2006/03/17(金) 21:03:37 ]: >>52
おおまかなクラス設計を行うと言っても、頭の中に実現可能性を想い描くことが
できなければ絵に描いた餅になる。　そういった点で GoF の23パターンを見た場合、
適用できないものの方が少ないと思う。

私の場合、よく使うのはBridge、AbstractFactory、Strategy、Observer、Visitor、等々
54 名前：52 mailto:sage [2006/03/17(金) 21:18:37 ]: >>53
なんか俺はちょっと違うことを考えていたらしい
実現可能か考えずに、より適切なモデリングするぐらいのものかと思ってた
言語まである程度意識してるクラス設計まで　ってことでいい？
55 名前：33 mailto:sage [2006/03/17(金) 21:51:21 ]: >>54
いいっす。
そもそも、言語を考えずにモデリングするってーのは、はなはだ危険な行為だと思う。
だいたいクラス設計と言った瞬間に、オブジェクト指向言語の採用が前提となってるので
言語を意識しないモデリングなんてあり得ないと思うが。

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

蛇足だが、この辺りのことを理解してないSEが多く、下流工程を意識することなくモデリング
しようとするSEがいるためにSEとPGがいがみ合ってるということもあると思う。
クラス設計時に名詞と動詞を抽出するなんてアプローチを使ってちゃ、下流工程を意識しよう
にも意識できないわな。　そんな設計だと実装時にギャップで苦しむのは目に見えている。
56 名前：52 mailto:sage [2006/03/17(金) 22:05:51 ]: >>55
アナパタは言語意識しないよね　あのレベルなのかと思ってた
ソフトウェアを作るためのモデリングじゃなくて、現状把握のためのモデリングかと
基本設計って結構範囲が広いんだな
57 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 22:18:08 ]: 設計段階からデザインパターンを使いまくろうなんて考えていると、
アンチパターンになるぞ。
実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。
58 名前：33 mailto:sage [2006/03/17(金) 22:20:45 ]: アナパタは結構毛色が違うよね。
あれは要求定義書を作る際に使うものだと認識してまふ。
要求定義＝Whatの定義、設計＝Howの定義なのでどうしても切り口は違って
くるかな。

ということで今日はボチボチ帰って寝るわ～。
59 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 00:42:04 ]: >>57
それ単に設計が不十分なだけじゃん。
60 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 01:28:46 ]: なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい。
61 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 03:58:40 ]: 俺がGoFのデザパタ意識するのは
・(ツールレベルの)フレームワークの設計/実装をしてる時
・実装コードのリファクタリングをする時
だけ。
設計か実装かと言われれば、俺の意識だと実装。
前者は人によっては設計と呼ぶかもしれない。

アプリレベルのフレームワーク設計してる時には
とたとえばJ2EEデザインパターンや
アンチパターンは大いに意識するけど
GoFを意識することはない。
62 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 07:55:20 ]: >>57
＞設計段階からデザインパターンを使いまくろうなんて考えていると、
＞アンチパターンになるぞ。
＞実装していって、気持ちが悪くなったらデザパタ使ってリファクタリングする。

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

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

>>60
つ >>46

>>61
アプリレベルの設計でも Bridge パターンはよく使うぞ。
このパターンは、日本で最も過小評価されているパターンなんじゃないかと思う。
俺も「こころ」本を読むまで Bridge を正しく認識していなかったが。w
（他にも当たり前のように Strategy とか使うけど。）
63 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 10:44:09 ]: なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしい
64 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 10:47:48 ]: うちだとアプリレベルの設計はもっと大枠で捉えてしまうんすよ。
プロセス・スレッド間の通信には何使うとか、
他システムの通信方法がｷﾓいから
この部分はラッパーでカプセル化しちまおうとか、
DAO層はあのやり方で実装しようとか、
その程度だけ決めて実装(含むプロトタイプ作成)に入っちゃう。

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

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

こういった「あるものを流用」したり「技術からの要求を主」にする設計は、顧客の要求する
ものを取り込むタイミングが難しく、顧客ニーズからブレたものができる危険性がある。
大規模開発をする予定があるのなら、トップダウンの視点は身につけておいた方がいいと
思うぞ。　　この視点は小規模開発でも有効だし。
66 名前：34 mailto:sage [2006/03/18(土) 13:14:44 ]: >>51
うーむ、詳細設計をしつつ基本設計をする。って感じに聞こえてしまうなぁ。
基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？
それだと俺が働いてきた会社の基本設計とは違うかもしれない。
というか基本設計とかって働いてる場所によって意味合いが変わってくるかもね。

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

それぞれのパターンのうまい使い方の情報交換とかしたい。
67 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 13:50:37 ]: こころたけーよこころ orz
昨日、本買ったばっかりなのに
68 名前：33 mailto:sage [2006/03/18(土) 14:46:19 ]: >>66
＞基本設計でクラス設計を完了させるってのはクラス図とかも基本設計書に書いちゃう感じなの？

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

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

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

いいですねー、それ。　　どんな感じでやりゃいいのか、イメージはできてないけど。
69 名前：http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 20:16:45 ]: TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
70 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 02:54:15 ]: 俺は Template Method が一番利用頻度高い。
その次に来るのは Adapter や Decorator、Singleton。
DIコンテナ使うことが殆どなので
潜在的には Factory パターンの利用回数がダントツなんだろうか。

Template Method はDIコンテナと親和性が高いので多用してしまう。
71 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 12:36:24 ]: なんにしてもやっぱり設計の話でソースコードがでてくるのはおかしいよな
72 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 17:01:07 ]: >>71
釣れますか～？
73 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 17:49:49 ]: >>72
釣られちゃってますね。
74 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 19:44:20 ]: >>73
おっ、釣れた釣れた。
75 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 22:21:03 ]: >>74
これをメタフィッシングパターンと命名する。
76 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 01:23:29 ]: ＞それぞれのパターンのうまい使い方の情報交換とかしたい。
とか言っちゃったけど、言いだしっぺの俺がまずなんか書かねば…。
77 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 21:22:18 ]: 俺がプロトタイプ作成→リファクタリング→Template Method適用に至るよくある手順

(1) 詳細は無視して大まかな流れだけを実装する。
(2) 細部に肉付けして簡単なテストが通ることを確認する。
(3) 一部の処理が特定の条件下では異なるため、その処理と、条件分岐の部分を書く。
　　テストが通ることを確認する。
(4) 別の条件だと別の処理を書かなくてはならず、いい加減面倒になってくる。
　　もっとスマートに書けないものかと思案する。
　　どう考えても Template Method パターンです。本当にありがとうございました。
(5) という事で書き直す。テストも通る。
78 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 22:29:11 ]: 構造に関するパターンは設計段階でも話が出る可能性はある。
振る舞いに関するパターンはほとんどでない。
79 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 08:07:30 ]: >>77
よくある手順って…おまいは毎回そんなことを考えてるのか。
いい加減、最初からわかれよ。
80 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 08:37:57 ]: >>78
振る舞いに関するパターンでも Command，Interpreter，Observer，Visitor なんかは
大まかな設計レベルでも十分考慮対象だったぞ。　それ以外はちょっと詳細な設計
レベルになるかもしれんが。
あと、生成に関するパターンも構造に関するパターンと対にして設計時点で使うわな。
81 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 10:39:52 ]: >79
最初は動くものを作って、だんだん仕上げてく。
こっちの方が最終的に早く出来上がるし、
変な設計に振り回されないので見通しも良くなる。

別フレームワーク作るわけじゃないんだから。
82 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 13:10:21 ]: >>81
曳光弾形式の開発ができる現場だとそれもいいんじゃない？
83 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 13:46:40 ]: 行き当たりばったりなだけじゃん
84 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 13:58:20 ]: >>83
悪く言えばそうだけど、XPなんて正にそれじゃん。
行き当たりばったりだったとしても、そのプロセスに顧客を巻き込めれば無問題。
スパイラル開発で各サイクルを早く回そうとするのもまったく同じこと。

ただ、そういったプロセスを使えない開発の場合には、まったくもって指摘通りになる。
そしてこの場合、デザパタはリファクタリング時だけでなく、設計時にも活用することになる。
そんだけのことじゃない？
85 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 00:43:07 ]: 俺は84じゃないが、最初は出来るとこまで作って、
後からどんどん洗練してくやり方なんて最近じゃ普通の考え方だと思うんだけど。

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

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

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

プロトタイプを設計フェーズだと考える場合、そのプロトタイプは実装フェーズ
に引き継がれないという暗黙の前提が生まれるため「行き当たりばったり」という
表現は妥当ではなくなる。　ってーか設計フェーズは試行錯誤するのが当たり前。
88 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 15:41:57 ]: なるほど。
89 名前：デフォルトの名無しさん mailto:sage [2006/04/07(金) 16:41:51 ]: このスレではわりと好意的な評価のようなので
こころを買ってみた。
最初は眠くなる話が多い気がする。
良さが分かるまでにしばらくかかりそうだ。
90 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 01:15:39 ]: >>89
もしや、他にデザパタの本読んだ経験無い？
91 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 01:17:44 ]: 結城本でFAかと思ってた
92 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 01:21:13 ]: 結城本はかなりメジャーだからむしろ宣伝するやつが少ない
93 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 07:13:58 ]: 「ここは○×パターンでコーディングする」と書かれた仕様書が上から落ちてくる
のであれば、結城本でも十分だろう。

しかし自分で適用可能なデザインパターンを見つけ出す（＝自分で仕様書を書く）場合、
結城本だけではツライと思う。
（練習問題を飛ばさずに真面目にじっくりやってれば、できるかもしれんが。）
94 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 12:47:40 ]: >90
結城本は持ってる。
デザパタそのものの有用性は自分なりに理解してる。

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

「こころ」は前書き読む限りだと過程を重視してるようなので期待。
まだ第一部読んでるあたりで、UMLがなんちゃらとかそんな話。
非常に眠くなる。読み飛ばせばいいのだけど、それが出来ない性分。
95 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 13:08:32 ]: ある程度パターンを暗記したら、あとは実際にデザパタを意識したコードを読むのが良いと思う。

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

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

論を勉強するのもいいけど、やっぱり証拠もないと理解しにくいかと。
96 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 02:30:58 ]: てっきりあの「あなたの考えを広げるためのヒント」が
結城本の特徴なのかと思ってた。
あれの域にとどまらず、もっと応用の指針について
解説されてる本があるのね。
97 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 10:33:45 ]: 結城本はGOFの劣化版でしかない
GOFのわかりやすいところ(結城が理解できたところ)を
初心者向けに言い直しただけ
それ以上の情報はいっさいなし

オブジェクト指向のこころとアジャイルソフトウェア開発の奥義を読んで、
リファレンスとしてGOFを手元においておけばいいと思う
98 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 10:40:03 ]: GOFはなんでC++を選んだのだろう
99 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 11:14:05 ]: どういうこと？
Smalltalkで全編書けってこと？
GoF本オリジナルは1995年だからJavaはありえんよ
100 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 14:18:36 ]: 日本語版なら付属CDにJavaソースあるしね。
確か、SmalltalkとC++のうち話したいことがわかりやすいほうで例示する、みたいなこと
書いてなかったっけ。
101 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 14:21:47 ]: >>99
単純になんでだろう、と思っただけなんだ。
そうか、Javaなかったのか。そりゃ仕方ない。
102 名前：デフォルトの名無しさん mailto:sage [2006/04/09(日) 15:43:01 ]: 結城さんに抽象的なモノを説明させるとかなりヤバい。
例とか背景とかなしで、方法だけを詳しく掘り下げる。
同マルチスレッド編もそんなスタイル。途中で読むの止めた。

具体的な内容だとすごく分かりやすい・読みやすいもの書いてくれるんだけど。
HOW TO 本が彼の本来のフィールドだと思う。
103 名前：デフォルトの名無しさん mailto:sage [2006/04/13(木) 01:17:07 ]: あるシステムのGUIコンポーネントを表示する部分の設計をしているんだけど、
綺麗な設計が浮かばなくて悩んでます。

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

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

こういう場合、どういうパターンが有用だと思いますか？
104 名前：デフォルトの名無しさん mailto:sage [2006/04/13(木) 02:13:37 ]: Composite
105 名前：デフォルトの名無しさん mailto:sage [2006/04/13(木) 23:20:57 ]: トップダウンでできんじゃないの？
>>104のいうとおりCompositeで。
106 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:12:06 ]: そういうのはパターンと言うよりアルゴリズムの話
108 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:27:37 ]: >>107
本質的には同じなんだけどな
109 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:32:24 ]: 二回走査しなければいけない原因を分析
　アルゴリズムの問題
　構造の問題

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

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

と手順踏めば良いだけのこと
いきなりパターンに解を求めるのは違うよ
110 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:36:45 ]: >>109
108じゃないけど本質的には同じじゃないか　＾＾；
111 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:43:37 ]: 本質は同じだけど、視野が狭くなるでしょ
元の課題の本質が理解できていない人がとるべき行動ではない
112 名前：デフォルトの名無しさん mailto:sage [2006/04/14(金) 08:53:08 ]: >>111
そりゃそうだ
113 名前：デフォルトの名無しさん mailto:sage [2006/04/17(月) 08:55:15 ]: まあ、そんなこと言ってると、このスレの視野が狭くなって話題が無くなるけどな
いいじゃん本質は似たようなもんなんだから。そこからパターンの話が広がってくかも試練氏。
114 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/05/08(月) 16:03:28 ]: >>115
シングルトンって言われると違和感が多少あるけど、処理自体は変じゃないと思いますよ。
117 名前：デフォルトの名無しさん mailto:sage [2006/05/08(月) 18:56:14 ]: >>115
オレなら初期化用のメソッドを作るかな。
118 名前：デフォルトの名無しさん mailto:sage [2006/05/08(月) 23:54:26 ]: >115
getInstance(String) の呼び出しを
一回に限定しないとならんわけだけど
それはどのように実現するつもり？

ファイルパスだけでいいのなら、
プロパティファイルなりで指定して
静的初期化ブロックで処理してしまえば良いのでは。
(javaじゃないなら環境変数などで渡す)
119 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 09:53:43 ]: そんなかんじでよさげ。

ハッシュ（マップ）みたいなものにファイルパスをキーにして
自分のインスタンスを複数保持すればいいんでね？
ハッシュから取り出せなかったら場合に、同期で初期化すればよいかと。
120 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 11:12:06 ]: >>116-119
お忙しい中、良レスありがとうございます。
今まではプロパティファイルに絶対パスを指定しておいて初期化メソッドの中で読み込むようなことをしていました。

Webアプリだと環境によってデプロイされる場所が変わってしまい、環境毎にプロパティファイルを設定するのがたいへんでした。
ファイル自体はWEB-INF/fileの位置においてあるので
ServletConfig#getServletContext().getRealPath + "/WEB-INF/file"のようなかたちでパスを作り
初期化メソッドにパスを渡すような構造に変更しました。
121 名前：デフォルトの名無しさん mailto:sage [2006/05/09(火) 15:21:04 ]: デザパタとは外れますが
＞環境毎にプロパティファイルを設定するのがたいへんでした。
war作るたびに設定編集するのは大変なんで
・環境の数だけ設定ファイルディレクトリ作成
・環境依存の設定ファイルを全てぶちこむ
・環境の数だけwar作成
・warを作成する時には環境に適した設定ファイルを使用する
・warの作成は設定の選択も含めてantで行う。
にしてみてはどうでしょうか。
122 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 02:49:21 ]: if文はあんまりつかいません
と言い換えればOK？

説明文で躓いてるならそれで十分だけど
内容で躓いてるなら
「状態を変更するif文は必要」
「状態を判断するif文は不要」
と考えれば少しは納得いくかも
125 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:12:51 ]: switch(状態){
case 朝:
currentState = mornig;
break;
case 昼:
currentState = day;
break;
case 夜:
currentState = night;
break;
}
currentState.showMessage();

こうしか思いつかないんですけど、なにか根本的に間違ってますか？
126 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:18:07 ]: >>123
意味的な話をすると、State パターンってのは、表示メソッドが showMessage01 ～ showMessage03 まであったときに、

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

と

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

のどっちが使いやすいかーって話にも関連してくる。ちなみに下が State パターン
127 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:19:31 ]: >>125
違う違う。状態は予めセットしておくの。
んで showMessage したいときに currentState.showMessage()
128 名前：123 mailto:sage [2006/06/04(日) 03:33:02 ]: >>126
なんとなくわかりますが…
>>127
その状態はいつセットするんですか？
123のサイトの説明ではさっぱり。
currentStateには状態がかわった時にmornigなりdayなりがはいるんですよね？
実装がわからないです。
バカでもうしわけないです。
129 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:46:21 ]: >>128
いつセットするか……。
少なくとも showMessage の直前までには正しい状態がセットされてる必要があるね。

逆に考えると、『状態がセット』されるタイミングと『実際に showMessage 』されるタイミングを離すことが出来る
ってのも、メリットの１つじゃないかと。
130 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:46:30 ]: 状態は変わったときだから
その場合は時間が経過した時になるかな？

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

すると状態変更はTimerの監視部分だけになって
あとはstateを呼ぶだけで勝手に動作が切り替わる
131 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:49:00 ]: 『状態がセット』というより、『状態を判断するタイミング』って言ったほうが良いかな。

タイミングってのは、コード上の箇所も含むよ。
先に状態を判断しておいて、後からその状態に従った動作を行わせるってのも State パターンで行えるし。
132 名前：123 mailto:sage [2006/06/04(日) 03:56:15 ]: うーん、いまいちよくわからないですね。
朝.showMessage();
昼.showMessage();
夜.showMessage();
の３つのメソッドを作って状態みてどれかのメソッドを呼び出す。
このやり方とサイトの説明の差は>>129さんの
『状態がセット』されるタイミングと『実際に showMessage 』されるタイミングを離すことが出来る
しかないように思えます。
今日はもう寝ます。明日また考えたいと思います。
みなさんありがとうございました。
133 名前：123 mailto:sage [2006/06/04(日) 03:58:09 ]: >>130さんのがなんとなくわかるかも…
明日その辺も考えてみます。
134 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 04:13:05 ]: >>132
ちなみに、こういうメリットもある。

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

だから、勝手に MyState のサブクラスを自作して、それを currentState にセットしても動くかもね。
135 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:30:10 ]: たとえば後からStateに夕方を追加したくなったとすると

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

Stateクラスとしてまとまっている方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．夕方クラスを追加
クラスを増やすぶん、追加すべきコード量自体はむしろStateを使わない場合より多くなりそうだが
２の作業については変更箇所が新規クラスの追加という形で一箇所にまとまっているため
既存の朝昼夜は基本的に触らなくてすむ。
136 名前：135 mailto:sage [2006/06/04(日) 21:22:31 ]: 補足。

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

状態の種別のほうが追加や変更を受けることが多そうならStateを使うといい。
137 名前：123 [2006/06/05(月) 11:43:58 ]: いろいろと説明ありがとうございます。

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

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

とゆう認識でよろしいでしょうか？
でもまだ疑問が。
いろいろサイトをみてまわったんだけど、ほとんどの所でStateパターンはifは使わないと書いてます。
でも今までのやり方だと状態を変える時結局ifが必要で、
ただのポリモルフィズムの説明に思えるんですが…
138 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:01:57 ]: >>137
＞・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
割とそうではない場合も。このあたりはケースバイケース。

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

＞ただのポリモルフィズムの説明に思えるんですが…
認識としては全く正しい。多態を使用して、”オブジェクトで状態を表す”のが State パターン
139 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 13:04:39 ]: >>137

１．状態を変えるための判断としてのif
２．（今現在の）状態を判断するためのif

がごっちゃになってない？
Stateパターンだとifは使わないというのはおそらく後者のほうかと
前者はどうしようもないよね。
140 名前：123 mailto:sage [2006/06/05(月) 13:35:35 ]: りょうかいです。
すっきりすることができました。これでやっと次に進めます。
ありがとうございました。
141 名前：デフォルトの名無しさん [2006/06/06(火) 00:53:15 ]: >>135
コード量では後者の方がむしろ追加分量が増えるという所が何とも吐き気がするんだが…ｗ
142 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 22:10:57 ]: インデントとか改行みたいなもんだよ
コードの見通しを良くするために使う。
また、見通しが良くならないのであれば使うべきではない。
143 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 22:18:34 ]: 一番大事なことは
状態のような概念をオブジェクトとして扱うという考え方
なんじゃないかと思う
144 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 10:04:36 ]: 一昔前はオブジェクト＝モノ。
モノに操作を与える＝クラス。
だったすからねえ。

ていうかオブジェクト指向のオブジェクトって言葉が
もう時代にそぐわない気すらするですよ。
145 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 10:30:27 ]: エンティティのほうがまだまし？DBのほうで既成の用語なんで使いづらいけど
146 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 20:36:15 ]: この調子で幸せになれる議論をお願いします
147 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 21:52:49 ]: しかしやっぱ、そんなに議論する内容ってないよねこのスレ。
148 名前：デフォルトの名無しさん [2006/07/07(金) 23:17:05 ]: commandパターンとstateパターンの違いがよく分からん。

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

結局、名前が違うだけで考え方は一緒のような気がするんだ
が・・・という俺の愚痴。
149 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 23:37:55 ]: >>148
Strategy と State と Command は、どれも多態で処理を切り替えてるから、
おそらく知らない人が見れば同じに見えると思う。

ただ、意味的な物は随分異なる。重点はそこかと。
150 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 23:44:15 ]: そうかそうか。よーくわかったぞ。
151 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 00:42:23 ]: 考え方は一緒だけど、使う箇所が違うってだけで分けられたパターンって結構あるよね。
前々スレあたりでGoFも一部の似たようなパターンは無くすとかいってなかったっけ？
152 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 01:22:41 ]: >>141
テストケースのコード量も加味して考えるといいのでは。
153 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 02:29:05 ]: StateとStrategyは構造は同じだけど、意味の区別がやや不明瞭。
Commandは意味も構造も違う。
GoFの原典を読むとそんな感じだな。
154 名前：デフォルトの名無しさん [2006/07/08(土) 02:58:41 ]: そんな事いったらChainOfResponsibilityだってたんなるtree構造じゃん
155 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 03:20:10 ]: そうか。なるほど。うん。お前の言いたい事はよくわかったぞ。
156 名前：デフォルトの名無しさん [2006/07/08(土) 04:29:30 ]: 何がtree構造だ？馬鹿。
157 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 19:50:03 ]: どうやるとこのスレ盛り上がるのかな。
158 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 22:03:22 ]: なるほど。GoF信奉者は馬鹿ばっかりだという事がよくわかったぞ。
159 名前：デフォルトの名無しさん [2006/07/08(土) 22:04:42 ]: ごめん。
オレが。
フェブってた。
160 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:17:09 ]: フェブってたという言葉がググレません。
トミーフェブラリーのことかー！
161 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:24:07 ]: ファブってたのtypoじゃないか
162 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:30:05 ]: ファブリーズのことかー！
それは言うならファビョるじゃないかな、たしか。
163 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:31:22 ]: >>162
残念、そこは落とすところだ
164 名前：デフォルトの名無しさん mailto:sage [2006/10/21(土) 01:39:05 ]: 現在ゲームをつくっていてどういうパターンを使えばいいか悩んでいます
アドバイスをお願いします。

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

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

このようなものを実装するのに適したデザインパターンを教えてください。
165 名前：デフォルトの名無しさん [2006/10/21(土) 01:40:01 ]: age
166 名前：デフォルトの名無しさん mailto:sage [2006/10/21(土) 03:09:11 ]: >>164
あえて言うなら Mediator
167 名前：デフォルトの名無しさん mailto:sage [2006/11/01(水) 21:48:53 ]: >>164
表示という親クラスを作って
空、鳥Ａ、鳥Ｂをそのメンバにする。
鳥Ａと鳥Ｂの相互作用が絶対に必要なら
Birdsという鳥全体の動きを仕切るクラスを作って、
そこに鳥Ａと鳥Ｂを入れる。
168 名前：デフォルトの名無しさん mailto:sage [2006/11/03(金) 19:06:17 ]: >>164
Observer
はどうでしょう。
鳥Aは鳥Bの位置を監視し、その値がかわったら、自分（鳥A）の座標をupdateする。　
鳥Bも同様。
169 名前：デフォルトの名無しさん mailto:sage [2006/11/03(金) 19:11:56 ]: >>168
無限ループに突入しないようにしないとな
170 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 12:34:28 ]: まだ結城本読了＆自分のプログラムにいくつか採り入れる
っていうレベルで、まだGoFのカタログ読んでないです。

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

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

状況次第なんですかね？
そろそろGoF読まなきゃと思いつつ、なかなかとっつきにくい
171 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 23:07:26 ]: そもそも

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

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

ということがわからんのです(；´Д`)
173 名前：デフォルトの名無しさん mailto:sage [2006/11/21(火) 21:52:55 ]: >>172
AbstractFactory パターンを使って、ConcreteImplementor を作る、
だと思うよ。クラス図を書けばすっきりする予感。
174 名前：デフォルトの名無しさん mailto:sage [2006/11/22(水) 01:34:32 ]: >>173
なるほど、そういうことだったんですか。。。
やっと頭の中でクラス図がぼんやりできてきました。

デザパタを教条的に使うだけじゃ、いかんですな。＜自分
ありがとうございます
175 名前：デフォルトの名無しさん mailto:sage [2006/11/24(金) 16:24:47 ]: 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 名前：デフォルトの名無しさん mailto:sage [2006/11/24(金) 16:39:37 ]: >>175
書き換えられなかったらどうするのか、って話だ。
177 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 16:52:58 ]: >>175の天才ぶりにびびった。
178 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 00:49:44 ]: void ColorPuts()()
179 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 10:45:59 ]: >>175
あなた程の天才がなぜこんなスレを見てるのですか
180 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 11:56:28 ]: Adaptor　-　貴方は委譲しますか？継承しますか？

漏れは原則委譲派
181 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 20:42:59 ]: >>180
case by case だけど、俺は継承だな……
182 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 23:47:27 ]: 委譲(包含+転送)しか使ったことないです。

継承の方が優れてるケースってどんな時でしょうか。
基本的に adapter is a adaptee な状態にはならんので
継承使おうと言う気が起きないです。
183 名前：181 mailto:sage [2006/11/29(水) 01:17:07 ]: あ、ごめん。普通に勘違いした。委譲だ委譲。

よく考えなくとも Adapter クラスを継承することは大前提なんだよな。
すまね orz
184 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 04:55:44 ]: 結局継承によるアダプターは誰も実践してない罠。

でもアダプターパターンの解説見てると
継承による方法が先の場合が多いのはなぜなんだぜ。
185 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 09:15:54 ]: 委譲よりも継承の方が、初心者にはOOっぽく見えるんだぜ？
186 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 23:52:47 ]: 継承による場合は override によって処理を上書きすることで
完全にコントロール出来ることが利点だと説明するサイトがあったが
コントロールしちゃったらアダプタでもなんでもないと思った。
187 名前：デフォルトの名無しさん [2006/12/28(木) 20:59:47 ]: 質問なんですが、ファクトリパターンってインスタンスが一つあればいいってのはわかるんですが、
メソッドをstaticじゃなくて、シングルトンパターンにする必要があるのですか？
どうせなら、インスタンス作らないで、staticメソッドにしてアクセスした方がいい気がするのですが
インスタンスを生成するかstaticにアクセスするかどちらの方がいいのですか？
188 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:06:43 ]: 一概には言えまい
staticにしてしまうとファクトリ事態を抽象化することが出来んからな
189 名前：デフォルトの名無しさん [2006/12/29(金) 00:46:41 ]: >>188
なるほど
190 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:52:45 ]: >>182
adapter has a adaptee？
191 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:58:56 ]: client　→　Target
　　　　　　　　△
　　　　　　　　 |
　　　　　　　Adapter→Adaptee

TargetはClientに対するInterfaceだからAdapterがTargetを継承するのは当然なのでは？
AdapterはAdapteeに委譲するのは当然だし
192 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 06:29:05 ]: >>191
当然だと思う。

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

オリジナルのGoF本を読んでないので分からんけど。
193 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:14:40 ]: >>192
クラスでもいいのでは？
Targetとしての振る舞いに共通なものがあるのだとしたら
抽象クラスとする事もアリだと思うけど

Client　→　Target
　　　　　　　　△
　　　　　　　　　;
　　　　　　AbstractTarget　
　　　　　　　　　△　　　　　　
　　　　　　　　　 |　　　　　　　
　　　　　　　　Adaptar　　→　　　Adaptee
194 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:29:13 ]: まあ、↑みたいにするAdapterパターンの説明としては複雑になるから
省略してTargetをクラスにしてるんだと思うけど
195 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:00:04 ]: クラスが悪いとかクラスじゃできないとか言ってるんじゃなくて。

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

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

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

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

なんかもうコードが共有されるなら継承が最高の解なんだよ、みたいな。
それは15年前に通ってきた道だろう、と。
196 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:07:58 ]: それをいったらデザインパターン自体が出てからだいぶ時間がたってるから
当時の説明をそのまま鵜呑みにしてもしょうがないでしょ。
もし初心者がそれ見て今の時代にアンマッチな知識をインプットしてしまう
事に懸念を感じるなら、自分で「こう解釈するのがいいですよ」って説明する
サイトでも立ち上げてみればいいｗ
197 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:14:16 ]: >>195
＞↓これが一般例で、他はもう特殊例でしょ？
それは少し乱暴だと思うが・・・・・
そう熱くなるなよｗ
198 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 16:58:29 ]: >>195
っていうか、「委譲」って言葉の使い方間違ってね？
199 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 21:21:49 ]: Effective C++ みたいに、時代に合わせて新しくなるデザパタ本があればいいのにな。
200 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 22:04:55 ]: GoFのデザインパターンは、モデリングの世界の"Hello World"
見たいな物になってしまったンだと思うね
201 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 19:42:57 ]: ほす
202 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 20:07:12 ]: 「それはパターンから外れているから駄目だ」とかは全然駄目なセリフの例ですね
203 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:41:05 ]: ほす
204 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 13:53:11 ]: いまさらデザインパターンを語ることはあるまい
205 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:24:09 ]: デザインパターンってもう語りつくされたん？
206 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:36:31 ]: 語れるほど言葉を持たないというのが正確なところかｗ
207 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 18:06:31 ]: これはよく使うパターンって何？
208 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 03:12:29 ]: Iterator
209 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 07:26:27 ]: Singleton、Factory、Template あたりかなぁ。
210 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:45:02 ]: こんぽじっと
211 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:47:05 ]: こーるばっく、こまんど、
212 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:28:34 ]: 微細主義，機能分割，集団無能化・・・
213 名前：デフォルトの名無しさん [2007/02/10(土) 20:34:33 ]: 結城さんのMLってどうやって送信先メールアドレスを変えるんだ？
進級２つ登録したから古い方だけ購読解除できればいいんだが

まぁ４月になればアドレスが使えなくなるから放置でもいいんだけど
214 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 22:10:48 ]: >>213
それって面白い？
215 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 01:12:50 ]: NullObjectのような、GoFの23には含まれていないパターンについて勉強したいのですが、
みなさんはどのように勉強されましたか？
個人的には本で勉強したいので、参考になる書籍などを示してほしいです。
216 名前：デフォルトの名無しさん [2007/02/12(月) 19:33:51 ]: age
217 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 19:38:25 ]: boostのコードを読むと、すごい勉強になった
218 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:29:48 ]: >>217
kwsk
219 名前：デフォルトの名無しさん [2007/02/12(月) 20:55:12 ]: デザインパターンを勉強すると、
自分が頭良くなってスゴイSEなったってカン違いするヤツ、
多いよな・・・
220 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:59:00 ]: 一人前のSEって感じでしょ
221 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 11:29:01 ]: GOFデザインパターンはマイクロアーキテクチャーの一種に分類され、
その対象領域は一般にプログラムと呼ばれている、いわゆる動作単位であるから、
どの様に考えてもプログラマの職域に属する事項であるかと
222 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:23:41 ]: >>221
「マイクロアーキテクチャー」って一体何の事だか、
分かっている？
223 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:58:25 ]: SEではないな
224 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 08:14:40 ]: 半導体設計が思い浮かんだ。
225 名前：デフォルトの名無しさん [2007/02/19(月) 23:50:05 ]: >>219
結局デザインパターンって、フレームワーク作る時にしかあんまし使わないかなあ
226 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 23:54:41 ]: 勉強が足らんな
227 名前：デフォルトの名無しさん [2007/02/20(火) 00:13:46 ]: >>226
kwsk
228 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:24:41 ]: フレームワーク使う側でも使う。
java.lan.io.* なんてデコレータパターンの塊だし
コレクションフレームワークはそのままイテレータパターンの実装だし。

フレームワークが面倒見てくれない粒度の細かいオブジェクトの組み立てには
それはもうファクトリやらテンプレートやらのオンパレードさ。
229 名前：デフォルトの名無しさん [2007/02/20(火) 00:33:57 ]: >>228
ｉｏ自身がデコレータでしょ
使ってる側は意識しないはず

イテレータは素人でも使うよ
230 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:43:25 ]: イテこまし…いやなんでもない
231 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 05:36:30 ]: つーか、あるものを利用するだけで自分では使わないんだｗ
232 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 15:50:13 ]: プログラマなんてみんなあるものを利用するだけでしょ
アセンブラでもマシン語でも。
233 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 23:18:29 ]: いんや
234 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:22:45 ]: ｺﾞﾌ！
235 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:07:48 ]: ちょっと皆さんに助言願いたい事があります。
例えば、ゲームプログラムなんですが、
あるキャラクタークラスYがあったとしてキャラクタークラスは内部に
AI処理を担当するクラスZをコンポジションでもっていたとします。

で、AIのタイプにはいくつかあって（タイプA/B/C）、それぞれの
タイプにも、細かく引数によってパラメータの指定ができるとします。

AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジションで
持っていてもまぁなんでもいいのですが、

他のクラス（ゲーム進行管理クラスなど）からそのキャラクターのAIの動作を
変更するために、例えばAI処理をタイプBに変更、そしてB特有のパラメータを設定できるとします。

こういう事を実現するために、現在はクラスZを持っているキャラクタークラスにも、
タイプA,B,Cいずれの処理に切り替えるメンバ関数、あるいはそれぞれのタイプ別にパラメータを
設定する独立したメンバ関数を設定しています。
でもこういう事をすると、AIのタイプを増やすたびにキャラクタークラスにもそれに応じた
メンバ関数を追加する手間が必要になってしまいます。

もっとスマートなやり方は無いものでしょうか？
236 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:14:56 ]: 他のクラス　──→　AIクラス
　　　　　　　　　　　　　　△
　　　　　　　　┌───┼───┐
　　　　　　　　│　　　　 │　　　　│
　　　　　　　　タイプA　　タイプB　　タイプC

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

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

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

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

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

割りきりが必要。極端に変な動作はさせないほうが吉。
238 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:00 ]: ｴｴェェェ・・・？
239 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:40:37 ]: >>235
他のクラスオブジェクトへの参照を持つ事をコンポジションというのではないのですか？

ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、
いっそZへの参照を利用側に渡してしまおうかと思ったのですが、内部のオブジェクトの参照を
外部に渡してしまうのは好ましくないようなので、どうしようかと思ったのです。
Zのメンバ関数のいくつかは、キャラクタクラス以外のクラスから呼んで欲しくないものがあるので・・・。
240 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:48:58 ]: 書き間違えました。

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

です。
241 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:35:06 ]: >>240
ABCがAIだろうがキャラクターだろうが同じじゃハゲ
242 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:44:26 ]: 　　　　　　　　　┌─→AIクラス
　　　　　　　　　│　　　　　◇
他のクラス　─┤　　　　　│　　　　　　　　　　　　　
　　　　　　　　　│　　　　　↓　　　　　　　　　　　　　 ┌→キャラクターA
　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB
　　　　　　　　　│　　　　　　　　　　　　　　　　　　　 └→キャラクたーC
　　　　　　　　　│　　　　　　　　　　　　　　　　　　 ┌→キャラクターA用のセッター
　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 └→キャラクターA用のセッター
243 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:45:17 ]: まちがいたｗ　　　　　　

　　　　　　　　　┌─→AIクラス
　　　　　　　　　│　　　　　◇
他のクラス　─┤　　　　　│　　　　　　　　　　　　　
　　　　　　　　　│　　　　　↓　　　　　　　　　　　　　 ┌→キャラクターA
　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB
　　　　　　　　　│　　　　　　　　　　　　　　　　　　　 └→キャラクたーC
　　　　　　　　　│　　　　　　　　　　　　　　　　　　 ┌→キャラクターA用のセッター
　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB用のセッター
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 └→キャラクターC用のセッター
244 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:49:25 ]: Javaで書くとこんな感じ

　　　AICharactor iaChar = ai.getCharactor();
　　　PropertySetter setter =　PropertySetterFacotory.getSetter(aiChar);
　　　setter.set(iaChar,otherObject);
245 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:53:52 ]: プロパティじゃなくてパラメータだなｗ
246 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 03:01:46 ]: >>235
そういうときこそ継承使えばいいじゃない
247 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 11:37:58 ]: 全 AI が必要とするパラメータを一つの巨大なクラスに集めて、それを渡すことにするとか。
各 AI はそのオブジェクトを一つ受け取って、自分に関係するメンバだけ触ることにすれば、インターフェイスは共通化できる。
AI が増えても、そのクラスにメンバを増やすだけで、他は一切書き換えずに済む。
再コンパイルは必要だろうけど。
248 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 15:49:22 ]: みなさん、ありがとうございます。
>>247
その方法も考えていました。なんかオブジェクト指向的に完璧な解決策じゃない
気がしていたんですが、それが一番手っ取り早いのかもしれませんね。
249 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 16:03:31 ]: ・・・・・・・・
250 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 18:16:05 ]: パラメータをいじる権利のある人がAIを生成して
もしも途中でパラメータを変更する必要があるならそのままそいつが参照を持ちつづけ
キャラクタは自分が生成されるときにAIへの参照を貰い受けるような形のほうがいいと思う
パラメータを設定できないtickするだけのインターフェイスで貰えるならなお結構
251 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:45:05 ]: >>235
なんかよくわからんけど、直感的にBridgeパターンが頭に浮かんだ。違うかな。
252 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:59:31 ]: オブジェクト指向ってホントウに垣根が高いんだな・・・・
253 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:18:21 ]: たぶんずれると思うけど。

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

ゲーム進行 ----> AiBuilder-------
↓ ↓ |
キャラクタ ----> <Interface>Ai |
△ |
| ↓
AType BType CType
254 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:20:08 ]: ずれすぎてだめだった。
ABCはAiのサブクラスね。
255 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:15:43 ]: 全角スペースを使い玉へ
半角スペースは続けて使うと一つにまとめられちゃうのだ
256 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 10:19:21 ]: テスト
あああ
257 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:41:28 ]: interaface Param{
}

interface Ai{
　doHoge(Param param);
doFuga(Param param);
}

interface AITarget{
　setAi(Ai ai);
Param createParam();
}

class Character implements AITarget{
}
258 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 00:52:10 ]: >>256
これは専ブラが半角スペースをユニコードに変換するタイプなんでおｋなんだよ
259 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 09:53:49 ]: キャラクターなんていうデカイ括りがなんで必要なのかわからん
まずキャラクターありきでデザインするのよそうよ
260 名前：デフォルトの名無しさん [2007/03/02(金) 21:48:08 ]: 今回初めて Visitor パターンを使ってみようと思ったんだけど、
Visitor パターンって巡回順(次のaccept) は、Element に書いた方が、巡回順が再利用できていいと思うんだよね。
でもそうすると、巡回終了処理用のメソッドが欲しくなる。

結城さんの本しか見たことがないんだけど、
この実装方法は、正攻法？　邪道？

ex)
public void accept(Visitor vis) {
　　vis.visit(this);
　　Iterator it = contents.iterator();
　　while(it.hasNext()){
　　　　((Element)it.next()).accept(vis);
　　}
　　vis.visitEnd(this); //← これのこと
}
261 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 23:54:31 ]: 最近はaspectあるからVisitor要らなくね？
262 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:40:04 ]: なわけないだろ。
aspectとかＤＩって害虫だろ。
そんな迷走してるより、
とっととクロージャ取り入れて、正常進化して欲しい。
263 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:47:05 ]: なわけないだろ。aspectとDIは本流だろ。
264 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 03:17:43 ]: AOP&DIの文脈でクロージャの話が出る理由が分からん。
265 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 07:14:09 ]: それが正常進化とも思えん
266 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:17:01 ]: クロージャはＤにもあるし、Javaにもいずれ実装されるからだろ。
267 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 15:14:26 ]: Javasist 系は、VM が後方互換のないバージョンアップをしたとき、
手の打ちようがないよな。
Aspect がうまい具合に言語仕様に入るなんてこともなさそうだしな。
268 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:52:16 ]: ランタイムでウィービングすりゃいいじゃん。
269 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 21:49:37 ]: 　　　　　　　　　　　２ちゃんで煽りながらデザパタ学習した池沼が

　　　　　　　　　　　古い話題を壊れたレコードのように繰り返すスレ
270 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:07:11 ]: ま
敢えて言うほどの事でもないがの
271 名前：269 mailto:sage [2007/03/14(水) 22:13:31 ]: こんなスレ未だに見てる奴が居る事実に感動
元お豆のｓずきさんかな
272 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 02:19:28 ]: たかひろくんのデザパタ幼稚園
273 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 10:43:46 ]: >>33の発言は間違い。
274 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 09:22:19 ]: ごふっ
275 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:59:37 ]: 質問です。
テンプレートメソッドパターンを適用しようとして気になったのですが、
ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう？
（内容が同じになるものが複数組あります）
内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、
このままでは冗長です。

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

使っているのはPHP5なので多重継承はできません。
276 名前：デフォルトの名無しさん [2007/03/26(月) 18:21:23 ]: age!
277 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:05:42 ]: ConcreteClassのユーザーから見て、
その「処理が同一だけど異なるクラス」とやらは
「全く同じクラス」にしてはいけないものなの？
278 名前：275 [2007/03/26(月) 19:18:30 ]: 微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。

例えば、
www.techscore.com/tech/DesignPattern/TemplateMethod.html
ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に
public class TanakasWoodCutPrint extends WoodCutPrint{}
と
public class SuzukisWoodCutPrint extends WoodCutPrint{}
の二つが同じ内容になってしまう、という場合にどうすれば良いのか？という事です。
279 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:00:25 ]: 木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？
280 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:44:58 ]: 差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。
もう一階層挟んだら綺麗にまとまったりしないかとか。
281 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:44:55 ]: メモリが必要になったときに一度だけ生成されて、それ以降の記述では
必ず最初に確保されたメモリが使われるようなパターンは何というの？

C++風に描けば

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

全部グローバル変数にすればいいんだろうけど、使わない領域は
確保したくないって時にやる（a が不要になったときは回収してもOK）
282 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:46:53 ]: >>281
しんぐるとんだろ？
283 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:49:00 ]: >281
Singleton
284 名前：275 mailto:sage [2007/03/27(火) 12:17:40 ]: >>279
>>275で書いた共通クラスというのはそういうイメージなのですが、
タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？

>>280
symfonyでモデルクラスをＤＢスキーマから自動生成後、
各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。
285 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 22:52:26 ]: っていうか、そのモデルは何を表してるモデルなのよ？
DBから生成されたものに後付で持たせたい機能って言う意味がわからん
モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな
286 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 23:18:27 ]: なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。
287 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 07:29:58 ]: >>280
まず、モデルの定義を明確にしろ。
・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、
・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。
後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。

次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。
版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、
cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。
具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。

ここで、テンプレートパターンを使う。
　　ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass
　　ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass
となるようにする。

もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、
同じConcreteStrategyクラスを生成して呼び出せば良い。
違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。

それだけの話ではないか
288 名前：２８７ mailto:sage [2007/03/28(水) 07:36:24 ]: >>280ではなく>>275
289 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:14:53 ]: symfonyってのをちらっと眺めた感じだと
＞・DBエンティティをそのまま表したクラス(状態)
どうもこっちみたいだから、
そもそも適用するレイヤを間違ってる説が有力。
290 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:51:39 ]: ODBMS屋乙。

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

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

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

>>287は、後者の立場から説明した。
291 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:58:15 ]: 補足：
前者の立場でも
　　DBMSエンティティ＝静的状態＝ドメインオブジェクト　
と呼ぶことがあるが、
オブジェクト指向本来のドメインオブジェクトは、後者。
292 名前：275 mailto:sage [2007/03/28(水) 12:42:19 ]: symfonyは一つのテーブルから二つのクラスを生成する。
テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる）
問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。
なのでそのクラスにそのデータを使うメソッドを書こうかと。

今、>>287の方法でやっていますがこれで良さそうです。
ありがとうございました。
293 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:31:09 ]: エンティティとデータアクセスオブジェクトが自動生成ってことか
データアクセスはデータアクセスに特化させる方がいいだろねー
クラスの「役割」のくくりを大きくすれば、計算からデータの編集、保存まで一緒くたに
するって考え方もアルンかもしレンガ、普通はもっと細分化するもんだ。

public　WoodCutPrintContext{

　　　public void doWoodCutPrint(){

　　　　　　Coodinator coodinator = getCoodinator();

　　　　　　Hanzai hanzai = coodinator.getHanzai();

　　　　　　DrawProcessor drawProcessor = coodinator.getCutProcessor();
　　　　　　hanzai = drawProcessor.draw(hanzai);

　　　　　　CutProcessor cutProcessor = coodinator.getCutProcessor();
　　　　　　hanzai = cutProcessor.cut(hanzai);

　　　　　　PrintProcessor printProcessor = coodinator.getPrintProcessor();
　　　　　　printProcessor.print(hanzai);
　　　}
}

public 田中君 implements Coodinator {
　・・・
}

public 鈴木君 implements Coodinator {
　・・・
}
294 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:34:25 ]: ×；DrawProcessor drawProcessor = coodinator.getCutProcessor();
○：DrawProcessor drawProcessor = coodinator.getDrawProcessor();

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

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

閑話休題

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

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

だが、俺はそこまで突っ込むつもりはない。
そんな事をいちいち調べるつもりはないし、
質問者も困惑するだけだからだ。
296 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 13:11:21 ]: >>293
つか、今気付いた。
おまいは TemplateMethod Patternを共用したい
という質問に対して、全然別の回答をつけている。
特に、クラスの命名がデタラメだ。

×× public　WoodCutPrintContext{ ... }
×　　public class WoodCutPrintContext{ ... }
○　　public class WoodCutPrintProcess { ... }
297 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 14:58:49 ]: ----------------------------------------------------------------------------
デザインパターンにおける Contextの用例

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

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

----------------------------------------------------------------------------
>>293のクラス名 WoodCutPrintContext は、
クラスの役割を表現しておらず不適切な命名と言える。
298 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 15:32:52 ]: ----------------------------------------------------------------------------
デザインパターンにおける Contextの用例【追加と訂正】

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

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

----------------------------------------------------------------------------
もしかして >>293は、
　　鈴木、田中＝＝ StrategyパターンのConcreteStrategyクラス、
　　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス)
と言いたかったのか？
だが、それでは
　・鈴木と田中が同じ手順(Strategy)で版画を彫る　
　・鈴木が田中の手を借りて版画を彫る
が全く同じ表現になってしまう。これは不適切だ。
299 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 16:59:49 ]: ↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。
「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。
300 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:43:29 ]: ■>>293の表現　「鈴木が田中の手を借りて版画を彫る」

/* >>293のコード　　　　　　　　　　　　　　　　　　　　*/
public class 鈴木君 { // ConcreteStrategy
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　// 鈴木君はコンテキストを使って版画を彫る。
　　// 注：　鈴木君のコンテキストには手配師へのコネがあり、
　　//　　　　手配師は、仕事の各工程をメンバーに適当に割り振る。
　　WoodCutPrintContext context
　　　= WoodCutPrintContext.getinstance();
　　// 鈴木君は、寄せ集めメンバーがバラバラに各工程を担当した
　　//　ツギハギ細工を、自分の成果として公開する。
　　return context.doWoodCutPrint();
　}
}

　　　　　　　↓

/* 「手配師が田中君しか集められなかった場合」の *
　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/
public class 鈴木君 {　// ConcreteStrategy
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　// 田中君を拉致る
　　田中君 agent = 田中君.getInstance();
　　// 田中君に強制労働させ、成果を横取りして提出する。
　　return agent.createWoodCutPrint();
　}
}
301 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:44:38 ]: ■正しい表現「鈴木と田中が全く同じやり方で版画を彫る」

public class 鈴木君 {
　// 鈴木君には版画を彫るスキルがある。
　public WoodCutPrintStrategy getWoodCutPrintStrategy() {
　　// 鈴木君のスキルは、一般にAと呼ばれるスキルである。
　　return WoodCutPrintConcreteStrategyA.getInstance();
　}
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　// 鈴木君は自分のスキルで版画を彫り、成果を提出する。
　　return getWoodCutPrintStrategy().doWoodCutPrint();
　}
}
302 名前：デフォルトの名無しさん [2007/03/29(木) 18:00:19 ]: >>300
バグを発見しますた。
鈴木君の一人プロジェクトが無限ループを起していて
いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ

/* 「手配師が鈴木君本人しか集められなかった場合」の *
　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/
public class 鈴木君 {　// ConcreteStrategy

　// 版画を彫る
　public Hanzai createWoodCutPrint() {

　　// 鈴木君が自分を拉致る
　　鈴木君 agent = 鈴木君.getInstance();

　　// 鈴木君はいつものようにメンバーに強制労働をさせて、
　　// 成果だけ横取りするつもりだったが、
　　// 結局自分一人では何もできずに
　　// 貯え(VMスタック)を消費しつくして終了
　　return agent.createWoodCutPrint(); // 無限ループで　throw RuntimeException("スタックオーバフロー")
　}
}
303 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 18:38:56 ]: エロゲで使われているパターン

Singleton

他なんかある？
304 名前：300 mailto:sage [2007/03/29(木) 18:52:15 ]: >>302
バグｽﾏｿ( ; -_-)
>>294版鈴木君の等価コードはこうだ。

public class 鈴木君 {　// ConcreteStrategy
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　/* 以下、手配師付き変形TemplateMethod(ｺﾝﾃｷｽト)内の等価ｺｰﾄﾞ */ //{
　　　// 鈴木君は手配師を呼ぶ。(メンバー一人の場合、自分が手配師になる)
　　　Coordinator slave = this;
　　　// 手配師に各工程担当者を集めさせて、
　　　// 版材を準備し、版材処理を実行する。
　　　Hanzai hanzai
　　　　= slave.getCutProcessor().cut(
　　　　　　slave.getDrawProcessor().draw(
　　　　　　　slave.getHanzai()));
　　　// 版材を刷る。
　　　slave.getPrintProcessor().print(hanzai);
　　//}
　　return hanzai;
　}
　public Hanzai getHanzai() { reuturn new Hanzai(); }
　public 切り方 getCutProcessor()　 { return 切れ方_0893D.getInstance(); }
　public 書き方 getDrawProcessor() { return 書き方_1919Z.getInstance(); }
　public 刷り方 getPrintProcessor()　{ return 刷り方_0212A.getInstance(); }
}
// Functorパターン
public class 切り方_0893D extends 切り方 { public Hanzai cut(Hanzai hanzai) { /* 何もしない */ } }
public class 書き方_1919Z extends 書き方 { public Hanzai draw(Hanzai hanzai) { /* 何もしない */ } }
public class 刷り方_0212A extends 刷り方 { public Hanzai print(Hanzai hanzai) { /* 何もしない */ } }
305 名前：デフォルトの名無しさん [2007/03/29(木) 19:46:45 ]: まとめると、

>>275＝>>284の質問(>>292で解決済)
　テンプレートメソッドで、処理が同じものがある場合に、
　(注：同じなのは、TemplateMethod単位か、個々のメソッド単位か不明)
　どのようなクラス設計をしたら良いか？
>>279-280、>>285-290の回答
　TemplateMethod単位で同じものがあったら、
　それをStrategyパターンで外出しして共用すれば良い。

※ここまではOK

>>293の回答
　TemplateMethodの個々のメソッド単位で同じものがあったら、
　それをStrategyパターンで外出しして共用すれば良い。

※>>293の実装コードは
　　ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割
　　Coordinatorインタフェースを割り付けている点がおかしい。
　　鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。
306 名前：305 [2007/03/29(木) 19:47:36 ]: >>293の実装コードの問題点

分析/設計で得たモデルの特性として、
「手順を構成する複数の工程について、
　各工程の処理方法にバリエーションがあり、
　なおかつ、各処理方法は互いに交換可能」
な事が明らかならば、>>293の実装もありえる。

しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、
不吉な匂いがする。・・・数100人月のシステムで、
このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。

どのような場合にこの実装/設計が破綻するかと言うと、
設計/初期実装に見落としがあって、
Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合
である。この場合、Hanzaiインタフェースのバリエーションに関して、
各処理方法は互いに交換可能でなくなる。

正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは
なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ～
307 名前：デフォルトの名無しさん [2007/03/29(木) 20:14:36 ]: デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。

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

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

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

それでは、正しい解決方法はどこにあるのか
それを私は知っているが、このレスにはもう余白がないので書けないｗ
308 名前：鈴木 [2007/03/29(木) 22:31:38 ]: おまいら、俺の名前を気安く使うな、不愉快だぞ
続きは「佐藤クン」で
309 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:37:17 ]: 上がダメなら、下の名前ならおｋ？

例えばひろゆきとかゆきひろとかたかゆきとかあと
310 名前：デフォルトの名無しさん [2007/03/29(木) 22:49:30 ]: 問題はドメイン・モデリングの欠落だなｗ
311 名前：デフォルトの名無しさん [2007/03/29(木) 22:55:01 ]: 問題領域が「版画作成」なら、最終目的は「版画」だけど、
問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ～よなｗ
つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話
312 名前：デフォルトの名無しさん [2007/03/29(木) 22:57:26 ]: 「業務処理」の目的は、DB更新と電文(w。
313 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:58:09 ]: >>312
それはありえん
314 名前：鈴木 [2007/03/29(木) 22:59:24 ]: >>309
それもダメだ、かすってる

鈴木の続きは「都築」でどうだ
315 名前：デフォルトの名無しさん [2007/03/29(木) 23:03:13 ]: >>314
じゃニックネームで手を打とうぜ。

例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ
316 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:05:28 ]: >>309、>>315
　見事なまでのプロダクトラインだなｗ
317 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:07:17 ]: 閑話休題
318 名前：デフォルトの名無しさん [2007/03/29(木) 23:10:48 ]: >>312
ある種の基幹系業務システムは、
構築難易度を下げて抽象化すると、
結局、マスタメンテ型アプリに帰着する。

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

（終了）
319 名前：デフォルトの名無しさん [2007/03/29(木) 23:13:24 ]: )再開(
320 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:17:09 ]: GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ
321 名前：デフォルトの名無しさん [2007/03/29(木) 23:17:18 ]: ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。
322 名前：デフォルトの名無しさん [2007/03/29(木) 23:22:56 ]: >>321
M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。

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

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

なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆
323 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:29:25 ]: >>322
特に無い。
324 名前：デフォルトの名無しさん [2007/03/29(木) 23:38:44 ]: >>320
確かに飽きてきたのも事実
だが使いこなせてる奴が意外と少ないのも事実
325 名前：デフォルトの名無しさん [2007/03/29(木) 23:45:29 ]: だが使いこなせてる奴は１０年前から退屈してるのも事実
326 名前：デフォルトの名無しさん [2007/03/29(木) 23:49:47 ]: 2PLoP (2ch Pattern Language of Programming)報告：
Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、
まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。
彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。
トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、
Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。

　　　　　pc11.2ch.net/test/read.cgi/tech/1172431242/
327 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:56:05 ]: 糞コード放置してった >>293は
今どこで野垂れ死んでいることやら
328 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:05:24 ]: >>326
Pythonというか、いわゆる軽量言語にデザパタはいらんのじゃないかなぁ。
大規模開発にはそもそも向いてないでしょ。
もしかしたら、オブジェクト指向すらいらないかもしれないし。
馬鹿にして言ってるのではなくて、住み分けがあるだろうと。
大規模開発は javaなり c++ なりでデザパタを使って書けばいいし、
身近なユーティリティーを書くなら、軽量言語というか
perlででも書いた方がいいし。
大規模開発に向かん言語で、デザパタっていっても
そもそも意味がないと思うんだな。
329 名前：デフォルトの名無しさん [2007/03/30(金) 00:14:09 ]: >>328
常識的な意見ってツマンナイよ
rubyからrailが生まれたし、javascriptからAJAXが生まれた
そんなご時世なのだ
330 名前：デフォルトの名無しさん [2007/03/30(金) 00:18:07 ]: >>328
マジレスするぞ。
Pythonは関数言語的機能のほかに、
metaclassシステムやら、動的言語の性質をあちこち持ってるから、
C++やJavaよりよっぽどSmalltalk寄り。

そこにあろうことかJava版GoFを移植したってのが笑い所。

あと、後半部「ボトムアップでパターン抽出」
これは別に間違ってないだろ。
むしろ、将来Javaに取り入れるべき言語機能やパターンを
発見できるかもしれない(もう金脈は小さいと思うけどな)。

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

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

パターン関係ないチラ裏ｽﾏｿ
332 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:26:57 ]: >C++やJavaよりよっぽどSmalltalk寄り。

て言われても、Smalltalk てそんなにいいのか？
動的言語と言われた時点で、うーみとなりそうだけどなぁ。
型は、事前に論理的誤りを検出するためにあるんだぜ？
それを最初に省いたら、あとから泣きみるだろ。
それでデザパタが必要とされるような大規模開発に
向いてるといえるのだろうか？
333 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:27:09 ]: > OOは大規模開発向け

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

済まないが、実績作ってから言ってくれ
おまいらの作ってるのはOOじゃねぇだろ
単にOO系言語でOOP風の事をしました（でも中身はCOBOLそっくり）
だろ
334 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:28:45 ]: >>232
あぁーあ。今度はCS系関数言語厨房か。
マイクロソフトリサーチの人が
なんとかしてくれるだろ。
335 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:29:28 ]: > デザパタが必要とされるような大規模開発

どっから出てきた妄想ですか？
336 名前：デフォルトの名無しさん [2007/03/30(金) 00:31:22 ]: すげぇずうずうしさだなコイツ

>>306-307, >>310-312, >>318で
大規模(自称)OO開発の失敗例
ケーススタディしたばっかだっつうのに、
解決策も出さずに「大規模OO開発」かよ。
337 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:32:59 ]: なんだよ、Py厨だけじゃないのかよ。
てか、py厨が引っ掻き回してるのか？

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

実際、それ以上でもそれ以下でもないし。
338 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:36:10 ]: 何この盛り上がりようｗ
341 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:37:31 ]: たかびー祭＋ﾋﾟﾁｮﾝﾊﾟﾀｰﾝ祭　合同イベント
342 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:40:04 ]: おいおまいら騒ぐな

> 大規模OOにデザパタ必須
って言ってる人の大規模は、
せいぜい数千行～数万行ぽっちの事だぞ、きっと
343 名前：333=336 mailto:sage [2007/03/30(金) 00:42:56 ]: >>328

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

火ぃ噴くのは、プログラムもろくにできないのが
数十人単位で集まっちゃうような地獄の話だからｗ
344 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:44:49 ]: なんなんだよ、この盛り上がり。
そんなにヒマがあるなら、その、なんだ、Pythonのその膨大な過去の
素敵なコードの資産から、スマートなパターンを抽出して、
俺らをあっと言わせてくれよ。
もう、ずいぶん作業は進んでるんだろ？
ここで威張ってるぐらいなんだから。
345 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:46:34 ]: >>344
/~ytakagi/ に直接言え。
もっとも連絡先も書いてねぇけどｗ
346 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:48:29 ]: 盛り上がってもいいけど、もっと具体的な話してくれ。
抽象論は聞き飽きた。
347 名前：293 mailto:sage [2007/03/30(金) 00:50:44 ]: 物凄いレス着いたｗ

>>295
PHP５＋symfonyなんてしらね

>>296-297
で座ﾊﾟﾀなんてクソ喰らえｗ

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

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

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

っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ
348 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:50:51 ]: 一体何を聞きたいんだ？

・ソフトウェア・プロダクトラインのための資産管理
・大規模開発へのOOおよびデザパタ適用の是非
・そのほか
349 名前：デフォルトの名無しさん [2007/03/30(金) 00:54:30 ]: とりあえず、>>293は
・話の発端(PHP5+symfony)も見えてないし
・クラス命名のセンスもないし
・クラス設計のセンスもないし
・等価コードの意味も理解できないし
・目が悪くて人の話も聞かない
奴である事だけはかろうじて理解できた

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

お前はシャレも解せぬ不粋な人間だと理解した
351 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:00:00 ]: >　っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
>　ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ

はいはい釣れた釣れた
352 名前：293 mailto:sage [2007/03/30(金) 01:09:32 ]: 終わりか？
＞・クラス命名のセンスもないし
＞・クラス設計のセンスもないし
それは否定できんなｗ
ほいじゃーね
353 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:09:50 ]: 思い切り東陽町スタイルだな。あの糞コード
354 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:11:19 ]: > public　WoodCutPrintContext{

単にソースコード保守するだけの
運用チームじゃないかな、彼は
355 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 15:41:55 ]: >>293の元設計の問題点

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

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

つづく
356 名前：293 mailto:sage [2007/03/31(土) 00:03:16 ]: >>293から50レス以上あって
くだらない能書きは大量に吐き出されたが
もっと良い解決方法を提示するコードが出てこないとはｗ
所詮は口だけ、本を読んだだけの頭でっかちで現場で使えん奴らばかりだなｗ
コリャデスマがなくならないわけだ
357 名前：デフォルトの名無しさん [2007/03/31(土) 02:06:50 ]: お前のコードの問題点は示しただろ？すずき
358 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:55:10 ]: >>356
一応いっておくが、おまいに絡んでるのはキチガイ一人だけだ。
359 名前：デフォルトの名無しさん [2007/03/31(土) 11:48:32 ]: >>358
議論しているのをキチガイ呼ばわりする奴って
どこにでもわくのな
360 名前：デフォルトの名無しさん [2007/03/31(土) 11:52:26 ]: 【ひろたかと２ちゃんの不思議な関係】

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

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

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

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

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

さ～て、また荒しが発生するのかなｗ
361 名前：293 mailto:sage [2007/03/31(土) 12:56:20 ]: >>358
そういわれるとちょっと寂しい気も・・・ｗ
>>357,359
議論になってな（ｒｙ
>>360
「いまココ」ってところで、「ひろたか」が「たかひろ」になってるってことか・・・ｗ
362 名前：デフォルトの名無しさん [2007/03/31(土) 13:15:59 ]: >>361
議論になっていないと考える低脳はお前だけだ
363 名前：293 mailto:sage [2007/03/31(土) 13:27:20 ]: だってボク低脳ですから
364 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:55:01 ]: くだらねえことをいつまでもグダグダ書いてるが、>>275の問題の本質は
「テーブルとクラスをどうやってマッピングするか」ってところにあることに気づけや。
マッピング後のクラス設計以前の問題。

んでhibrenateとか見る限り、今のところ碌なやり方は存在しない。
366 名前：デフォルトの名無しさん [2007/03/31(土) 13:59:48 ]: うっせぇぞ低脳。

お前はさっさとODBMS営業逝ってこいや
負け犬が
367 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:03:10 ]: ODBMS（ｗ

ぷぷぷ

もう10年前にたかひろの子分に
「(製造業など一部の特殊分野を除いては)
　仮想記憶方式のODBMSなんてもう売れねぇよ」
って伝えたはずだけど。まだ悪あがきしてたんか。おめでてぇなｗ
368 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:10:47 ]: そん時に提示した代替手段が、
・ ORマッピングによるRDBMSとの共存
・ Stonebreaker氏のORDBMSの発展
だったな。
369 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:41:39 ]: >>293の元設計の問題点(つづき２)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

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

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

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

　　　　しかし>>293,>>304のコードでは、
　　　　データ(Hanzai及びﾊﾞﾘｴｰｼｮﾝ)と処理方法(～Processor)を別々のクラスに分離記述した後、
　　　　関連するデータクラスと処理クラスを適切な方法で再カプセル化しなかったため、
　　　　オブジェクト指向のメリットが得られなくなっている。(非ＯＯ的コード)
370 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:59:40 ]: >>355、>>364、>>369
その問題点を直したスケルトンコードを頼む
371 名前：293 mailto:sage [2007/03/31(土) 15:13:25 ]: >>365が僕の考えからは少し極端な意見だがいいこと言った。
まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに
とらわれないコードを書いたんだがね。
自分のレスの後だったんでよっぽど悔しかったんだろうｗ。
だが少しだけ付き合ってあげようｗ

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

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

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

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

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

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

となるのが自然な設計だと思うけど？
372 名前：365 mailto:sage [2007/03/31(土) 15:25:41 ]: >>371
キチガイにかまわないであげてください。
373 名前：293 mailto:sage [2007/03/31(土) 15:34:06 ]: >>372
むむ・・・
スレが荒れてしまいますな・・・
まぁ彼が言うクラス粒度が細かくなりすぎると見通しが悪くなるのは事実だけどね
その辺の加減が難しい・・・
374 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 15:51:23 ]: 　-- 引き続き、元質問者(>>275) の挙げた例題(>>278) を題材に､ --
　-- デスマ現場で発生した問題 (>>306-307) を論じる｡　　　　　　　--
375 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 15:53:01 ]: >>293の元設計の問題点(つづき２)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

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

　　　　まず、データにはバリエーションがある。
　　　　例えばデスマ事例(>>306-307)で指摘されているように、
　　　　操作対象となるオブジェクト/データ(Hanzai)は一種類ではなく、
　　　　実際には何種類ものバリエーションが存在する。(分析モデル)
　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版
　　　　　　　　　　 │　　　　　　　　 │　　　 └ 硬い木版
　　　　　　　　　　 │　　　　　　　　 ├ ゴム版
　　　　　　　　　　 │　　　　　　　　 ├ 芋版
　　　　　　　　　　 │　　　　　　　　 └ 銅版
　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai
　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai
　　　　　　　　　　 └ 完成した版画版
　　　　　※ ここでHanzaiのサブクラスは、
　　　　　　工程進行に伴う状態変化 (原料→下絵中→切除中→完成) と見なせる。
　　　　　　ただし、後工程になるほどデータの内部構造は複雑になっていく。
　　　　
　　　　次に、データはしばしば単純なモノシリック構造ではなく、
　　　　複数のデータを内部構造として持つComposite構造を持つ。
　　　　　完成した
　　　　　　版画版 ◇┬ 背景部 ◇─(略)
　　　　　(人物画)　　└人物部 ◇┬ 頭髪
　　　　　　　　　　　　　　　　　　　　├ 顔　 ◇┬ 目
　　　　　　　　　　　　　　　　　　　　│　　　　　├ 鼻
　　　　　　　　　　　　　　　　　　　　│　　　　　└ 口
　　　　　　　　　　　　　　　　　　　　├ 上着
376 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 15:59:12 ]: 　　　　当然のように、処理もこのComposite構造の対応している必要がある。
　　　　　人物画のゴム版画の為の
　　　　　切除処理 ◇┬ 背景部 ◇─(略)
　　　　　　　　　　　　　└人物部 ◇┬ 頭髪パターン切除
　　　　　　　　　　　　　　　　　　　　　├ 顔　 ◇┬ 目をリアリスティックに表現する切除
　　　　　　　　　　　　　　　　　　　　　│　　　　　├ 鼻の膨らみを表現する切除
　　　　　　　　　　　　　　　　　　　　　│　　　　　└ 口の生々しさを表現する切除
　　　　　　　　　　　　　　　　　　　　　├ 毛皮パターン切除

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

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

　　　　これが現実世界の共用だ。
377 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:11:43 ]: 御託はいらん
読む気も無い
378 名前：デフォルトの名無しさん [2007/03/31(土) 16:12:41 ]: 【そして、現実の世界へ・・・】

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

>>293のコードは、精神性疾患患者たかひろが、その劣悪なる知能で設計し
その結果デスマを巻き起こしたコードと極めて類似している。
したがって、>>293の詳細な分析は、デスマ事例コードへの解決策を与えるのである。
379 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:39:53 ]: いまごろ解決しても、お前の頭がおかしくなったのはもとには戻らん。
あきらめろ。
380 名前：ﾜﾛｽ [2007/03/31(土) 16:46:39 ]: ｢版画の世界｣から、｢デスマ・システム｣への概念マッピング（・∀・）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　【版画作成アプリ】　　　　　　　【マスタメンテ型基幹システム】
[主要ドメイン] 版画作成プロセス　　　　　　　マスタ更新プロセス
[主要データ]　下絵、原料版材　　　　　　　　入力 (画面入力,電文入力)
　　　　　　　　　完成した版画版　　　　　　　　出力 (ＤＢ更新,電文出力,)
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 (付帯的な画面出力)
[主要プロセス]版材取得　　　　　　　　　　　　入力取得
　　　　　　　　　下絵作成　　　　　　　　　　　　入力取得
　　　　　　　　　版材の品質チェック　　　　　　入力チェック
　　　　　　　　　下絵と切除テクのマッチング　業務チェック
　　　　　　　　　切除処理　　　　　　　　　　　　ＤＢ参照、演算処理、ＤＢ更新
　　　　　　　　　印刷処理　　　　　　　　　　　　出力処理 (画面出力,電文出力)
381 名前：デフォルトの名無しさん [2007/03/31(土) 16:49:08 ]: 【たかひろと２ちゃんの不思議な関係】

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

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

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

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

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

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

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

　という事実にある。

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

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

　悔い改めよ。そしてお前が迷惑をかけた人、一人一人に許しを乞え。
383 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:00:02 ]: 荒しはスルーするとして。

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

すると主要ドメインはあくまで業務処理プロセスであって、
マスタ更新プロセスではない。
384 名前：デフォルトの名無しさん [2007/03/31(土) 17:08:41 ]: >>379
たかひろ、お前が壊れているのは最初から知っている。
お前が壊れた設計をしていたのにも、１週間と待たずに気付いた。
当然の事ながら、問題の解決策もすぐに判った。

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

謙虚になれ、たかひろ。
お前はお前が思っているのの１/１００も有能ではない。
単なる空っぽの本棚だ。お前の頭は
385 名前：375 mailto:sage [2007/03/31(土) 17:16:39 ]: >>375の分析モデルがズレたので、再投稿
------------------------------------------------------------
　　　【版材の分析モデル】

　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版
　　　　　　　　　　　　 │　　　　　　　　　　　 │　　　 └ 硬い木版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ ゴム版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ 芋版
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 銅版
　　　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai
　　　　　　　　　　　　 └ 完成した版画版
------------------------------------------------------------
386 名前：375 mailto:sage [2007/03/31(土) 17:17:57 ]: あれ？まだずれてる。

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

　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版
　　　　　　　　　　　　 │　　　　　　　　　　　 │　　　　　　└ 硬い木版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ ゴム版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ 芋版
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 銅版
　　　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai
　　　　　　　　　　　　 └ 完成した版画版
------------------------------------------------------------
387 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:53:08 ]: >>383

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

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

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

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

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

だが今時の新システム構築なんて、大抵中身はマイグレーション。
COBOLプログラマがプログラムの動きを日本語で説明して「設計書でござい」
なんて言い出すおバカな世界だからなぁ・・・
388 名前：デフォルトの名無しさん [2007/03/31(土) 17:54:57 ]: >>365
さて、そろそろORマッピングスレを爆撃に行くかｗ
389 名前：369 [2007/03/31(土) 19:59:13 ]: バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

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

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

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

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

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

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

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

　　確認作業はコーディング能力のある人にしか実行できないが、
　　それは致し方ない所だろう。
390 名前：369 (>>389つづき) [2007/03/31(土) 19:59:56 ]: バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

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

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

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

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

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

２．動作主体が「鈴木君」や「田中君」であり、
　　プロセスは >>293の最初のクラス＝WoodCutPrintProcessクラスである。
391 名前：369 (>>389つづき) [2007/03/31(土) 20:05:01 ]: バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

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

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

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

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

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

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

　　(なおこのクラスの名称 "WoodCutPrintContext"は、内容を適切に表していない。
　　正しくは、"WoodCutPrintProcess"と命名するべきである。根拠は>>297 参照)
392 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:06:02 ]: たかひろがバカなのは判ったから
とにかく sageを覚えろ
393 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:18:05 ]: あらあら、よく見たらアイツ
またまた敗走宣言してるやん >>379

ﾜﾛｽ
394 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:19:51 ]: >>380
GJ！

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

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

----------------------------------------------------------------------
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング part2
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　【版画版作成アプリ】　　　　　　【マスタメンテ型基幹システム】
[主要ドメイン]　　版画版作成プロセス　　　　　　　マスタメンテ・プロセス
[主要データ]　　　版材原料　　　　　　　　　　　　入力 (画面入力データ)
　　　　　　　　　下絵　　　　　　　　　　　　　　ＤＢ参照データ
　　　　　　　　　加工中の版画版　
　　　　　　　　　完成状態の版画版　　　　　　　　出力 (ＤＢ更新データ)
　　　　　　　　　刷り上がった版画　　　　　　　　表示 (画面表示データ)
[主要プロセス]　　版材原料取得　　　　　　　　　　入力取得
　　　　　　　　　版材作成　　　　　　　　　　　　入力チェック
　　　　　　　　　下絵取得＆下絵処理　　　　　　　業務チェック, ＤＢ参照
　　　　　　　　　切除処理　　　　　　　　　　　　演算処理, ＤＢ更新
　　　　　　　　　印刷処理　　　　　　　　　　　　画面表示
----------------------------------------------------------------------
修正結果を見ると、両者の対応関係はそんなには悪くない。
むしろ、別物にしてはずいぶん良い対応関係を持っている、と言える。
395 名前：394 AAズレ修正 mailto:sage [2007/03/31(土) 20:35:49 ]: ----------------------------------------------------------------------
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング ver.2
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　【版画版作成アプリ】　　　　　　　【マスタメンテ型基幹システム】
[主要ドメイン] 版画版作成プロセス　　　　　　マスタメンテ・プロセス
[主要データ]　版材原料　　　　　　　　　　　　　入力 (画面入力データ)
　　　　　　　　　下絵　　　　　　　　　　　　　　　　ＤＢ参照データ
　　　　　　　　　加工中の版画版　
　　　　　　　　　完成状態の版画版　　　　　　　出力 (ＤＢ更新データ)
　　　　　　　　　刷り上がった版画　　　　　　　　表示 (画面表示データ)
[主要プロセス]版材原料取得　　　　　　　　　　入力取得
　　　　　　　　　版材作成　　　　　　　　　　　　　入力チェック
　　　　　　　　　下絵取得＆下絵処理　　　　　　業務チェック, ＤＢ参照
　　　　　　　　　切除処理　　　　　　　　　　　　　演算処理, ＤＢ更新
　　　　　　　　　印刷処理　　　　　　　　　　　　　画面表示
----------------------------------------------------------------------
396 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 02:18:44 ]: ある意味すごいなｗ
未だにコードが出てこないし解釈間違ってるけど、このエネルギーはスゴイ。
便所の１００ｗと比喩してはいけないｗ
397 名前：396 mailto:sage [2007/04/01(日) 05:00:48 ]: スマソ　誤爆した
398 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 07:01:05 ]: まあまあ
元々の質問はもうとっくにクローズしてるし、
>>293はjavaとよく似た擬似コードで記述されたクラス設計に過ぎんから、
代替コードを示す必要もない。

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

理解できないなら結論が出るまで静観するがよろし
399 名前：デフォルトの名無しさん [2007/04/01(日) 08:41:27 ]: このスレ、爆発力はあるな
問題は火のつけ方
400 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 09:44:28 ]: >>397
ﾅﾆｺﾚｗｗ
勝手に誤爆にするなよｗｗｗ
>>397-398
おまいウザイから別にスレ立て手やれよ
401 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 09:52:28 ]: あとそんなに自分の主張に自信があるなら
コテつけてレスしろ
402 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 10:38:41 ]: >>400-401 またスレ荒しか
403 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 10:40:13 ]: おまぃはバカなんだから黙っとけ
404 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:38:31 ]: いやさ、例の「精神性疾患の俗称連呼」の人、
別スレで暴れまくっててえらい騒ぎになってるわ。

どうも東京都在住の４４歳の人物らしい。
４４歳にもなって２ちゃん三昧とは幼いね。
405 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:50:51 ]: リアルワールドが悲惨なんだよ、きっと
406 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 17:02:21 ]: よしよし
407 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:05:17 ]: NGワード推奨：キチガイ
408 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 19:09:37 ]: 某スレで、コーディング能力も設計能力も疑わしい４４歳の人が
「擬似コードを元にした議論はよくねぇ～」とか叫んでて笑えた。
「print文入れて動作を見ればいい」ってそれなんて名前のBASIC言語？ｗ
409 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 20:54:04 ]: なんと言う春休み。
思わず読み飛ばしてしまった。
このスレはしばらく伸びる。
410 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 21:05:50 ]: >>409
荒しに来たのなら、帰ってくれ。
411 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 02:42:25 ]: こっちが平和になったと思ったら
今度はあっちで暴れてたんだな
pc11.2ch.net/test/read.cgi/tech/1172431242/
412 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 14:16:56 ]: >>407
自分がそれだから、そうやって相手を封じたい訳ね。
ま、相手なんてお前の脳内にしか居ないんだけど（藁
413 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 14:25:05 ]: 誤爆？
414 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 14:50:04 ]: >>412
おまえが自己の行動に無自覚な精神障害者である事はよくわかった。
415 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 14:56:12 ]: ここのスレ主はそろそろ鉄格子付き個室病棟の中か。

頭も性格も悪いスレ主に意見すると
ひたすら泥沼に引きずり込もうとあがくから
始末が悪い。
416 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 15:56:32 ]: スレ主は、ＯＯやデザパタに対して、狂信的な宗教感情を持っている。

その信仰はあまりにも愚かで盲目的であり、
自身の独自解釈とは異なる意見を持つ者に対して
狂信的信者の狂ったな正義感を持って攻撃と排除を試みる。
しかし、世の中に広く受け入れられる技術ノウハウというものは、
そのようなカルト的宗教活動とは一切無縁のものである。
417 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 16:08:13 ]: 個人的な技術ノウハウの蓄積は、
　・日々の実践と経験を通じた、メンタルモデルの形成
　・合理的思考による、メンタルモデルの検討と洗練
　・明確な目的意識に基づく、合目的なノウハウの抽出と洗練
を通じて行われる。

そして世の中に広く受け入れられる技術ノウハウというものは、
個々人のノウハウを、他の専門家を交えた健全な議論に晒し、
目的と手段の合理性を詳細に検討し、
その過程で多くの人々が同意し共感する事を通じて、
初めて成立するものである。
418 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 16:28:04 ]: 注：誤解のないように注記しておく。

ここでスレ主とは、今回のスレを立てた人物の事ではなく
関連スレのど真ん中に居座り、罵詈雑言を撒き散らしては議論妨害を繰り返す、
牢名主のような人物の事である。
419 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 19:28:31 ]: GoFってなんて呼べばいいの？
個人的にはゴフって読んでるんだけど、公の場で使ったら笑われたりする？
420 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 19:37:48 ]: >>419
情報処理用語の読み方を確認するスレ
pc8.2ch.net/test/read.cgi/tech/1056173956/670

　670 ：デフォルトの名無しさん：2005/05/16(月) 20:02:16
　　GOFはともかくGoFはゴフと読んでる。
421 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 20:33:32 ]: ｺﾞﾌｺﾞﾌ
422 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 22:39:06 ]: 護符としての効能はあるんだろうか？
423 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:00:50 ]: 　　　　　　__
　　 i＜´ 　 }＼　 ,　- 、
　　　ヽ.._＼./　 .ﾝく　r-兮、＿_
　　　 ∠｀ヽ.!　/ 　ヾﾆEｦぐ　,ゝ-＞　　　　さすがGoFだ。
　　　/＿｀ｼ'Ｋ-───‐-､l∠ イ　　　　ﾃﾞｽﾏくらっても
　　　l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤ 　　　　　何ともないぜ。
.　　 l'___|⌒ヾ''ｰ＝=､ｰr='ｲ　ｉ二| 　　　　　
　　　/　.｣　　 i　　 /./7r‐く　 lー!
.　　ｆ.　　ヽ‐ｉ人.∠'＜　＿i. l,.-ゝ.
　　ﾄiﾍﾍ｢ﾄ〈　　　　｀X　　ﾄﾚi7__|
　　　〉ﾄ:ﾄﾊj｀! i.　　　 /　ﾄｰ┤lﾙj,ﾘ
　　/‐+----+‐l　　 iｰ--i---ヾ'〃
.　ｌ＿i＿＿__i__|　　 |＿__i,＿＿i_|
424 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:57:18 ]: 荒らしは帰ってくれ
425 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 20:59:35 ]: あっちの隔離スレ、すげぇ荒れようだな。

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

狂信者って本当に怖いね。
426 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 00:52:40 ]: ｲﾀｲ････
427 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 00:56:10 ]: pc11.2ch.net/test/read.cgi/tech/1175959706/
428 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 09:39:44 ]: State パターンで相談です。各 State クラス間でコンテキストを共有したい
場合に、相互の依存度を下げるにはどういったイディオムが使えますか?

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

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

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

あるいは、こういう場合にはそもそも State パターンは使わないとか、
そういった指摘でもかまいませんので、よろしくお願いします。
429 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 09:47:55 ]: その前にStateパターンのクラスズをよく見て依存関係を
シッカリ把握しなさい
430 名前：428 mailto:sage [2007/04/21(土) 10:02:23 ]: >>429
問題にしているのは以下のような依存関係です。
Controller has a State
Controller has a Context
StateA is a State
StateB is a State
431 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:13:33 ]: >>430
私が問題にしているのは
＞各 State が興味があるのは Context の限られた一部分であり
です。
StateはContextに興味はありません。
432 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:26:13 ]: ハッタリ業務コンサルのデザインパターン解釈はダメダメだな
433 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:42:32 ]: まー独自解釈して苦しんでしまう事は初心者にはよくあることだから気にする必要は無いｗ
434 名前：428 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:48:50 ]: ContextがMediatorになるんじゃないの?
436 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:52:17 ]: WebApplicationやStrutsと同じジャマイカ
437 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:07:11 ]: 扱うデータの型や処理の型を問題にせずSharedDataでひとくくりにするから
概要設計レベルではContextで解決したつもりになっていても
詳細設計レベルで一気に破綻するんだろ。

ハッタリコンサル(初心者)の典型だな
438 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:12:12 ]: >>435
Mediatorで相互依存性を弱めるというのは正しい方向だが
それをContextと呼び続けるのは病気だ。
今ならDIだろ。
439 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:15:19 ]: いまどき概要設計/詳細設計かよ
440 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:17:17 ]: ハッタリコンサルはメーカ毎の工程名の相違に鈍感
OMGの工程名対応表でも見とけクズ
441 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:22:56 ]: いまどき工程かよｗ
442 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:27:07 ]: ハッタリが話題ずらしに必死だな
上空レベル、海面レベルとでも読み替えておけクズ
443 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:28:25 ]: >>435
> ContextがMediatorになるんじゃないの?

ContextではなくMediatorだろうな、
古臭いデザパタ厨房の妄想に合わせてやれば
444 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:29:48 ]: >>442
そりゃユースケースの話だろｗバーカｗ
445 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:31:11 ]: ハッタリ必死すぎるぞ

カプサイシン摂取過多でそろそろ拳銃乱射事件かｗ
446 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:33:12 ]: ハッタリコンサルの仕事：
奴隷コーダに一画面分のコードを書かせ、
それが複数画面で使いまわせると信じ込んで
詳細設計の雛形にする
447 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:35:53 ]: ハッタリコンサルの仕事２：概要設計
一画面分のコードで、データ類がContextにまとめられているのを見て、
Contextというクラスを作れば複数画面にも対応できるとはずだ
という妄想設計をすること。
448 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:37:09 ]: >>446
お、宗旨替えか？
そうだよSE/コンサルはコーダ以下なんだよｗやっと気づいたか
449 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:44:03 ]: >>448

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

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

例えば俺。
コーディングもできるし(あたりまえ)、
科学技術にも口出しできるし、
ダメコンサルを叩いて再起不能にする事もできる。
お前を今叩いているようにな
450 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:45:54 ]: ここで叩かれてボロボロになってるハッタリコンサルって、誰なの？
451 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:50:20 ]: ＞コーディングもできるし(あたりまえ)
コンプまるだしｗ
452 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:53:19 ]: ＞例えば俺。
日中カキコしまくりのヒキコモリが大企業のSE？ｗ
453 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:54:03 ]: >>450
各種情報を総合すると、こいつが本人らしい。
megalodon.jp/?url=http://pc11.2ch.net/test/read.cgi/tech/1172431242/626&date=20070410182152
454 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:56:16 ]: >>453
みっともねぇ～ないい歳こいた親父が
２ちゃんごときで必死になっちゃってｗ
仕事場でオナニー三昧２ちゃん三昧って
それなんていう引き篭もり部屋？
455 名前：428 mailto:sage [2007/04/21(土) 12:00:16 ]: うーん。Mediator だとクラスの数が増えてしまうので、ちょっとおおげさ
かなという気がします。コストとメリットがバランスしないというか。

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

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

C++ だし参照渡しでお茶を濁そうかなと思ったり。
456 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 12:06:18 ]: >>454
おめえは気の利いたこといってるつもりなんだと思うけど、
とにかくセンスが無さすぎる
457 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 12:06:31 ]: 妄想に基づく独自解釈をGoogleで探しても、適切な例が出てくるわけない。
StateパターンにおけるContextクラスの役割は約一ヶ月前に書いた通り。

お前の負けだ。観念しろ
458 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 12:08:07 ]: >>456
キチガイのセンスに合わせるのは難しいな
四流大学出はそういう会話が得意なんだろうけど。
459 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:21:07 ]: >>446
手足として使った奴隷コーダに強烈な恨みを買っているのが
ハッタリコンサルのダメダメな所。

「勝手に引き抜いて、変な仕事ばかり回してきて
　あのバカは一体何様のつもりだ？」
って泣いてたぜ、奴隷コーダちゃん
460 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:24:16 ]: >>459
そうそうｗ
そういえばあのコーダも使えなかったよなｗ
Javaのクラスはオブジェクトじゃない！とかわけのわからないこといってたしｗ
461 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:25:40 ]: >>460
そういえばあいつ、頭おかしくなって会社やめちゃったってなｗ
ヒキって２ｃｈばっかやってるらしい。
版画とかよばれてるしｗ
462 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:33:03 ]: >>461
ああ、あのゴミか
ほんと死ねばいいのにな
463 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:34:23 ]: >>462
同意ｗ
おれがあいつならとっくに吊ってるｗ
464 名前：デフォルトの名無しさん [2007/04/21(土) 13:34:37 ]: >>460
バカが発振し始めたな
デブのことだよハッタリ高弘ちゃん
465 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:36:25 ]: >>464
版画ﾊｹｰﾝ（版画風ｒｙ

うわきもｗ
466 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:36:31 ]: 早速スレに晒しときましたｗ
467 名前：デフォルトの名無しさん [2007/04/21(土) 13:39:24 ]: おいおまいら、アドレナリンは俺専用のオモチャだ
勝手にアドレナリンをいじるな
暇つぶしに適当な書き込みをするとすぐ怒り出すのでとても面白い
468 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:42:11 ]: >>467
強がりいってらｗあったまわりいｗ
469 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:42:51 ]: >>467
カプサイシンの間違いじゃねぇの
半島人臭いし
470 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:43:53 ]: ﾑｯｷｰ、ﾌｧﾋﾞｮｰﾝ(笑
471 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:45:29 ]: おいハッタリをあんま構うな
あまり追い詰めると
出身校(四流大)で拳銃乱射事件起こすぞきっと
472 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:46:34 ]: >>469
そうそうｗ
版画もちょっと煽るとすぐファビョるしなｗ
半島に帰れよｗ
473 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:47:38 ]: ハッタリ高弘の好物
キムチ餃子
474 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:48:59 ]: さぁーってと
昼休みのハッタリいじめはそろそろ飽きたし
四月の休日を満喫してくるか（←満喫に行くって意味じゃないよｗ
475 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:52:03 ]: 版画版画ってバカにすんな！！
Javaのクラスなんかオブジェクトのわけないだろ！

たしかにハッタリたかひろも俺も鮮人だが、それがどうした！
低脳どもが！
476 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:53:51 ]: ハッタリの成りすましはクオリティが低くて萎える
477 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:54:42 ]: GoF本って独習C++を一通りやった程度の知識で理解できますか？
478 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:54:51 ]: メモ：ハッタリは半島人
479 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:56:31 ]: >>478
半島人には関わらない方がよい。
480 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 21:03:15 ]: >>477
基本的に経験則のまとめ本だから、必要な状況にならないと理解しにくいのが多い。
まあ理解出来る出来ないに関わらず一冊持っとくのは良いと思うよ。
481 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 21:15:36 ]: こういうのには盛り上がるんだなｗ
482 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 21:18:22 ]: ほら、宗教の人だから自作自演で信者獲得したフリしないと気が済まないんだろ
483 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 11:52:06 ]: GoF本を今時会社の机にこれ見よがしに置いてあるの見ると笑える
484 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 14:49:27 ]: キチガイって飽きないの？
485 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:50:15 ]: >>484
自問自答は黙って答出せ
486 名前：デフォルトの名無しさん mailto:sage [2007/05/18(金) 15:28:15 ]: ここのObserverﾊﾟﾀｰﾝはわかりやすかった。
ttp://goodjob.boy.jp/chirashinoura/id/135.html
487 名前：デフォルトの名無しさん mailto:sage [2007/06/18(月) 21:21:41 ]: アーキテクチャパターンの質問で悪いんだけど、
MVCパターンにおいて、
｢押されたボタンに応じて新しいサブWindowをオープンする作業｣のような、
Window遷移を管理する人(実現する人)って誰になるの?

Model? View?

Window遷移もアプリケーションの中核処理になるから、
Modelの責務の範囲内なのかなとも思うんだけど、、実際どうなの?
488 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:59:02 ]: どーでもねーよ
489 名前：デフォルトの名無しさん mailto:sage [2007/07/09(月) 11:31:18 ]: >>487
画面の制御なんてモロにViewだと思うんだけど。
490 名前：デフォルトの名無しさん mailto:sage [2007/07/09(月) 22:41:24 ]: ＵＩモデルだな
491 名前：3年前 mailto:sage [2007/07/11(水) 11:24:49 ]: Domain-Driven Design
pc11.2ch.net/test/read.cgi/prog/1080149913/

1 名前：仕様書無しさん投稿日： 04/03/25 02:38
　ドメイン駆動型デザインとは何か？

　Download draft of book from
　www.domaindrivendesign.org/book/DDD_2003-04-15.pdf
　www.domaindrivendesign.org/
492 名前：そして現在 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/07/11(水) 19:11:44 ]: へー
494 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 17:41:42 ]: ここって何も知らん人でも書いていいんだろうか・・・

一つのパターンを適用、っつーか使うっていうのなら何とかできるんだけど、複数のパターンを組み合わせるとなるといきなり手が止まる・・・
デザインパターンはいいコードを書いていれば自然に適用されている物、っていうことなの・・・？
495 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 18:57:21 ]: 一つ使うも複数使うも難易度に差はないだろ
理解しないでサンプルコード改変してるレベルと見える
496 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 23:46:07 ]: デザインパターンって、「組み合わせて」使うような例ってほとんどないんじゃないかな。

一つのモジュールの別々の箇所で複数のデザインパターンを併用することはよくあるけどねー。
Java のクラスライブラリがいい例。
497 名前：デフォルトの名無しさん [2007/10/31(水) 00:50:37 ]: 難しいことはいいからデザパタって
ホントに役に立つのかどうか教えろよ
498 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:51:49 ]: >>497
OOPを一から自分で設計するのは骨が折れるぞ
バグも紛れ込むし
499 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:55:39 ]: お前に使いこなせねえよバーカ
500 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:55:43 ]: >>497
仕事なら役に立つよ
一単語だけで意図が伝わる
501 名前：デフォルトの名無しさん [2007/10/31(水) 00:58:01 ]: >>499
うるせーハナクソ
502 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 01:16:18 ]: >>497
自分のそれまでの経験とセンスだけで、
後々のメンテとかになるべく困らないような
設計するのは難しいから、頭のいい先人たちが
編み出した有用なパターンを知っておいた方が楽。
ていうか知らないとかなり大変。
503 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 01:23:01 ]: >>498

かなりできる人間が過半数超えてれば使えるし、
超えて無いとロスの方がでかい。
504 名前：デフォルトの名無しさん mailto:sage [2007/11/08(木) 11:28:46 ]: C++でのcrtpとか言語毎に形成されたイディオム的なパターンは実用性も高いし、初心者にも分かりやすいと思う
結局言語の所まで落とさないと使えないしね
というかC++だとそういうidiom使わないとたちどころに言語になるし

GoFで紹介されてる各パターンは役に立たないけど
そこで使われる考え方っていうのは言語ローカルなイディオムを理解するのに役立つかなぁと思ったけど、
もう少し勉強が進んだらまた違う感想になる気がする
505 名前：デフォルトの名無しさん [2007/11/14(水) 02:08:15 ]: デザインパターンを使わずにスマートに書く方法とかって
どんな感じなんになるんでしょうね？

たとえば、うどんをそばを作る場合なんかはほとんど
工程は一緒なのでテンプレートメソッドに使うんだろうけど

みなさんならどうやって書きますか？
ふと考えるといろいろあるけどどれもいまいちな気が。

1どんぶり用意
2うどんかそばを入れる
3だしをそそぐ
506 名前：デフォルトの名無しさん mailto:sage [2007/11/14(水) 03:04:16 ]: GoFが役に立たないとか、デザインパターンを使わずにスマートに書くとか・・・学生さんかね？
507 名前：デフォルトの名無しさん [2007/11/14(水) 08:14:51 ]: >>506
なんだか継承になれすぎて使わないパターンがあまりおもいつかなかったもので使わなかったらどうだろうかと思ったんですけど。
508 名前：デフォルトの名無しさん mailto:sage [2007/11/14(水) 12:22:47 ]: >>505
昔は仕様書を元に上から下へ逐次式に書いたものだよ。
仕様書がすべて、はじめに機能をすべて洗い出せることこそ能力。

これに慣れたままSEになり３０代を迎えると、もう補正が効かない。

あと、現場でやっている人は、GOFどうこうを意識している人はあまりいないとおもう。
509 名前：デフォルトの名無しさん [2007/11/15(木) 02:57:13 ]: >>508
>これに慣れたままSEになり３０代を迎えると、もう補正が効かない。

そういう人を一般的に才能がないという。
勉強する意欲がない人はいくら若くてもダメ。
転職するならお早めに。
510 名前：デフォルトの名無しさん [2007/11/15(木) 03:47:08 ]: >>508
ちょっと前にやったプロジェクトで、GOFに死ぬほど拘ってる
プロジェクトリーダーが居て困ったことがあるな。

最近、GOFを勉強したらしく、なんか頭がすごく良くなったカン違い
してるみたいで、設計がGOFのどれかのパターンになってないと、
全部NGにされて、直すのに苦労したよ・・・
511 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 03:50:05 ]: >>508
GoFすら意識してなくて機能をイメージできるものか？出来てるつもりじゃないか？
512 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 09:22:08 ]: 設計なんて茨の道さ。
もんどりうってじたばたして、
痛い思いしながらGoFにしがみついたり、
手放したり、またGoF読み直したり、
もんどりうったり、じたばたしたり、
GoF読み直してピンときてみたり、
こなかったり、もんどりうって、ピンときたり。
513 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 13:56:27 ]: 全ての設計要素は何らかの秩序の上に存在すべき
だが設計要素や立脚する秩序をすべて表現する必要はないってこった
達人の書いたオプソのコード読んでも、凄さが伝わりくい理由がそこにある気がする
514 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 14:39:57 ]: >>512
オッパイ揉んでピンときたり
が抜けてね？
515 名前：デフォルトの名無しさん mailto:sage [2007/12/28(金) 16:51:17 ]: ソースコードの見た目がかっこ良くなるので使ってます
516 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 21:48:54 ]: 開発環境のバージョンによって、含まれるライブラリが違うため、
どちらのバージョンでも動くように、実装を切り替えるということがしたいのです。
XMLのラッパーライブラリのエンジンの実装を切り替える、というようなことです。

Strategyパターンを使うのがよいのでしょうか？
最初は、Decoratorパターンと区別がつかなかったのですが、
GOF本のDecoratorのところにあるように、

・中身を取り換えるのが、Strategyで、
・外側を取り換えるのが、Decorator
ということで、

中のエンジンを取り換えるのは、Strategyパターンということでしょうか？
517 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 22:43:21 ]: >516
あんまりパターンの名前にとらわれずにしたほうがいいと思われ。
518 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 00:19:40 ]: うむ。
とりあえず作りたいように作って、似たパターンがあったらそれに合わせていく方向で。
519 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 03:33:32 ]: >>517-518
ありがとう
過去レスででてたけど、作ってみてリファクタリングの時に考える方法やってみる
520 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/02/06(水) 23:46:55 ]: これっしょ？よく見る普通のインターフェイスじゃないか。
boost.cppll.jp/HEAD/libs/smart_ptr/sp_techniques.html#abstract
522 名前：デフォルトの名無しさん mailto:sage [2008/02/07(木) 00:21:09 ]: 「～パターン」とかの名前がついてるわけではないのね。
523 名前：デフォルトの名無しさん mailto:sage [2008/02/07(木) 03:10:32 ]: strategyじゃね
524 名前：デフォルトの名無しさん mailto:sage [2008/02/07(木) 07:40:40 ]: 派生クラスを１つしか作らないこと前提で目的も違うから
strategy じゃないな。
525 名前：デフォルトの名無しさん mailto:age [2008/02/14(木) 22:04:23 ]: 質問させてください
Compositeパターンで作られたクラスに
インターフェースの拡張を施した新しいクラスを作りたいときは
Bridgeパターンを使いますか？
526 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 20:35:57 ]: 自己解決しました
527 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 03:47:22 ]: 自己解決したらできれば、解決法を書いていきましょう
後で見た人の参考になりますよ
528 名前：デフォルトの名無しさん [2008/02/27(水) 09:21:02 ]: フラグを１ビットではなくカウンターで持っておき、ＯＮ扱いを１より大きい
値（仮にＡ）とします。ＯＮしたい状況ではいきなりＡを代入するのではなく
１ずつ足していき、ＯＦＦしたい状況ではすぐにゼロを代入します。

こういう、ＯＮにするときだけショックアブソーバー付きな動作をする
フラグはデザパタではどういう名前が付けられてますか？
529 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 13:24:07 ]: 自家発電しました
530 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 19:14:49 ]: >>525-526
自己解決パターン
531 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 01:50:40 ]: アンチパターンだな
532 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 18:10:25 ]: 最近デザインパターンを勉強しだしたんですが
GoFの23個のうち2～3個組み合わせて何か簡単なものを作るとしたら
どんなものが思い浮かびますか？
533 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 18:27:07 ]: STL
534 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 18:29:26 ]: Template Method との組み合わせは結構考えられるかと。
535 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:56:35 ]: コマンドパターンとなんかで、
GUIツールのアンドゥの練習
536 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:56:57 ]: やっぱり、アンドゥ、リドゥの練習にしといて
537 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 23:13:23 ]: Memento パターンと Command パターンの複合か。
538 名前：デフォルトの名無しさん mailto:sage [2008/03/03(月) 01:22:59 ]: わかりました
やってみます
539 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 18:26:09 ]: ｃ++です
DecoratorパターンでConcrete ComponentとDecoratorを区別して
Concrete Componentの型を知る方法はdynamic_castを使うしかないですか？
540 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 18:53:21 ]: >>539
型を知って何をするかによって方法が変わる気が。
RTTI(dynamic_castもその１つ)を使うか、Concrete Componentのメンバに型を示すIDのようなものを用意しておくか。
そもそもスレ違い。
541 名前：デフォルトの名無しさん [2008/05/09(金) 11:50:43 ]: 鈴木高弘スレｗ
542 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 05:10:51 ]: ゲーム作ろうと思い、デザインパターンの勉強をしてるんですが
Singletonをどんな風に使うのか今一ピントきません。

Singletonじゃないと困る場合。
Singletonだと助かる場合。
出来たら例を示して貰えないでしょうか。
543 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 07:57:27 ]: >>542
ぜひ、こちらへどうぞ

ゲームにおけるデータ構造・クラス設計・パターン
pc11.2ch.net/test/read.cgi/gamedev/1155209226/
544 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 16:39:33 ]: あちらで聞いてみます
545 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 17:47:41 ]: やる夫がデザインパターンをやるようです
mojalog.com/2008/02/post_160.html
546 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 18:06:29 ]: >>545
やる夫ｗｗｗｗめちゃめちゃ笑った
547 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 18:15:14 ]: >>545
デザインパターンの考え方が分かりやすくて助かりました。
548 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 19:23:44 ]: AA入ってるのって、一見とっつきやすそうだが…、
読みにくくもあったり…しかし微笑ましいのだけは確か。
549 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:11:22 ]: 例自体は具体的で読みやすいんじゃないか？
デザパタ本て(全部とは言わないが)ほとんどが
説明のための説明みたいな本になってるし。
550 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 02:47:40 ]: シンプルファクトリーって始めて知った
ファクトリメソッドとアブストラクトファクトリしか知らなかった
デザインパターン的には常識なの？
551 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 02:56:07 ]: この手のものは先に名付けたもん勝ちだから
あまり仔細にこだわろうとするな。

> ファクトリメソッドとアブストラクトファクトリしか知らなかった
知ったかどうかよりも理解できたかどうかが大事なんだが。
552 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 16:39:49 ]: marupeke296.com/DP_main.html

個人的にここのデザインパターンの解説がゲームプログラミングを例にしているせいか
わかりやすいんだが、スレ住人的にはどう？
553 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 16:59:44 ]: >>552
わかりやすいし、筆者の理解度は高いと思う。
自分の言葉で言いなおしてるところで、
的が外れていないので高感度アップ。

Abstract Factory 一塊のオブジェクト群を沢山の種類用意する

は、恥ずかしながら今までみたどの解説よりスッとくる一文だった。
554 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:57:03 ]: 例というなら、GoFの元ネタはウィジェットや言語の実装で現われたパターンだから、
自分でウィジェットや言語を書けば何を言ってるのかすぐわかる
555 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:10:08 ]: うじぇー奴
556 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:53:16 ]: >>552
FlyWeightってこのページで書かれているような感じなの？
557 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:31:42 ]: zsh line editorのwidgetでも使えますか！？
558 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 11:28:21 ]: 実践UML 第3版オブジェクト指向分析設計と反復型開発入門
www.amazon.co.jp/dp/4894716828

この本とかどうだろうね？まだ自分は読み始めだけど。
559 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 19:02:26 ]: だったら読み終わったときに評価書いてくれ
560 名前：デフォルトの名無しさん [2008/06/18(水) 18:46:30 ]: MVCモデルについて質問です。

javaであればModelでは描画するメソッドを一切実装せず、描画メソッドについてはすべてViewで実装するという事ですか？
例えば、Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思いますが、
そういう時もViewまで先送りにした方がいいですか？
561 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 00:31:36 ]: 描画はモデルじゃね？
562 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:05:46 ]: >Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思います
例えばどんな時？

デザパタの本にありがちな、
Shape インタフェースに draw メソッドがあって
Circle でも Triangle でも draw 呼べば片付きますよ、
的な話って、いかにも説明のための説明って気がしてならん。
563 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:20:03 ]: ここまで一切コントローラの話題が無い件
564 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 07:30:42 ]: >>562
まさにそういう時。
アルゴリズムでdraw可能なオブジェクトをいくつかはじきだす。
その時にそいつにdrawメソッドを持たせておいた方が都合がいいのでそうしているが、
癒着してるようで気がかり。
565 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 19:37:43 ]: ほれ、答えだ
www.fujigoko.tv/rev/prof/doc4/index.html
566 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 20:07:01 ]: 長い；；
567 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 23:52:54 ]: >>565
当たり前すぎるくらいに当たり前のこと書いてるな。
でも、この当たり前が理解できてないやつが殆どだ。

モデル自体が保存メソッド持ってるフレームワーク見せられて
「なんでこんな設計なの？」「便利だから」
意味不明の回答で泣きそうになった。

次の会社でも探すか。
568 名前：デフォルトの名無しさん [2008/06/21(土) 00:25:48 ]: データモデルと永続化は別か，そうかそうか
569 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 00:50:45 ]: >>567
あたり前田のクラッカーってどうなったんだろう？
570 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 09:28:30 ]: > モデル自体が保存メソッド持ってるフレームワーク見せられて

普通じゃん。
571 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 09:42:35 ]: >>567
むしろ保存とか読み込んで再構築とかいう手間を見せ付けてはいけない
572 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 13:33:10 ]: シリアライズ機能くらい普通じゃん
573 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:01:39 ]: シリアライズを提供することと保存の主体であることは別じゃね？
574 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:06:23 ]: Save(IOutputStream* stream)
Load(IInputStream* stream)
みたいに外部に保存主体があるわけじゃなくて、
まさか内部に保存主体があるのか？
575 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:12:35 ]: dbの話じゃないの？
576 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:23:23 ]: >>574
保存主体ってなんですか＞＜；；

# Save(IOutputStream* stream)
これだと「何を」みたいな目的語が全く存在しない
577 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 18:08:59 ]: .NET Frameworkだと、シリアライザクラスに分けてあるね。
578 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 18:15:05 ]: クラスを分けるのは便利な面もあるけど、
保存すべき情報は外部に見せることのできる情報ばかりではないからね。
両方できるようにしてどっちにするか選択できるのが一番良い。
579 名前：デフォルトの名無しさん mailto:sage [2008/06/22(日) 09:05:38 ]: Save(PersistContext pContext)とかになってPersistContextの実装しだいでDBにもXMLにも保存できるのが吉かと。
580 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 21:05:45 ]: >>552のAbstract Factoryの頁を読んでみたんだけど、
とても違和感を感じる、というよりはっきり言って全く間違っているように思うのだが
これは俺の方が間違ってる？

俺がおかしいなと思った点は、

(1) void Create( AbstractWeapons *AbsWep)みたいな"具体的な"値を引数で
　　取るメソッドのどこが"Abstract"（抽象）なのか？
　　思うに、この著者は"Abstract"の意味を取り違えているのではないか？
　　確かに「武器」はAbstractWeapons という型に抽象化されてはいるが、
　　Abstract Factoryの"Abstract"ってそういう抽象化のことを指しているんじゃないのでは？

(2) 1とも関係するが、著者は自分で『オブジェクト内部で作ってもらった方が、
　　外部の人は渡すべき武器について知らなくて良いので楽になる』と（もっともな）事を言っているのに
　　できたコードは全然そうなってない。
581 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 22:20:23 ]: >>580
そういう疑問を持ったときは実際にプログラミングするのが早い
582 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2008/08/07(木) 00:49:16 ]: まぁWeaponをインタフェース名にしろと思ったな。

AbstractWeaponsImpl みたいな感じで
なんらかの共通処理を持った実装クラス名にすることはあるんだが
インタフェース名にAbstractcなんやらーってあんまりしないなあ。

宗教だけど。
584 名前：デフォルトの名無しさん [2008/09/08(月) 11:09:58 ]: あげ
585 名前：デフォルトの名無しさん mailto:sage [2008/09/08(月) 14:08:20 ]: 読み始めたけど、道のりなげぇぇぇぇ。
586 名前：デフォルトの名無しさん [2008/09/08(月) 20:11:30 ]: 或曰: お仕事
www.issei.org/blog/archives/000225.html

こちらのサンプルにあるような、
依存部分だけをインターフェスのContextとして取り出し、
実行時に引数にContextを渡して依存を解決するような場合の
パターン名は何かありますでしょうか？

もし、ない場合適当なパターン名としてどんなものがありますでしょうか？
587 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 01:27:27 ]: Context と Context のユーザーが
互いにインスタンス参照をもちあう作りが
ものすごく不吉な感じするんだけど
そのあたりどうなんだろう。
588 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 09:44:23 ]: Head Firstの本ってどう？
589 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 19:11:26 ]: abstract Factoryパターンと、Factory Methodパターンの違いについて述べよ。
また、ファクトリパターンがどういう場合に有効なのか知るところを述べよ。
生成メソッド（例えばファイル読み込みなど）を生成すべきメソッドに持たせるとどのような不都合が起こるのかを述べよ。
590 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 20:23:18 ]: >>588
俺持ってるけど良いよ
ホントに重要なパターンだけを優先順位を付けて展開してる、
最初は秘術的なobserverパターンから初めてるのも好感できる
observerはstrutsやMVC関連で良く使われるパターンだよね
591 名前：デフォルトの名無しさん [2008/09/10(水) 00:47:57 ]: >>590
でもピザパターンとかが無いからなぁ・・・
入門としては良書だけど、見通しが利かないってとこがちょっと。
592 名前：デフォルトの名無しさん mailto:sage [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, 佐藤直生, 木下哲也, 福龍興業: 本
www.amazon.co.jp/dp/4873112494
images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg

これですか？
高すぎるんですがｗｗｗ
594 名前：デフォルトの名無しさん mailto:sage [2008/09/10(水) 21:00:44 ]: >>593
貧乏自慢すんなよ
595 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 16:16:55 ]: 「デザインパターンによるJava実践プログラミング」っていう本がぱっと見GoF本に似てる感じがしたんだけど、
これを読めばGoF本読まなくっていいかな？
596 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 23:48:47 ]: どれ読んでも難解だよな
ゲームで説明しているページが一番分かりやすい。
1個だけ間違ってるのあるけど
597 名前：デフォルトの名無しさん mailto:sage [2008/09/14(日) 04:40:51 ]: GoFをまるぺけのところと照らし合せながら読むのがいいと思う
598 名前：デフォルトの名無しさん mailto:sage [2008/09/14(日) 10:29:03 ]: Head Firstシリーズのデザパタ本を読んだ後に同じシリーズのオブジェクト指向設計の本
をちょっと立ち読みしてみたら内容がかぶってる気がしたんだけど、
前者を読んだ後に後者を読む価値はあるかな？
両方読んだ人いたら教えて。
599 名前：デフォルトの名無しさん [2008/09/21(日) 15:39:38 ]: stateとstrategyの違いを教えてください。
600 名前：デフォルトの名無しさん mailto:sage [2008/09/21(日) 17:17:42 ]: 実装クラスで表現されたモノによって呼び方が変わるだけで、構造上の違いはないよ。
601 名前：デフォルトの名無しさん mailto:sage [2008/09/22(月) 06:22:50 ]: Gofって所謂カタログ本だと思ってた。

>>598
ある
602 名前：デフォルトの名無しさん [2008/09/28(日) 10:00:51 ]: 過疎どすな
603 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 23:50:39 ]: デザパタてはやり過ぎない不思議
604 名前：デフォルトの名無しさん [2008/10/02(木) 15:47:16 ]: 渇祖
605 名前：デフォルトの名無しさん [2008/10/05(日) 14:25:10 ]: >>599
「目的が違う」ってことでいいのかな？
stateはアルゴリズムを動的に切り替えられることに意義があり、
strategyはアルゴリズムを分離することに意義がある
とか。
606 名前：デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:08:42 ]: stateの方、それ違くね？
607 名前：デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:29:00 ]: The differences between Strategy pattern and State pattern Five ’s Weblog
powerdream5.wordpress.com/2007/10/05/the-differences-between-strategy-pattern-and-state-pattern/

The difference between the two GOF patterns "Strategy" and "State"
www.c-sharpcorner.com/UploadFile/rmcochran/strategy_state01172007114905AM/strategy_state.aspx

散々議論されてきた歴史があるのでそれを参考にしたらいいと思うよ
608 名前：デフォルトの名無しさん mailto:sage [2008/10/08(水) 23:54:54 ]: Compositeってやつのみっつのくらすをひとつのクラスにすることは出来るの？
609 名前：デフォルトの名無しさん [2008/10/09(木) 12:31:35 ]: っていうか、「何でお前が勝手にルール決めてんの？つか誰？」って感じしない？
610 名前：デフォルトの名無しさん mailto:sage [2008/10/09(木) 16:31:30 ]: >>608
XMLとか
611 名前：デフォルトの名無しさん mailto:sage [2008/10/13(月) 23:36:50 ]: >>609
OOPのノウハウを共有するために呼び名を決めたほうが良いね、ってのが
デザインパターンの意義なのにルールも糞もあるもんか。

おまいが好きなノウハウに好きな名前を付けたけりゃ、そうすればいい。
それを共有しようとする奴は誰もいないだろうがなぁ。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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