デザインパターンの単純そうな質問

1 ：デフォルトの名無しさん：2001/07/11(水) 16:22

GoFのデザインパターンを読んだけど、分からない事があるよ～
という人のためのスレ。

2 ：デフォルトの名無しさん：2001/07/11(水) 16:27

PROTOTYPEパターンの適用可能性の最初の項目が何をいいたいのか分かりません。
そもそもダイナミックローディングとは、どういった操作の事をいっているのでしょうか？

ちなみに、本は、日本語版の初版です。

3 ：デフォルトの名無しさん：2001/07/11(水) 16:44

>>2
俺なんか結城さんの本を読んでもプロトタイプわからん。

4 ：デフォルトの名無しさん：2001/07/11(水) 16:48

あれれ？デザパタスレって、まだ無いんだっけ！

本の話は…持ってない人が辛いんで、
該当部分を引用するとか、もしあればURLを書くとか
(英語しかなくてもとりあえずないよりはマシ)
してくれると助かる。

5 ：2：2001/07/11(水) 16:55

>>4
大昔にはあったのかも知れないけれど、探したら無かった。

で、該当する箇所を引用します。

インスタンス化されるクラスが、例えば、ダイナミックローディングにより、
実行時に明らかになる場合。
(p128、デザインパターン初版、SOFTBANK社)

これだけじゃ、分からないかなぁ。やっぱり。

6 ：適当に：2001/07/11(水) 17:00

[ja]
Java言語で学ぶデザインパターン入門
http://www.hyuki.com/dp/
Javaプログラマのためのデザインパターン入門
http://objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.html
デザインパターンの骸骨たち
http://www11.u-page.so-net.ne.jp/tk9/ys_oota/mdp/

[en]
Patterns Home Page
http://hillside.net/patterns/

7 ：2：2001/07/11(水) 17:05

>>6
見た事の無いWebページもありますので、読んでみます。
ありがとう。

8 ：追加：2001/07/11(水) 17:09

[ja]
デザインパターン with JAVA
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/patternIndex.html
Javaなページ
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaMain.html
デザインパターン入門 (ちとわかりずらい…)
http://www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html

9 ：デフォルトの名無しさん：2001/07/11(水) 17:14

>>5
>インスタンス化されるクラスが、例えば、ダイナミックローディングにより
>実行時に明らかになる場合。
>これだけじゃ、分からないかなぁ。やっぱり。

…わかっちゃった(^^;

インスタンス1号を作るとき、そのクラスとして
後からロードされるクラスを使いましょう、って場合だ。

で、インスタンス2号を作りたくなった辺りのソースでは
インスタンス1号は(Scopeとか的に)見えているんだが
そのクラスは見えないようになっている、という場合だ。

じゃあインスタンス1号に2号を(本人と同じクラスで)
作らせちゃえばいいじゃん、という話。

喩え１：
謎の悪の組織デスト某に作られた仮面ライダ1号は
戦いに疲れて仲間が欲しくなったのだが、
いまさら謎の悪の組織に再びのこのこ出向くわけにもいかない。
しかたがないので自分の体を真似して自力で2号を作った。

喩え２：
ゲイツのソフトだろうがLinuxだろうが
元ファイルがあればピーコするのは同じ手順でできる！(わら

うーん。でもこれだと、Factory系のパターンとの違いが
際立たないというか、なんか変だな。
俺間違いかも。突っ込み歓迎。

10 ：さらに：2001/07/11(水) 17:20

デザインパターン
http://piza.2ch.net/test/read.cgi?bbs=tech&key=994690114

mogura (2chLinuxer氏に敬礼！）
http://2ch.dyn.to/

11 ：2：2001/07/11(水) 19:35

>>9
私もわかったかも。

Cloneオペレーションを定義を定義してある、Prototypeがまずある。
で、Prototypeの派生クラスConcretePrototypeA、ConcretePrototypeB
と言ったクラスがある。

ロードをする部分（メッソドやクラス）は、具象クラスの名前なりがわかっているわけだ。

でも、実際にロードされたクラスを使うクラスでは、具象クラスを知らない。
けれど、新たにインスタンスが欲しい。
しかし、具象クラスについて知らないから、コンストラクタを呼べない。

結果、複製すればいいということになる。
ポリモルフィズムで適切なCloneメソッドが呼ばれるから。

という感じ？

12 ：2：2001/07/11(水) 19:36

　ただ、クラスをダイナミックローディングする仕組みを使ったことが
無いから、根本的なところが間違っているかも。

13 ：デフォルトの名無しさん：2001/07/11(水) 19:38

>>8
>>10
親切な人だ。
ありがとうございます。

14 ：9：2001/07/11(水) 19:40

書き方がいまいち悪かったと反省。

>インスタンス1号を作るとき、そのクラスとして
>後からロードされるクラスを使いましょう、って場合だ。

ここでいう「後」とは、そのプログラムが起動された後という意味のつもり。
動的ロードがあたりまえのように出来る言語では、
大騒ぎするような話じゃあないわな。
C++だと標準では出来ない(VCやC++Bみたいに
色々手を尽くしてそれっぽく実現してる奴はいるが)。
rubyみたいな動的でインタプリタな言語なら
とーぜんのように(すまんmatz氏)ついている機能。

喩え１や２は、そういう意味では悪くないと思う。
インスタンス1号を作る時点では、間接的にせよClassを使えたわけだ。
で、2号の辺りでは間接的だろうがなんだろうがそのClassを
「再びソース上で」呼ぶことが出来ない、という状態。

15 ：9：2001/07/11(水) 19:47

ごちゃごちゃ言うまでもなく11で既に判ってるようなんで
まぁいいか。

>ポリモルフィズムで適切なCloneメソッドが呼ばれるから。

それそれ。

ただ、蛇足だがObjectiveCやDelphiだと
「クラスメソッドのポリモルフィズム」を使えるので、
そーいう意味でのCloneは、あんまり必要なかったりする。

#もちろん、インスタンス1号(の状態)を2号に含めたい場合は、
#ピーコ(Clone)のほうがずっと自然なやり方だが。
#今回の話はやっぱりどっちかってーとBuilder系パターンの話が
#微妙に混線してるような気がする。

Smalltalkやrubyなんかでも指摘されていることだが、
デザパタのいくつかは、対象言語の柔軟性の低さ
(つまりあるパターンを直接ライブラリ化できないこと)を
パターンということにしてカバーしている(わら)という節もある。

16 ：２：2001/07/11(水) 20:43

>>15
ありがとうございます。
どうにか分かりました。

＞デザパタのいくつかは、対象言語の柔軟性の低さ
＞(つまりあるパターンを直接ライブラリ化できないこと)を
＞パターンということにしてカバーしている(わら)という節もある。
みたいですね。
　私はSmalltalkは知らないのでよくわからないのですが、
「Smalltalkではあまりこの使い方に意味は無い」といった感じの
記述を、デザインパターンの本の中でしばしば見かけます。

17 ：1：2001/07/23(月) 09:53

たまには上げてみる。
かなり人気無いな、このスレ。
ターゲットを絞りすぎたのかも。
「パターンを全般的に扱うスレ」とかにした方が、良かったかなぁ…。

18 ：うむ：2001/07/23(月) 09:57

さいきんデザインパターンを勉強しはじめたが・・・・

ククク・・・・
　　　　　　　まったくわからんよ・・・

19 ：デフォルトの名無しさん：2001/07/23(月) 12:30

Singletonパターンしか使ってないなぁ・・・・。
SingletonDialog便利（笑）　

20 ：デフォルトの名無しさん：2001/07/23(月) 21:58

AbstractFactory
の工場は、
いろんな部品をまとめて提供するもの
て解釈でいいですか？

21 ：デフォルトの名無しさん：2001/07/23(月) 22:41

>>20 全然違う。

22 ：デフォルトの名無しさん：2001/07/23(月) 23:21

>>20
ナニ(1つでも複数でも)を作るかが、
大筋は決まってるんだけど、
完全に具体的というほどにはまだ
決まってない(=Abstract)、という工場だ。

たとえばプラモ自動車用に
10種類くらいの部品を作る工場で
その設計とかも大抵出来ているし
金型まで用意済んでるんだが、
その金型にナニ色の樹脂を流しこんで製品作るか？は
まだ決まってない、みたいな工場(のクラス)。

で、その工場クラスを継承(カスタマイズ)して、
赤プラモ製造工場や、青プラモ製造工場を、作るわけな。

ところで結城氏の本。
「自分の言葉」で語っている(しかもドキュじゃない)のは
素晴らしいが、それ故なのか、時折過不足を感じる記述も有るなあ。
90点以上の出来(=並大抵のもんじゃない)なのは確かだが。

23 ：デフォルトの名無しさん：2001/07/24(火) 10:00

ありがとう！
ぜんぜん違うっていわれたけど、そうでもなかったみたい

24 ：名無しさん：2001/07/24(火) 10:59

Javaをつかったデザインパターンの本は３冊読んだけど
結城氏の本は簡単でネチっこく説明してくれてるので一番良いと思った。

ところで、結城氏の本のPrototypeの説明(P75)にある
「種類が多すぎてクラスにまとめられない場合」
にProtptypeを使えと言うのが良くわかんない。

25 ：デフォルトの名無しさん：2001/07/28(土) 19:08

>>24
「デザインパターン（英語版）」のP119-120に、
Specifying new object by varying valuse.
（中略）
This kind of design lets users define new "classes" without programming.
って書いてあり、これのことを言っているのだと思う。

で、何がいっている文章かというと、例えば楽譜エディタがあった時に、音符を
表すクラスがたくさん必要になる。
二分音符クラスやら、四分音符クラスとか。

そこで、「音符クラス」を用意しておいて、異なる「長さ」と「ビットマップ」で
初期化したインスタンスを用意しておいて、それのクローンを作るようにすればいい。

…っていうようなことが書いてあるように俺には読めるのだけど、二分音符クラス
やら、四分音符クラスをまとめて「音符クラス」にするのって普通の発想だよなぁ…。

うーん。
ということで、結局俺もよく分からなかったり。

26 ：デフォルトの名無しさん：2001/07/28(土) 21:05

>>25
なるほど。prototypeの使い道がようやく見えた。
四分音符が楽譜上に置かれているとして、ユーザーがその音符をコピーしたいとき、
単純に四分音符を生成するのではなく、
とある（種類不明の）音符をコピーした結果として四分音符が生成されると。
そういうときに使うのか。

27 ：d：2001/07/29(日) 12:46

めめんと！
めめんと！

28 ：デフォルトの名無しさん：2001/07/30(月) 04:51

>>27
おれもめめんとなんて単語、あの本読むまで知らなかったよ

29 ：デフォルトの名無しさん：2001/07/30(月) 14:52

Prototypeって、「インスタンスのコピーをして何が面白いんだろう？」って
思っていたけど、「具象クラスを知らなくても、インスタンス化ラインスタンスが
生成できる」って側面に注目すべきだったみたいだな。
ちょい、納得。

30 ：デフォルトの名無しさん：2001/07/30(月) 15:15

GoF本(和訳第二版)を読んだけど、Prototypeパターンは

ちょっとずつ違う似たような図形をいっぱい並べて使うようなアプリで、
仕様のホットスポットが「図形のバリエーションが今後も追加されると思われ」
だった場合に、図形ひとつづつをいちいちサブクラスとして定義しようとすると
クラスの数が爆発してしまう。

という場合に使うと思った。

31 ：dこうい：2001/07/30(月) 16:03

ソースみただけで
これは○○パターンだな　とかわかるものなのでしょーかー

32 ：デフォルトの名無しさん：2001/07/30(月) 17:37

>>31
というか逆に、ソースコードを説明する時に、
「これは○△パターンを使って×□を処理してます」とか
設計についてミーティングする時に、
「この部分は□○パターンを使って管理しよう」とか
コミュニケーションのために使うんじゃない？

あとコードの中では意識してイディオム的なクラス名やメソッド名、フィールド名を使って
後から読む人（含む自分）に、そのコードがどういうパターンを使っているか伝わりやすい
ように工夫するとか

33 ：30：2001/07/30(月) 17:55

ちょっと補足
つまり、ちょっとずつ違うたくさんのオブジェクトを扱う時に、
それぞれの違いをサブクラスとして表現するのではなく、
同じクラスのインスタンスなんだけど状態が異なるものとして表現すれば、
without programming で種類を増やせるってことね。

だから clone() は状態もコピーするってところが重要になってくる。

34 ：デフォルトの名無しさん：2001/07/30(月) 18:11

出遅れっぽいけど、

>四分音符クラスをまとめて「音符クラス」にするのって普通の発想だよなぁ…。

というかサブクラスの4分音符クラスとかを「作らない」のがあのパターンの味噌。

でも当然だが4分音符を意味するインスタンスは作れなきゃならない。

そういうインスタンスを、クラス定義レベルじゃなくて、実行時の
インスタンスいじり(属性を設定したり他のインスタンスと組み合わせたり)で
作ってしまって(ここまでならBuilderパターンだな)、
しかもそれをピーコすれば同じ「種類」のものがばんばん作れるぞ、
という話。

「種類」を「クラス」で表現しないとならん義務なんか無いよ、ってことね。
勿論、クラスで表現したほうがスッキリする場合はクラスでやるべきだけど。

-----
蛇足。ちょっとひねった使い方だと、作った二代目instanceに
prototype「元」へのポインタを持たせておいて、
共通する属性とかはそっちに委譲しちゃって
二代目は差分しか持たない、なんて手もある。
ProxyパターンやFlyweightパターンとも通じるものがある。

というか、ここまでやったら「Class」の仕掛けを自分で作っているようなもんだ。
なにせ差分プログラミングなのだから(わら

35 ：29：2001/07/30(月) 18:31

わけの分からん誤字をやってしまった。
＞「具象クラスを知らなくても、インスタンス化ラインスタンスが
インスタンスからインスタンスが、
の間違い。

話の流れからして、どうでも良さそうだけど一応直しておきます。

36 ：29：2001/07/30(月) 19:01

>>33
＞だから clone() は状態もコピーするってところが重要になってくる。
なるほど…。
じゃあ、本質的には、「コピーする」っていうのが、やはり重要なのか。

37 ：デフォルトの名無しさん：2001/08/02(木) 14:59

age

38 ：デフォルトの名無しさん：2001/08/14(火) 03:17

良スレ保全age

39 ：デフォルトの名無しさん：2001/08/15(水) 22:47

Singletonってよく使うけど、C++だと、誰がDeleteするんだろって
思ったりしない？
特に途中で
if (singleton == 0)
singleton = new Singleton();
return singleton;
なんてインスタンスを作る場合は、使わなくなったら消したくなるような

40 ：デフォルトの名無しさん：2001/08/15(水) 23:25

>>39
やっぱ、プログラム終了時じゃない？
もしくは、メモリが一時的にでも足りなくなった時

41 ：>39：2001/08/15(水) 23:36

namespaceのコンストラクタ・デストラクタ

42 ：デフォルトの名無しさん：2001/08/17(金) 03:26

>>39
>>40の言う通り、普通はプログラム終了時なんだろうね。
でも、「好きにSingletonオブジェクトを消したい」という要望もあるようで、
「パターンハッチング（ピアソン社）」に一つの答えが載っている。

Singletonオブジェクトを消すためのクラスを作って、Singletonのfriendにするんだそうな。

43 ：>39：2001/08/17(金) 04:28

インスタンスの廃棄・再生成時に副作用が無ければこんなのもありかも
これならインスタンスを参照しない限り生成されることも無いし

C++なら安全の為に、最後にClearSingletonする
SingletonDestructorクラスでも作っておけばいいかな

interface

type TSingleton = class(xxx) ... end;
function Singleton: TSingleton;
procedure ClearSingleton; // キャッシュをクリアするくらいの感覚で使う

implementation

// インスタンスの参照を管理するローカル関数
var TSingleton_Instance: TSingleton;

// singletonインスタンスの参照を取得する関数
function Singleton: TSingleton;
begin
　if TSingleton_Instance <> nil then
　　// 既に生成されていたらそのまま返す
　　Result := TSingleton_Instance
　else
　begin // 生成されていなければ生成して返す
　　TSingleton_Instance := TSingleton.Create;
　　Result := TSingleton_Instance;
　end;
end;

// 既に生成されていたら廃棄
procedure ClearSingleton;
begin
　if TSingleton_Instance <> nil then
　begin
　　TSingleton_Instance.Free;
　　TSingleton_Instance := nil;
　end;
end;

44 ：デフォルトの名無しさん：2001/08/17(金) 04:35

ある日の、FactoryMethodパターンに関する私と教授のやりとり。
クラス名は、デザインパターン日本語版、初版のP116の図のもの。

教授「FactoryMethodパターンを使うとどの部分の再利用性が上がるの？」
私　「CreatorクラスとProductクラスの組です。
　　　Creatorクラスの責務の一部をProductクラスに委譲する構造に
　　　します。
　　　するとConcreteProductで、CreatorクラスとProductクラスの
　　　組の動作をカスタマイズ（なんて言うのが適切なんだろう？）
　　　する事が出来ます。
　　　よって、CreatorクラスとProductクラスの組を
　　　様々なプログラムで使い回すことが出来ます」
教授「それだけ？」
私　「え？」
教授「Clientクラス（図にはないけど、Creatorを使うクラス）と
　　　Creatorクラスの関係に注目してみなよ」
私　「ClientクラスはCreatorで宣言されているインターフェースしか
　　　使わない。
　　　だからConcreteCreatorを差し替えてもClientの変更はしなくて
　　　良い（実際はConcreteCreatorの生成部分を書き換えないといけないけど）。
　　　だからClientの再利用性が上がる。ってことですか？」
教授「うーん。分かってないなぁ…」
私　「？？」

と、言うやり取りがあったのですけど、教授の真意が分かる人は
いますか？
かなり長い間悩んでいるのだけど、私には分からない…。

その後いくつか質問した結果、
「Clientの再利用性が上がる、という事を教授は言いたいのでは
ないらしい」
と言うところまでは分かったのですが、行き詰まってます…。

45 ：デフォルトの名無しさん：2001/08/17(金) 06:02

>>44
> 「ClientクラスはCreatorで宣言されているインターフェースしか
は「Productで宣言されている…」の方がしっくりくるけど…

そんな言葉尻つかまえて「分かってないなぁ」って訳じゃないよね。
ちゃんと他に再利用性が上がる部分があるんだよね？
うーんなんだろ、帰省の長旅用に丁度良いな、これ。
>>43
くぅ、興味あるのに読めない…smalltalk?

46 ：デフォルトの名無しさん：2001/08/17(金) 09:16

>>45 Delphi。

47 ：デフォルトの名無しさん：2001/08/17(金) 09:35

>>45
PL/SQL

48 ：デフォルトの名無しさん：2001/08/17(金) 10:32

delphiならユニットのfinalizationに解放処理かいてるけど。

49 ：43>48：2001/08/17(金) 11:09

Delphiならそうだね。まあC++向けの説明ってことで。
Delphiの場合unit=namespaceだから
finalizationは>41のいうデストラクタにあたると言えるのかも。

50 ：デフォルトの名無しさん：2001/08/20(月) 17:54

age

51 ：デフォルトの名無しさん：2001/08/21(火) 13:45

> > 「ClientクラスはCreatorで宣言されているインターフェースしか
>は「Productで宣言されている…」の方がしっくりくるけど…
ClientはProductのインターフェイスを直接使用する必要は無いよ。
(元の記述のほうが正しい)
普通はCreatorの固定実装部分がProductのインターフェイスを使うね。
もちろんGoF本の｢結果」の2で書かれているように、Productのインスタンスを
Client側に返すようなことがある場合はその限りじゃないけど。

> Clientの再利用性が上がる
これは変でしょ。いやある意味正しいかもしれんけど。ConcreteProductを
差し替えることでClientの変更なしに振る舞いを変えた別のアプリケーションを
作るみたいな文脈ではそういえるし。

明らかに再利用されるのは、Creatorの固定実装部分と思うけどどうよ。
大体Creatorって名前は適切じゃないかもしれんね。anOperation内部に
あるStrategyのような構造こそ重要と思う。
乱文ｺﾞﾒｿ

52 ：Delphiを知らない名無しさん：2001/08/22(水) 01:34

>>51
> ClientはProductのインターフェイスを直接使用する必要は無いよ
スマソ。仰るとおりパラレルなの（邦訳GoF本P118）が頭にあったから…。

「Creatorの固定実装部分」ってのはanOperationの実装部を受け持つ
productのことだよね？そうなら漏れも激しく同意。（anがAnじゃ無いのも同意（ｗ

狭義で再利用って言葉使うなら、適用箇所はProductの抽・具部分のみだと思う。
というか広義で再利用って言ったら、なんでも再利用できるからなぁ（ｗ

ただ44教授の意図は分からずじまいか。…直接、訊いて教えてくれ～

53 ：51：2001/08/22(水) 13:46

このスレは意外と厨房の目に止まりにくいのかもしれないので気楽かも(藁

>「Creatorの固定実装部分」ってのはanOperationの実装部を受け持つ
>productのことだよね？
「実装部を受け持つproduct」ってのはちょっと意図を汲みかねるけど、
漏れの言うのはanOperationの実装そのものが直接的な再利用対象で、
Productの実装は差し替わるわけだから「再利用」とはちょっと違う。
Productは実装無し(interface)であっても構わないことに注目。

なお、こんなことが教授が言いたかった事であるかは疑問なので
(なぜならこのことは「それだけ?」で切り捨てられた主張に含ま
れるとも考えられるから)、漏れ的には教授が解って無い可能性
に+1(藁
デザインパターンって誤解/曲解+宗教的なのが多くなりがちなので。
漏れが解っていない「最も重要な再利用性」があるならそれを知
ることができれば万々歳なので煽っとく(藁
ちなみに「再利用」には実装の再利用とインターフェイスの再利用、
そして構造の再利用があると考えるが、教授はどの「部分」と言っ
てるので「構造」のことじゃないんだろう。じゃ、ここまでにでて
きた事以外に後何があるかねぇ。

54 ：44：2001/08/22(水) 15:40

「Creatorの固定実装」部分を使いまわす、っていうのはTemplateMethodパターン
と似た感じの話でいいのでしょうか？
>>51さんの言うようにStrategy的というのと、ほぼ同等の話であるとは思うのですが。

デザインパターン日本語版（P349）の図で言うと、AbstractClassの持つメソッド、
PrimitiveOperation1、PrimitiveOperation2をProductクラスに
持たしてしまいます。
CreatorはTemplateMethod（anOperationに相当）で
Productクラス（の派生クラス）のPrimitiveOperation1、PrimitiveOperation2を
使う、ってつもりで私は理解しています。

＞漏れ的には教授が解って無い可能性に+1(藁
実は、その可能性を私も疑っていたりします（笑）。
他の可能性としては、
１．私が教授の質問の意図を誤解している。
　　実は、言葉通りの質問ではなくて遠まわしに別のことを言っているのかも。
２．実はFactoryMethod特有のことと、あんまり関係ない質問である。
　　もっと、シンプルなことを聞いているのかもしれない。

＞そして構造の再利用があると考えるが、教授はどの「部分」と言っ
＞てるので「構造」のことじゃないんだろう。
教授は気がつくと話が勝手に展開しているので、もしかすると「構造」なのかも
しれません。
けど、私は「教授はクラス単位の再利用について、私に聞いているのだろう」と
思ったのですけどね。

>>52
＞ただ44教授の意図は分からずじまいか。…直接、訊いて教えてくれ～
教授が基本的には、「あっている」「間違っている」としか言わない人なので、
いつになったら教授の意図が掴めるのやら…。
また、進展があったら書きます。

55 ：デフォルトの名無しさん：2001/08/25(土) 04:54

デザインパターンを意識しないと設計できないような奴は, センスなし.
まとめること自体に価値があるだけで,　その成果物に価値はなし.
ありがたがってるような奴は, それだけの奴.

56 ：Delphiを知らない名無しさん：2001/08/25(土) 05:11

>>53
パラレルじゃ無い場合、Creatorはコンポジションとしてもっているproductインター
フェイスを使ってanOperationを実装する……のじゃないのか…、うーん曲解してるかも
 >>54
ウチの教授は質問すると延々と語るタイプだよ。頭のいい人に質問するのは骨だよね
 >>55
うはぁ、まさに漏れのことだ。でも自分で設計したのも、大体において主要
デザインパターンのいずれかに収束しない？やっぱなかなかの車輪だと思うけど…

いずれにせよこのスレもう少し賑わって欲しいなぁ。それこそウワベのパターンだけでなく
本質を見抜く手がかりになるし。頭のいい人達でパターン毎に議論してくれないかな。
…私はDOMに戻るので

57 ：デフォルトの名無しさん：2001/08/25(土) 07:37

>>55
うっ。耳が痛いです。
でも、逆に「デザインパターンを使う事で、センスの無い人もそれなりの設計が
出来る」なら、私はデザインパターンに意味はあると思います。

「デザインパターンを意識する事で、うまく設計できる人が増えるのか？」って
聞かれると、私はなんとも言えませんけれども。

58 ：51：2001/08/25(土) 08:00

>パラレルじゃ無い場合、Creatorはコンポジションとしてもっているproductインター
>フェイスを使ってanOperationを実装する……のじゃないのか…、うーん曲解してるかも
あってるけど?誤解があるとしたら、56はCreatorのサブクラスでanOperation
をオーバライドすることを前提としているような気がするけど、GoF本定義の
Factory Methodパターンではそうじゃないって事かな。

>>54
教授が「間違っている」としか言わないのだとしたら、44の問い方に自信
がなかったからかもしれないね。
自分がどこまで理解してこのような回答に行き着いたかをきっちり説明
できているなら、その誤りの理由を説明するのが教師の義務と思うし。
こっちがちゃんと説明できている自信があるのに、納得できる説明をし
てくれないようなら、俺ならふーんその程度かぁって判断するなぁ。

>>55
デザインパターンはコミュニケーションの為のものだから、「デザイン
パターンを意識しないと設計できない」のは駄目だが、デザインパターン
を知らない/曲解しているのも困り者。
Factory Methodパターンはその典型なんだけど、今時はGoF自信も
A a = B.create();
なんてのをFactory Methodパターンと呼ぶ事を認めているらしいから…。

59 ：デフォルトの名無しさん：01/09/21 23:27

a,b,c,d,e,f,g,h,i,j
ってクラスが１０個あって、各々のインスタンスの数を１０個に制限した
いけどどうやんの？

class a
{
　private static a[] = new a[]
　{
　　new a(), new a(), new a(), new a(), new a(),
　　new a(), new a(), new a(), new a(), new a(),
　};
　private a(){}
}

ってのを各々のクラスに書かないとだめ？
(インスタンスを識別するのにintを使いますがここでは省略しました)

60 ：デフォルトの名無しさん：01/09/21 23:29

>59
private static int instance_count

a(){ instance_count++; }
~a(){ instance_count--; }

ってやってinstance_countが10超えたらコンストラクタ内で例外をthrowする

61 ：デフォルトの名無しさん：01/09/21 23:37

>>59です。
質問すら満足にできなくてすみません。

>>60
１０個に制限するにはそうしますよね。

>>59で、
>各々のインスタンスの数を１０個に制限したいけどどうやんの？
とか言っておきながら聞きたかったのはこれではなく、

１０個のクラスにほとんど同じコードを書かないとだめなのか
なーと疑問に思ったので。

たとえば、bクラスは、
class b
{
　private static b[] = new b[]
　{
　　new b(), new b(), new b(), new b(), new b(),
　　new b(), new b(), new b(), new b(), new b(),
　};
　private b(){}
}

これが延々と続く・・・(クラス10個・・・)。
結局、最初の段階でおかしいのかな・・・。
OOわからない・・・。
・・・。

62 ：デフォルトの名無しさん：01/09/22 03:31

>>59
お帰りはこちら
http://www.mycgiserver.com/~phpmona/zoids0/ch_list.php4

63 ：デフォルトの名無しさん：01/09/23 14:33

>>61

staticフィールドやstaticメソッド「の」overrideを
サポートしてない言語が多いんで、こういう場合はウザイよね。

仕方ないから小技を使おう。
俺なら(言語に拠るが)こうするね。

10個のクラスの上位にクラスxを作る。

そのクラスのstaticフィールドとしてHashを作る。

Hashには、KeyとしてそのClassObject(またはその代用として
Class名やClass番号)を、Valueとして長さ10の配列Objectを、突っ込む。
勿論そのHashのエントリはここでは10個になるわけだ。

で、Instanceを作るたびに、自分のClassをKeyにしてHashを参照し、
Valueである配列に、InstanceをAddする。
配列が予定したN個を越えていたら、例外で蹴る。

どうよ？

64 ：デフォルトの名無しさん：01/09/23 14:51

>>60
どっちかというと、コンストラクタはprivateにして、Singleton
のようにgetInstance()で制御する方がなんとなくいいような気がする。
別にいいけど。

65 ：デフォルトの名無しさん：01/09/23 14:53

>>60

　　　λ
　　 (　ヽ　　／￣￣￣￣￣
　　( ﾟДﾟ )＜　Rubyはクソです。ゴミ箱逝きです。いじょ
　(＿＿＿_) ＼＿＿＿＿＿
　　　ヽ(´ー｀).ﾉ
　　　　　(　へ)
　　　　　　く

　　　　　　　　　　　　　　　　　　　　　　- = ≡三　　λ
　　　　　　　　　　　　　　　　　　＿ = ≡三　　　　　(　ヽ　　／￣￣￣￣￣
　　　　　　　(´ー｀) 　　　　　　　　　= ≡三　　　　( ﾟДﾟ )＜　この発言をコピペしていただければ幸いです。
　　　　　　( ヽヽ)　　　　　　　　　- = ≡三　　　(＿＿＿_) ＼＿＿＿＿＿
　　　　　　／　　>　　　　　　　　　　　　　- = ≡三

66 ：デフォルトの名無しさん：01/09/23 14:58

>>61
そういう風にしたいなら、親クラスで

class Parent
{
　　public Parent getInstance() {
　　　　//instanceNumberを参照して10個以内に抑える
　　}
　　public static int MAX_INSTANCE_NUMBER=10;

　　private int instanceNumber;
　　private Parent(){}
}

んで、他はこのクラスを継承させる、ってのがいいような気がする。

67 ：Ruby!：01/09/23 15:21

OOPならRubyだね。
Java

なにかと話題のオブジェクト指向言語であるJavaとRubyを比較すると:

* Rubyはインタプリタ型言語。
* Rubyではすべてのデータがオブジェクトである。
* Rubyではモジュールを使って実装を共有できる。
* Rubyの変数や式には静的な型がない。
* Rubyでは正規表現が文法としてサポートされている。

http://www.ruby-lang.org/ja/compar.html

Rubyを知ってもらうためにもこの文をコピペしてください。

68 ：デフォルトの名無しさん：01/09/23 15:29

>>66
大嘘だった。継承するには継承もとのコンストラクタがprivateじゃ
まずいか。getInstance()にしたって、親クラスのインスタンス
そのものが返されるのじゃ意味ないし。。。

こりゃ、親クラス作らずにそれぞれのクラスで実装するしか
ないか？

69 ：たぶん：01/09/23 15:30

61が何のために10x10のインスタンスを生成したいのかを
もっと詳細に書かない限り最適解は出ないに一票

70 ：デフォルトの名無しさん：01/09/23 17:33

　　　　　　　　　　　
――――――――――――――――――――――
番組の途中ですが、臨時ニュースです。
「Rubyはクソです。ゴミ箱逝きです。いじょ」
この発言をコピペしていただければ幸いです。
＿＿＿＿＿＿＿＿＿＿_ 　＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　∥　＼|________　　　
　　　　　　　　　　　　　∥　| ON AIR.|
　　　　　　　　　　　　　∥　￣￣￣￣
　　　　　　　　.／￣￣θ Λ＿Λ
　　　　　　...／　　　／／（´∀｀　)／|
　　　　　.／　　　　￣／⊂　　　 ||_／
　　　　　|￣￣￣￣￣|　（　 ━┳┛
　　　　　|＿＿＿＿＿| ／ヽ｣┘┻

71 ：デフォルトの名無しさん：01/09/23 20:25

――――――――――――――――――――――
番組の途中ですが、臨時ニュースです。
「Rubyはクソです。ゴミ箱逝きです。いじょ」
この発言をコピペしていただければ幸いです。
＿＿＿＿＿＿＿＿＿＿_ 　＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　∥　＼|________　　
　　　　　　　　　　　　　∥　| ON AIR.|
　　　　　　　　　　　　　∥　￣￣￣￣
　　　　　　　　.／￣￣θ 　∧＿∧
　　　　　　...／　　　／／（´∀｀　)／|
　　　　　.／　　　　￣／⊂　　　 ||_／
　　　　　|￣￣￣￣￣|　（　 ━┳┛
　　　　　|＿＿＿＿＿| ／ヽ｣┘┻
　

72 ：デフォルトの名無しさん：01/09/23 22:13

Javaの場合、同packageにインスタンスを管理するクラスを用意して、そこから
インスタンスを獲得するようにします。

73 ：デフォルトの名無しさん：01/09/26 01:00

インスタンスを一個にしたいときSingletonを使わずに
staticメソッドを使うのはだめでしょうか？
初期化の順序が重要なときに使えないのは分かりますが、
他にどんなデメリットがありますか？

74 ：デフォルトの名無しさん：01/09/26 01:37

>>73
言いたいことが理解できない（というか、何通りかに解釈できる）ので、サンプル
コードを希望。

C++ に関して言えば static メソッドは virtual 指定できないので、微妙に使いづ
らい。

75 ：デフォルトの名無しさん：01/09/26 11:03

> C++ に関して言えば static メソッドは virtual 指定できないので、微妙に使いづ
> らい。

何かが根本的に間違ってる気がするが。

76 ：デフォルトの名無しさん：01/09/26 23:50

まず、それがインスタンスである必然性があるかどうか、だ。
初期化の順序ってどういうこと?(Java屋には無縁?)

77 ：73：01/09/27 00:33

>>74
言いたいことが分からないと言われても…
Ｃならグローバル関数になるような場合でもSingletonにしたほうが
よいのかな？と。
virtualを使いたいときに困るというのは分かりました。
Singletonでvirtualを使うときってどういう場合があるか思いつきませんが。

>>76
>まず、それがインスタンスである必然性があるかどうか、だ。
なるほど。ただSingletonの説明用サンプルってその必然性が
あまり感じられないんですけど。

>初期化の順序ってどういうこと?(Java屋には無縁?)
C++での話です。
class Hogeがあったときに、トップレベルで、

Hoge theHoge;

とかすると、コンストラクタが起動する順序を制御できない
という話だったと思います。

オブジェクト指向に不慣れなもので何か間違っているかもしれません。

78 ：デフォルトの名無しさん：01/09/27 00:36

>>76
A global_a;
B global_b;

これで global_a, global_b の間に依存関係がある場合（たとえば global_b の
コンストラクタ中で global_a を使ってる場合）、本来は

1. まず global_a を初期化
2. 次に global_b を初期化

とならないと困る。

C++ の仕様では、同一の翻訳単位にある非ローカルオブジェクトに関しては
定義順に構築されることが保証されているけど、翻訳単位が異なる場合には
初期化順序は保証されないので、まずい。

常套手段としては、グローバルスコープでインスタンスを宣言せずに、関数
ローカルに宣言することかな。

A& GetSingletonA()
{
　　static A a;
　　return (a);
}

こうすると、初めて GetSingletonA() が呼ばれた直後に、関数内で定義された
インスタンス a が構築されることが保証される。

あとは、処理系独自の拡張機能で、初期化順序を指定できる場合もある。

>>73
- インスタンスが解体される順序を指定できない。
- インスタンスの解体は main() から抜けた後に行われるため、エラー回復
　は絶望的。デバッグするのも不可能な場合がある。

79 ：74=78：01/09/27 00:45

>>77
static メソッド／グローバル関数と Singleton を対比しているのが謎なんだけど。

- データが絡まない単純な手続きだけなら、普通に関数にしておけば良い。
- データが絡むなら Singleton にすれば？　具体的な方法は >>78 で書いた通り

80 ：76：01/09/27 01:03

Singletonパターンは普通グローバルな実体インスタンスにはしないと思ってたから、
初期化の順序なんていくらでも制御できると思ってたけど。GoF本の「実装」節もまさにそのとおりだし。
グローバル変数で実体が作れるならSingletonであることを保証できないんじゃないの?
ま、>>78にある通り後処理の問題もあるから単にGoF本通りの実装にもならないかもしれんけど、
その辺のC++流儀までは知らないや。
>>77
インスタンスである必然性とは、GoF本の「結果」の5に書いてある通り、インスタンス数を1以外に
したい場合と、サブクラス化の可能性がある場合のみ。
そうでなければ全部グローバルな関数(static)として実装してもかまわない。そのへんはもう趣味
の範疇だよ。(というのはJava屋だからいえる。C++では後処理の考慮はいるね)

81 ：デフォルトの名無しさん：01/09/27 02:47

っていうかコンストラクタで依存関係がからむ初期化をするのはどうかと思うが。
普通、そういうときは別途初期化関数を用意しないか？

コンストラクタでなんでもやりすぎなだけじゃないかな。

82 ：76：01/09/27 03:22

そだね。でも後処理の問題は結局あるけど。
取り敢えずグローバルな実体オブジェクトは違うかなと。

83 ：Delギコ：01/09/27 17:12

|　| ∧　　　／￣￣￣￣￣￣￣￣
|　|Дﾟ)　＜　聞いてもいい？
|　⊂|　　　＼＿＿＿＿＿＿＿＿
|　|　|
|　|U
￣￣￣￣￣
結城先生ﾀﾝのJavaデザパタ入門読んでるんだけど

ガベコレのない言語では

　　Iterator it = bookShelf.iterator();
　　while (it.hasNext()) {
　　　Book book = (Book)it.next();
　　　System.out.println("" + book.getName());
　　}
　　bookShelf.deleteiterator();

この最後のdeleteiteratorが必要って事でいいのですか？

84 ：Delギコ：01/09/27 17:49

　　　　　　　　　 ∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　(ﾟДﾟ ,,)＜　　なるほど！
　　　　　　　＿φ＿⊂)__ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／旦／三／／|
　　　　　　　　|￣￣￣￣￣|　 | 　Javaのトークナイザを実装するためには
　　　　　　　　|愛媛みかん |／ , 　DelphiのCommaTextをAdapterに当てはめるとイイのか...
　　　　　　　　￣￣￣￣￣
　　　　　　　　GUI部品については委譲によるAdapterは不可能だぞっと。
　　　　　　　　Interfaceがあってヨカタヨカタ...

　デザパタってInterfaceが無いと実践が難しくないですか？

85 ：76：01/09/27 20:45

>>83
それをやるなら、bookShelf.deleteIterator()ではなく、delete it; (C++の場合)でしょう。
Iteratorのインスタンスはiterator()メソッドが呼ばれるごとに生成するのが普通であり、
返されたIteratorオブジェクトはbookShelfの手を離れます。

ただ、どっちにしてもクライアント(呼び出し元)に削除の責任を負わせるのは大変なので、
GoF本ではIteratorPtrという実装例が紹介されていますね。(SmartPtrみたいなもの)
>>84は何言ってるかよくわかんなかったよ。

86 ：Delギコ：01/09/27 21:22

＿＿_ 　ヽ
＿／⊂　｀∧ ∧　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　｜　|　＼(　ﾟДﾟ)＜　ありがとございます。>>85さん
　 | ／　　　∪ ∪　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
￣
その結城さんのJavaデザパ本には"deleteIteratorメソッドはJavaの場合必要ない"
と書かれていたので,bookShelfのメソッドかと思ったのですが
そういえば it を削除した方が話が早いですね。

>>84ではちょっと意味不明の事言ってしまいすいません。
このスレのログを見るとDelphiの人もいらっしゃるのですね。

>GoF本ではIteratorPtrという実装例が紹介されていますね。(SmartPtrみたいなもの)
auto_ptrみたいなものでしょうか？
ｶﾞｲｼｭﾂだったらすいません。

87 ：76：01/09/27 22:16

そう。それ>auto_ptr 鬱氏(藁
スコープはずれたら自動的にデストラクタ呼ばれるようにする仕組みね。
おれ本読んでないんだけどそんなこと書いてんのか>有機本

88 ：76：01/09/28 02:05

>>84
おいらはDelphi知らないけど、interfaceが無いと難しいってのはデザインパターンで行われているような
構造を発案するのが難しいって意味かな?それはあると思う(interfaceという言語の仕組みがあると頭
を整理しやすいという意味)。
でも「実践」が、デザインパターンの適用のことを指しているのだとしたら、それはinterfaceという仕組み
がなくても大した問題じゃない。これはSmalltalkを考えれば解るかと。
多重継承なしでinterfaceも無し、おまけにstrongly typeだったりしたら、さすがに「実践」も難しいだろうね。

89 ：デフォルトの名無しさん：01/09/28 03:18

>>88
> 多重継承なしでinterfaceも無し、おまけにstrongly typeだったりしたら、さすがに「実践」も難しいだろうね。
off topic だけど、C 言語で多態を実装する手段として、関数ポインタを並べた構造体
が使われてますね。

下のコードは UNIX Version 6 からの抜粋ですが、今の UNIX も基本的な考え方は
変わってないです（もっとも機種やバス依存性を抑えるために、高度に抽象化されて
ますけど）。

struct bdevsw {
　　int　　(*d_open)();
　　int　　(*d_close)();
　　int　　(*d_strategy)();
　　int　　*d_tab;
} bdevsw[];

ＯＯＰＬを使うと、従来はコールバック関数や関数ポインタを使って書いてた部分が
スマートに書けるのが便利。構造体を埋める代わりに継承、Enum*() でコールバッ
ク関数を呼び出す代わりに iterator と、ね。

90 ：Delギコ：01/09/28 13:43

　　ｱﾘｶﾞﾄｺﾞｻﾞｲﾏｽ
　　　∧∧　　　／￣
（＿(,,ﾟДﾟ)　＜　サンクスです。
⊂,,＿_つつ.　　＼＿

このスレはsage進行なんですね。

>そんなこと書いてんのか>有機本
deleteiteratorのこと書いてありますが、たかだか3行で
ﾀﾌﾞﾝC++知っててJavaをあまり知らない人に
ちょこっとせつめい程度に書かれたもののようなので、問題ないです。

>スコープはずれたら自動的にデストラクタ呼ばれるようにする仕組みね。
これをDelで実践するのは出来なくはないらしいですが面倒みたいです。
C++のauto_ptrも実装した人は面倒だったのかな。

>多重継承なしでinterfaceも無し、おまけにstrongly typeだったりしたら、さすがに「実践」も難しいだろうね。
strongly typeっていうのがよくわかりませんが
Delは多重継承なしで
interfaceはｻｲｷﾝのVersionになってから実装され
COM周りにからんでGUIDというみょうちくりんな数字が入るので、あまり使われていないみたいっす。

デザパタをやるにはInterfaceは積極的に利用しなければいけなさそうですね。

上の >>43などであがってますが
Singletonなんかも、DelにはコンストラクタのStatic宣言が出来ない(と思う)ので
なんか変な実装になってしまうなあ。
デザパタを勉強していても、妙に実装依存してしまう気がする…

91 ：デフォルトの名無しさん：01/09/28 13:49

>>90
>>スコープはずれたら自動的にデストラクタ呼ばれるようにする仕組みね。
>これをDelで実践するのは出来なくはないらしいですが面倒みたいです。
Delphiでもinterface相手だとスコープ抜けるだけで確実にRelease呼んでくれるから
interfaceにしてReleaseを自分で実装しちまえばいいってかんじ?

>C++のauto_ptrも実装した人は面倒だったのかな。
C++はもともとスタック上オブジェクトはスコープ出るときにdestructor呼ばれるから
スタック外オブジェクトもスタックオブジェクトで包むだけでいいから比較的簡単だね。

92 ：Delギコ：01/09/28 15:34

>Delphiでもinterface相手だとスコープ抜けるだけで確実にRelease呼んでくれるから
　∧ ∧ 　　／
　( ﾟ∀ﾟ)　　＜　　そういう仕組みでしたか。
　 | つ[|lllll］).＼　ニャルホド
～| 　 |
　 ∪∪

>C++はもともとスタック上オブジェクトはスコープ出るときにdestructor呼ばれるから
　　そうか。おっしゃるとおりでｺﾞｻﾞｲﾏｽ。

　∧ ∧　　／ Prototypeを勉強しました。
　(,,ﾟДﾟ)　＜　　CloneメソッドなんてのはDelphiでどやって実装しますでしょう。
　 |つつ　　＼サブクラス側で実装しておく必要があるのでしょうか。
＠|　　| 　　　JavaでもCloneをｵﾊﾞﾗｲﾄﾞするのと一緒かな？？
　 ∪∪
　　　　　あと、interface変数にオブジェクトを代入したりも出来ないような
　　　　　気がするのですが・・・
　　　　　Prototypeの実装ってDelで出来るものなんでしょうか。

93 ：デフォルトの名無しさん：01/10/05 06:08

デザパタをありがたがっているような奴はクズ。
あれぐらいモデリングをしっかりすれば自分で考え出せるだろう。
デザパタの意義は、カタログにしたその取り組みにあるだけ。

94 ：デフォルトの名無しさん：01/10/05 16:17

>>93

その「自分で考え出す」手間を省くためのデザパタだろう。
さらに「自分で考え出したパターンを他人に説明する」手間も省ける。

そのためのデザインパターンだ。

もしかして車輪の再発明大好きな人デスカ？

95 ：デフォルトの名無しさん：01/10/05 19:32

そのうち俺的デザパタなんかつくって
同僚にでも読まそうとするのかモナ。

96 ：デフォルトの名無しさん：01/10/09 15:44

「え？それって○△のこと？」
と、自分の知らない有名なパターン(非GoF)を挙げられる。
に２００オクタット。

97 ：デフォルトの名無しさん：01/10/09 17:07

>>93
コピペしてる人間に言われたくないね。

98 ：デフォルトの名無しさん：01/10/09 20:41

非GoFな有名なパターンどっかにまとまってない～？

99 ：デフォルトの名無しさん：01/10/10 10:53

>>98
PLoP Japan
http://www.kame-net.com/jplop/

「プログラムデザインのためのパターン言語」
http://www.amazon.co.jp/exec/obidos/ASIN/4797314397/ref=pd_sim_b_dp_1_2/250-7533692-1453818

100 ：デフォルトの名無しさん：01/10/11 05:42

>>99
｢プログラミングデザインのためのパターン言語｣
はACEフレームワークに使われているパターンが中心やね。
分散処理のパターンとかネットワーク関連の人には
結構参考にはなると思われ。

101 ：99：01/10/11 12:53

>>100
そうですね。GoF本のような一般的なデザインパターンはそれほど多くはない
ですね。今本が手元にないのですが、Null ObjectパターンとActive Object
パターンくらいしか思い出せません。

後半には開発プロセスのパターンとかフレームワーク進化のパターンとか、
面白いけどこっちが期待しているのとは異なるものも入ってたりします。

102 ：デフォルトの名無しさん：01/10/12 00:03

結城さんとこにもいくつかあるね。
NullObjectパターンもあった。これはすぐにでも使えそう・・・。
http://www.hyuki.com/dp/dpinfo.html

103 ：_：01/10/12 07:22

結城さんのJava言語で学ぶデザインパターン入門はいい本ですか？
具体的なプログラムがのってたりしますか？
買おうか迷ってるので教えてください。

104 ：デフォルトの名無しさん：01/10/13 02:32

>>103

あなたがどうしようもないぐらいプログラマに向いていない場合は、いい本と
感じるでしょう。

105 ：デフォルトの名無しさん：01/10/13 17:34

>>103
私はわかりやすいと思いますよ。

＞具体的なプログラムがのってたりしますか？
とりあえず、短い動かせるプログラムが載ってます。

106 ：デフォルトの名無しさん：01/10/13 17:48

>>103
サンプルコードは(本を持ってなくても)著者のホームページから
ダウソロードできるよ。

107 ：デフォルトの名無しさん：01/10/13 17:52

>>103少し読んでみました
僕が、OOを知って2,3ヶ月の頃ならすごく分かりやすいだろうなと感じました
ただ、どうしても、GoFに比べ内容が不十分なため、
読む人がどういうレベルであるかで「分かりやすさ」が違うと思います

とはいっても、GoFでさえStrategyやAdapterのような
非パターンに属するものもデザパタとして含まれていたりするので、
どんな本を読む場合でも、考えながら読むようにしたほうが良いと思います

108 ：デフォルトの名無しさん：01/10/14 19:41

結城本を買うかどうかの簡単な自己診断法。
GoFを読んで「こりゃちんぷんかんぷん、歯が立たん」と思ったら結城本。

109 ：デフォルトの名無しさん：01/10/14 21:31

>>108
分かりやすくていいな、その判断法。

110 ：デフォルトの名無しさん：01/10/15 00:07

GoFを買わずに済ます方法。ET++を眺める。

111 ：デフォルトの名無しさん：01/10/15 00:57

本書くといくらお金もらえますか？

112 ：デフォルトの名無しさん：01/10/15 03:08

>>111確かに、知りたいよね
1冊につき、どれくらい貰えるのかなぁ
それ以前に、どうやったら著者に選ばれるんだろ？

113 ：デフォルトの名無しさん：01/10/15 03:43

1600円の本を5000冊刷って
6％なら48万円。

刷る数、印税率は実力次第。

114 ：デフォルトの名無しさん：01/10/15 04:02

数人の共著ならさらに安くなる。
時給にすれば数百円と思われ。

115 ：デフォルトの名無しさん：01/10/15 07:16

>>112
コンピュータ関係だと、印税は 8% 程度だと思います。（私はそうだった）

あと印税は売れた数ではなくて、刷った数で支払われる。だから初版で 5000 部
出れば、売れ残ってもそれだけ支払われる。また増版がかかれば、その時点で
追加の印税が入る。

> それ以前に、どうやったら著者に選ばれるんだろ？
ほんとに書きたいなら、原稿持ち込めば？　俺は最初は会社経由で仕事がきた
んだが、それで成果を上げたら直に話が振ってきた。まずは企画案を出すのが
スタートで

1 企画案を作って編集者に連絡
2 編集者が出版社の企画会議を通す
3 執筆開始

となる。

あと知り合いでは、出版されていた書籍の山のような間違いにうんざりして、レポー
ト用紙10枚分ぐらいの修正、分かりにくいからこう書き直せという訂正を送りつけた
ら、編集者から

「うちで書いてみません？」

と誘われた人間がいましたね。

いずれにせよ、コンピュータ関連の書籍だけで十分な収入を得るのは難しいです。
ただし、人に合ったときに名刺代わりに著書を渡せるのは、コンサルタント屋さんな
んかには直接的な収入以上の価値があるかもしれません。

116 ：デフォルトの名無しさん：01/10/15 09:33

>>112
自分が本書くのに向いているかどうか、試してみたことあるYO。
雑誌の連載記事を書くという想定で、企画案作って、記事の連載計画作って…、
とやってみたが、記事の本文書き始める前に飽きて挫折。不向きと分かってｳﾏｰ。

117 ：デフォルトの名無しさん：01/10/15 15:41

>>110
GoFのデザパタにでてくる例、ET+がやたら多いよね。
なぜなのだろう？

118 ：110：01/10/16 01:15

ETの初期設計をしたのはGoFのEricだから。でもeXtremeProgrammingと
DesignPatternは、なぜ反することが多いのだろう。同じ人なのに...

最終形態としてPatternを織り成すように構成される。（はいはい。
それはTestCodeを変更しないという前提だ。TestCODEを境界設計に
依存させないようにするってことですか？(無理ですぅー。)

119 ：でむぱ：01/10/16 01:19

織り成して組み立てるのではない。生成されたものを括り取る。
全ての末裔を定め、多重なる混沌を、不正集約された委譲を。
そうして空虚になったNullObjectの刃を入れる。彫刻の様に
R.U.OK?

120 ：117：01/10/16 03:13

>>118
なんと。同じ人が関わっていたのですか。
知らなかった…。

121 ：デフォルトの名無しさん：01/10/19 05:25

デザパタを学ぶのに適しているライブラリはET++以外にどんなものがあるのかなぁ
あと、Smalltalkは、やっておくべきなのかなぁ

122 ：デフォルトの名無しさん：01/10/25 02:51

>>121
＞あと、Smalltalkは、やっておくべきなのかなぁ
どうだろう？
でも、C++とはまた毛色が違う言語らしいから、オブジェクト指向プログラミングを
理解するという面では、面白いかもしれないぇねぇ。

123 ：デフォルトの名無しさん：01/10/25 03:10

ピンクのXP本にあるペアプログラミング例を読むと思わず使いたくなる。
といいつつ使ってないけども。

124 ：デフォルトの名無しさん：01/10/29 10:06

AbstractFactoryパターンと、FactoryMethodパターンの違いがいまいち理解できません。
構造的に違いはそれほど無く、
生成するものが複数か、単数かの違いという理解でいいんでしょうか？

125 ：デフォルトの名無しさん：01/10/29 11:35

自分が本書くの不向きだと気づかずに、編集者に企画投げて、
OKもらったのはいいが、今書いててめんどくさくて泣きそう。
ﾏｽﾞｰ

126 ：デフォルトの名無しさん：01/10/29 16:21

>121
Mac畑の経験でいえばMacApp(藁

SmallTalkもいいと思うよ、
Objective-C(Smalltalk風C)+Cocoa(openstep?nextstep?)を
つかってみて目から鱗がぼろぼろ落ちたもん＞俺

127 ：デフォルトの名無しさん：01/10/29 16:46

SmallTalkはﾏｶｰの証。

128 ：デフォルトの名無しさん：01/10/29 17:25

Ｑ．SmallTalk と Smalltalk はどちらが正しいか？

Ａ．後者。（理由：SystemDictionary にそう登録されているから。）

"Class SystemDictionary represents a special dictionary that supports
protocol for asking questions about the structure of the system. The
default instance is Smalltalk. Currently the programming environment
does not support having more than one instance."

129 ：デフォルトの名無しさん：01/10/29 18:10

HyperTalkとタイプする癖がついてるみたいだな。

130 ：デフォルトの名無しさん：01/10/30 20:13

>>124

あるクラスが必要とするパーツをそのクラスの中で生成してしまうのが
FactoryMethod。パーツの生成のために別のクラスを立ててしまうのが
AbstractFactory…と理解しているけど。

FactoryMethod から、パーツ生成以外のメソッドを削ると、
AbstractFactory と同じ形になっちゃう。

131 ：デフォルトの名無しさん：01/10/30 20:26

>>130
FactoryMethodは、生成メソッドを
サブクラスでoverrideすることによって、
生成物が変わる。つまり「継承」「クラス」が
基本となるパターン。

AbstractFactoryは、>>130の言う通り、
生成するオブジェクトを外に持つことが本質。
そのオブジェクトを切り替えると生成物が
変わる。つまり「コンポジション」「オブジェクト」
が基本となるパターン。

Javaだと例えばFactoryMethodは、
interface Document { ... }
abstract class ApplicationFramework {
　DocumentList docList = ...
　public void newDocument() {
　　// 「新規文書」操作を行うTemplate Method
　　Document doc = CreateDocument();
　　docList.add(doc);
　　doc->open();
　}
　protected Document createDocument();
}

class MyApp extends ApplicationFramework {
　protected Document createDocument() {
　　return new MyDocument();
　}
}
のように、TemplateMethodパターンと組み合わせることが
多くなる。

132 ：131：01/10/30 20:27

プログラム一部おかしいけど気にしないで。

133 ：124：01/11/01 00:45

ありがとうございます。
AbstractFactoryの方は、C++のSTLで使われてる
アロケータみたいな用法のこと、でいいんですよね？

134 ：デフォルトの名無しさん：01/11/07 18:53

サーバーからメッセージを受けて処理するクライアントを作ってるのですが
デザインパターン的にはどれがいいのでしょう。
スレッドでパケットを受けて、そのパケットの処理をして
メッセージを仕分けしてイベントを通知してデータ処理をするって
具合にしたいのですが。
すっきりと整理できたらなと思っています。

135 ：デフォルトの名無しさん：01/11/07 21:18

>>134

そういう場合は、

「スレッドでパケットを受けて、そのパケットの処理をしてメッセージを仕分
けしてイベントを通知してデータ処理パターン」

を使いましょう。

136 ：長いのはいやづら：01/11/07 21:24

>>135
名づけて？

137 ：デフォルトの名無しさん：01/11/07 21:25

>>136
「スレッドでパケットを受けて、そのパケットの処理をしてメッセージを仕分
けしてイベントを通知してデータ処理パターン」

138 ：長いのはいやづら：01/11/07 21:28

>137
頑固者め

139 ：デフォルトの名無しさん：01/11/07 21:33

>>135-138
ﾜﾗﾀ

140 ：134：01/11/07 23:32

>>135-138 ありがとうございました。

141 ：デフォルトの名無しさん：01/11/08 00:35

>>134
SOFTBANKから出てる「プログラムデザインのためのパターン言語」の
2章にそこらへんのパターン載ってるよ。翻訳が難しげだけど。
http://books.softbank.co.jp/bm_detail.asp?sku=4797314397

これ読んだらACE使ってみたくなった。

142 ：134：01/11/08 01:25

>>141 貴重な情報ありがとうございます。早速買ってみたいと思います。

143 ：デフォルトの名無しさん：01/11/08 08:04

似たような目的で「パターン言語」読んだけど、
正直いまいちだと思ったさ。

144 ：デフォルトの名無しさん：01/11/18 21:39

あげ

145 ：デフォルトの名無しさん：01/11/20 07:43

age

146 ：デフォルトの名無しさん：01/11/26 18:49

GoF本の訳って信じても良いのでしょうか？
なんかもー、いきなり定義されてない言葉を使ってくるので参ってます。

しばしば出てくる「責任」の明確な定義だけでも教えていただけませんか？

あとガイシュツっぽいけどﾜﾗﾀので…
「ギコ猫とデザインパターン」
http://www.hyuki.com/dp/cat_index.html

147 ：デフォルトの名無しさん：01/11/27 11:24

責任ってResponsibilityの訳でしょ？
一般的な言葉だからわざわざ説明するようなもんでもないと思うけど。

148 ：デフォルトの名無しさん：01/11/27 22:09

>>147
レス有り難うございます。ほんの一例ですが…
「クラスが責任をいくつかのサブクラスの中の1つに委譲するときに、
どのサブクラスに委譲するのかに関する知識を局所化したい場合。」(p116)

「生成の責任」だとは思うのですが…私見ながら、技術書ならきっちり明示して欲しいなぁ、と
原書をお持ちのようですが、ここはthe responsibilityとa responsibilityのいずれなのでしょうか？

149 ：通りすがり：01/11/27 22:46

想像だけど、'its responsibility'じゃないの。>>148

150 ：デフォルトの名無しさん：01/11/27 23:29

>>149
おお！ならばこの「責任」はプログラマならば
知っていなければならない様なテクニカルタームではなく、
単に「何かに対する」責任を示しているだけなのですね。
…うーん、それなら簡単にでも修飾語が欲しかった。

レスありがとうございました。何だか、こんな箇所ばかりですが
こういうもんだと割り切って、読み進むことができそうです。

151 ：デフォルトの名無しさん：01/11/28 00:15

クラスが責任を委譲といえば、本来そのクラスが担うと思える責任を他のクラスが果たすってことだから、
「責任」を「機能(を実現する為の実装)」のように受け止めれば?、とおもう。

152 ：デフォルトの名無しさん：01/11/28 03:51

責任をうまく説明するのは難しいが…

例えば、method(x)を実行する時、x>0という条件がつく場合、
実行元のコードにx>0を確かめるコードを書くか、
method(x)の中にx>0を確かめるコードを書くか…ってこと
つまり、どっちに「責任」を持たせるかはっきりさせようってこと

どちらにも書いた場合(責任をはっきりさせなかった場合)の弊害
　1.x>0の確認が2回実行される
　2.同じ責任を実行するコードが分散する
　3.(2)のせいで、もし、x>=0に仕様変更があった場合、
　　すべてを直すのが面倒臭いし、直し忘れるかもしれない

153 ：デフォルトの名無しさん：01/11/28 13:00

>>150
テクニカルタームでない、とはいえない。OOにおいて責任(責務と訳す場合も
ある)というのは重要なタームだから。

>>151
機能というより「役割」では？
システムのある機能を実現するために果たすべき役割をどのオブジェクトに
割り振るか、ということですね。で、割り振られたオブジェクトはその役割
について責任をもつ、と。

154 ：デフォルトの名無しさん：01/11/28 15:08

>>148
CRCカードの"Ｒ"であることにも留意されたし。

155 ：デフォルトの名無しさん：01/11/28 15:27

>>154 CRCカードって何？よく聞くんだけど…。

156 ：154：01/11/28 19:08

>>155
Class-Responsibility-Collabolation
ttp://c2.com/doc/oopsla89/paper.html#cards

157 ：デフォルトの名無しさん：01/11/28 23:01

GoF23パターン以外の基本的なパターンってどんなのがありますか？

158 ：デフォルトの名無しさん：01/11/29 00:04

int main()
{
return 0;
}

NULLプログラムパターン

159 ：デフォルトの名無しさん：01/11/29 00:10

２３個しかねえの？
あのなー。

160 ：デフォルトの名無しさん：01/11/29 00:11

あんなので良ければ、俺でさえ３００は出せるから
世間のを全部合わせりゃ１０００は逝くだろ。
デザパタヲタ信で良し。

161 ：デフォルトの名無しさん：01/11/29 00:23

>>160
その 300 個をとりあえず書いてみ？

162 ：デフォルトの名無しさん：01/11/29 00:36

int main()
{
　　char buf[32];
　　scanf("%s", buf);
　　printf("%s", buf);
　　return 0;
}

ノーガードパターン

163 ：デフォルトの名無しさん：01/11/29 00:40

>>162
ネタは sage で書け。

164 ：デフォルトの名無しさん：01/11/29 01:09

少ない数にまとめたってところがミソなんでしょ

165 ：デフォルトの名無しさん：01/11/29 01:14

int main()
{
　　int c;
　　c = getchar();
　　if (c >= 'A' && c <= 'Z') {
　　　　printf("Large\n");
　　else (c >= 'a' && c <= 'z') {
　　　　printf("Small\n");
　　}
　　return 0;
}

キャラクタセット依存パターン

166 ：デフォルトの名無しさん：01/11/29 01:27

全然デザインレベルじゃないし。

167 ：Kusakabe Youichi：01/11/29 01:28

>>165: デフォルトの名無しさん wrote:
> 　　else (c >= 'a' && c <= 'z')

Cではできないですね :)

168 ：デフォルトの名無しさん：01/11/29 01:33

誤植ですね。編集部に伝えておきます。

169 ：デフォルトの名無しさん：01/11/29 01:36

>>157
developer.java.sun.comにJ2EEパターンってあるよ。
Webアプリを５層に分けて考えて中間３層で、いろんなパターンを考えてる。
基本的かどうか知らんけど、なかなか面白かった。

170 ：157：01/11/29 01:44

>>162,165
デザパタというよりイディオムに近いですね
>>160
GoF以外の「有名な」パターンに質問を少し変えます
開発時にパターンネームを共有することも目的の1つなので
>>158
ネタに埋もれようとしているが、考えてみると含蓄深いパターンかもしれない…

171 ：デフォルトの名無しさん：01/11/29 01:50

>>170
Null パターンというのは、実際にあるよ。

172 ：157：01/11/29 02:53

>>171
NullObjectパターンなら知ってますが…
それ以外のNullxxxは初めてなんですよ

173 ：デフォルトの名無しさん：01/12/03 09:55

デザインパターンFAQ
http://www.hyuki.com/dp/dpfaq.html

174 ：デフォルトの名無しさん：01/12/25 18:42

age

175 ：command：01/12/25 18:53

コマンドパターンについて、詳しく教えてほしいのですが。
できれば簡単な例とともに。
ジャヴァでも、シープラスプラスでも、
オブジェクトパスカルでも良いです。

176 ：デフォルトの名無しさん：01/12/25 20:42

>>175
google 逝きましょう。いくらでもサンプルあるぞ。

177 ：age：02/01/26 13:31

age

178 ：デフォルトの名無しさん：02/01/26 15:41

うちの同僚に、どこかで権威から承認された"パターン"になった
瞬間に盲目的にありがたがるくせに、今までそれと同じような事を
やっていたのにそれは糞味噌言うアホがいますが、こういうやつ
はどのように扱うべきでしょうか？

創造的作業が嫌いならPGなんかやらなきゃいいのに、と思っている
のですが…

179 ：デフォルトの名無しさん：02/01/26 16:07

糞味噌...

例挙げて、冷静にメリット/デメリットを討論できないのが問題。

180 ：デフォルトの名無しさん：02/01/26 23:45

>>178
日本語がおかしいYO!!
えー、権威に弱いタイプは、詐欺に引っかかりやすい
傾向があります。壺でも売りつけるのが良いでしょう。
…いや真面目な話、その気持ち良く分かります。で、これ↓

会社のPCをたたき壊した後、同僚を机上に押し倒す
　　↓
「パターンは方法じゃ無い！あくまで伝達の手段だ！」と、言い放つ
　　↓
机の上、同僚の顔すれすれに、マウス突き刺す
　　↓
「行くあてはありません」と、何故かベレー帽をかぶった上司に言う
　　↓
(ﾟдﾟ)ｳﾏｰ

181 ：デフォルトの名無しさん：02/01/27 00:39

>>180
ランボーかよ、オレも見てた（ｗ
ま、確かにパターンの意味をはき違えてるわな＞同僚

182 ：デフォルトの名無しさん：02/01/27 00:50

>>180
マウス突き刺す…どんなマウスだよ！ｗ

そういや、多機能マウスってあってもいいよな
定規・温度計・ドライバ付きみたいな

183 ：デフォルトの名無しさん：02/01/27 01:28

マウスに付いた定規やドライバを何に使うのか小一時間（省略）
リモコン付きマウスなら欲しい気がするが・・・・・・

184 ：デフォルトの名無しさん：02/01/27 10:07

電話つきマウスは持ってるぞ。
うちダイヤル回線だからつかえねぇ・・・。

185 ：Ｃ屋：02/01/31 13:30

遅ればせながら結城本買いました。
GoF本が本棚の奥の奥に眠っている漏れには
ありがたい本です。

激しくｶﾞｲｼｭﾂですが、結城さんのｷﾞｺ猫頁には
ﾜﾗﾀ。漏れはｸﾘｽﾁｬﾝではありませんが、その
他の頁もよい感じですね。

ただ、今使っているのがCなので、実践で活用
するにはいろいろ障壁がありそうです。構造体
＋関数へのポインタでクラスを実装している程
度のところに持ち込むのは難しいのかなぁ？
どなたかやられた方はいらっしゃいますか？

186 ：デフォルトの名無しさん：02/02/25 04:11

age

187 ：デフォルトの名無しさん：02/02/25 04:34

>185
http://www.sage-p.com/process/cool.htm
こんなのはあるけどCでOOPはあんまりお勧めしないな。
N88BASICで構造化プログラミングするのと同じくらい空しいよ。

俺も今はCのプロジェクトやってるけどあえて無理にOOではやらない。
Cでself->set_value(self, 10)なんて珍妙なコードは書きたくない。

188 ：デフォルトの名無しさん：02/02/25 09:30

coolってMSが捨てたやつを思い出した・・・

189 ：デフォルトの名無しさん：02/02/25 09:33

C#の（初期の）開発コードネームじゃないの？Coolって

190 ：デフォルトの名無しさん：02/02/26 11:36

>>189
そうらしいけど MS は否定してなかった？
“COOL は C++ のライブラリだ！”っていうのが MS の主張していた事だったと
思う。結局 C# になったんだと思うんだけど。

とすると WFC For C++ ≒ COOL かな？

191 ：デフォルトの名無しさん：02/03/18 17:41

age

192 ：デフォルトの名無しさん：02/03/18 20:47

おっす。おら、デザパタ初心者だ。

で、みんなに聞きたいんだけど、いわゆるデータベースのフロントエンド
となるアプリを作るときに使えるパターンってないもんかね？

MVCとかBCEを使って（これ、アーキテクチャパターンか）M→Vのところに
Observerとか、データベースとのコネクションをSingletonとか、追加、訂正、
読取専用とかの状態を示すのにStateとか考えたんだけどどうよ？

193 ：JPLoPとは無関係な名無し：02/03/19 00:52

>192
良い考えだと思います。ただし良くまとめ親しみやすい命名をすると
Persister(Entity?)とかTransactionContextとかあるようです。
また、QueryIteratorは良く使いますが、ほとんど正規化できない
RDBの表定義にSQLUtilityはいい考えだと思いません。
TransactionContextはSingletonとかFlyweightとかに似ていますが
目的が違いますね。PoolingはFlyweightですが。
ちなみにデザインパターンはトランザクションとかスレッドとかが絡むと
今までのGoFのパターンとは違う扱いになる場合が多いいような気がするの
は気のせいでしょうか？＞お前等べ

194 ：デフォルトの名無しさん：02/03/19 01:12

>>192
>追加、訂正、読取専用とかの状態を示すのにState

ってもうちょっと具体的に教えて。

195 ：デフォルトの名無しさん：02/03/19 01:21

SQLUtilityって、アホかと思ったね。どこかで自画自賛してるマヌケ
を絞め殺したい。システムの規模が小さくて、SQLのスタイルをかなり
限定して規則化出来るような時にしか、意味がない。

副問い合わせとか、複雑な条件節設定とか、ベンダ毎のSQL仕様の差異
とか、テーブル側の激しい仕様変更（藁とか、結局吸収できないっしょ？

つうか、そんな簡単にどうにかなるんだったら、今までインピーダンス
ミスマッチで苦労していた技術者がみんなアフォだということになるな。

SQL一本を、SQL本体とバインドパラメータでパラメータ化して、
Persister（用語と概念との対応がよくワカランが…多分これでしょ）
のインスタンス一個を割り当てるというほうが、すっきりする気がする。

196 ：デフォルトの名無しさんｋ：02/03/19 17:49

ModernC++Design的なパターンがこれからは常識になっていくんでしょうか？

197 ：デフォルトの名無しさん：02/03/19 19:12

>>194

追加、訂正、読み取り専用とかの状態によって、初期化とかエラーチェック
とか変わるでしょ？そのときに、State で隠してあげるといいのかな？と。

エラーチェックとかのビジネスロジックを、Strategyにしたほうがいいのか
悩み中。

198 ：デフォルトの名無しさん：02/03/20 23:48

>>197
そういえば、StateとStrategyの違いってよくわからん。

199 ：デフォルトの名無しさん：02/03/21 03:37

>>198
おもに内部の情報をもとに振る舞いを決めるのがState。
おもに外部からの情報をもとに振る舞いを決めるのがStrategy。

「おもに」というのが曲者で、Stateパターンでは、
外部からのイベントと内部の現在の状態、あるいはそのオブジェクトが
置かれている状況のある状態をもとに次の状態が決まる。
で、次の状態になるとき、あるいはなった直後
に振る舞いに相当するアクションが実行される。
そういう意味で「おもに内部の情報をもとに…」と表現した。

Strategyパターンでは、Strategyオブジェクトが置かれる状況
(GoFではContextといっている)によって、どのような振る舞いを
するかを決める。この場合はStateパターンがコンテキストの内部
状態の違いを見ているのに対して、Strategyパターンではコンテキスト
そのものの違いを見ている。だから「おもに外部…」。

というのはどうだ？
ちょっとこじつけっぽいかもしれんが。

200 ：199：02/03/21 03:41

>>197
エラーというのは状態なんではないだろうか。
だからStateパターンだと思う。

ビジネスロジックそのもの、もしくはその一部が
切り替わるのに応じて振る舞いが違ってくるような
ところではStrategyパターンということになると思う。

201 ：デフォルトの名無しさん：02/03/23 15:37

『Core J2EE Patterns』<http://www.phptr.com/corej2eepatterns/>を
読み始めようとしているんですが、読み進めていくうえでのポイントとか
ってありますか？＞読んだひと

202 ：デフォルトの名無しさん：02/03/23 20:14

デザインパターンに慣れる
第1章 Iterator ― 1つ1つ数え上げる
サブクラスにまかせる
第2章 Adapter ― 一皮かぶせて再利用
第3章 Template Method ― 具体的な処理をサブクラスにまかせる
インスタンスを作る
第4章 FactoryMethod ― インスタンス作成をサブクラスにまかせる
第5章 Singleton ― たった1つのインスタンス
第6章 Prototype ― コピーしてインスタンスを作る
第7章 Builder ― 複雑なインスタンスを組み立てる
第8章 Abstract Factory ― 関連する部品を組み合わせて製品を作る
分けて考える
第9章 Bridge ― 機能の階層と実装の階層を分ける
第10章 Strategy ― アルゴリズムをごっそり切り替える
同一視
第11章 Composite ― 容器と中身の同一視
第12章 Decorator－飾り枠と中身の同一視
構造を渡り歩く
第13章 Visitor ― 構造を渡り歩きながら仕事をする
第14章 Chain of Responsibility ― 責任のたらい回し
シンプルにする
第15章 Facade ― シンプルな窓口
第16章 Mediator ― 相手は相談役1人だけ
状態を管理する
第17章 Observer ― 状態の変化を通知する
第18章 Memento ― 状態を保存する
第19章 State ― 状態をクラスとして表現する
無駄をなくす
第20章 Flyweight ― 同じものを共有して無駄をなくす
第21章 Proxy ― 必要になってから作る
クラスで表現する
第22章 Command ― 命令をクラスにする
第23章 Interpreter ― 文法規則をクラスで表現する

yuki本より

203 ：デフォルトの名無しさん：02/03/28 16:46

GOF のp25 最後の行からなんだけど、
「型(TYPE)はインターフェイスを表現するのに使われる・・・」
ってあるんだけど、ここで言ってる型ってのが意味不明なんだが、クラスのタイプって
ことなのかな？？？？？

204 ：デフォルトの名無しさん：02/03/28 18:01

>>203
その文脈だと TYPE は C++ なら class, struct のことだと思われ。

インターフェースは、そのメソッドが受理できるメッセージの集合を規定する
わけだが、C++ ではそのために

1. 純粋仮想関数から構成される struct, class を作る。
2. 実装クラスに 1 で作った struct, class を継承させ、実装を与える。

という手段をとるよね。Java だと interface/implements だし、そもそも型
チェックがない言語だと、この手間は不要なわけだが。

205 ：デフォルトの名無しさん：02/04/02 21:27

保存age

206 ：デフォルトの名無しさん：02/04/02 21:48

StateとStrategyの一番大きな違いは、StateはStateオブジェクト自身が、
他の状態に遷移する方法を持っているところにあると思ってるけど、ちがう？

207 ：デフォルトの名無しさん：02/04/02 21:52

大きな違いというかそもそも別物じゃん
クラス図は似ているが用途・発想はぜんぜん違う

208 ：デフォルトの名無しさん：02/04/02 22:00

用途も発想もぜんぜん違うものを、共通項を出して同じパターンを適用するのも、
デザインパターンなのでは？

209 ：デフォルトの名無しさん：02/04/02 22:34

･･･

210 ：デフォルトの名無しさん：02/04/02 22:49

>>207
どう違うのか言え

211 ：デフォルトの名無しさん：02/04/02 23:23

>>210
どう似ているのか言え

212 ：デフォルトの名無しさん：02/04/02 23:26

>>207 でクラス図が似てるって書いてるけど

213 ：デフォルトの名無しさん：02/04/02 23:34

だめだこりゃ

214 ：デフォルトの名無しさん：02/04/02 23:49

ファウラーなんかは、どっちでも同じだと述べてるね、「リファクタリング」の中で。
現場だと実際判別つかんぞ！！

215 ：sage：02/04/03 00:34

第２４章　すっかり頭が固くなって自分では何も発想できなくなる。
　　　　　また、問題点を自ら発見する事もできなくなる。　

216 ：デフォルトの名無しさん：02/04/03 02:50

Strategy...仕方なく変える。あるいは変えたほうが望ましいので変える。
State...変わっていくことが前提。

うーん大雑把すぎるなあ。

ロジックを変更するのがStrategy。
状態の変化をロジックに内包してるのがState。

こんな感じではどう？

217 ：デフォルトの名無しさん：02/04/03 03:23

直訳
Strategy 戦略
State 状態

218 ：デフォルトの名無しさん：02/04/03 08:46

State 状態遷移図をコードに落としたもの
Strategy State以外の多態を使って実行時にコードを差し替えたいもの

>クラス図は似ているが用途・発想はぜんぜん違う
同意。

>現場だと実際判別つかんぞ！！
それだと「デザパタ使うと話が早い」という
メリットがなくなってしまいますが？

219 ：デフォルトの名無しさん：02/04/03 15:35

>>214
「リファクタリング」P227 動機を見るとしっかり使いわけてるようですね。

Strategy　単一のアルゴリズムを単純化しようとしている場合。
State　　　状態に特有なデータを移動しようとしており、オブジェクトの状態が変わるものと考えられる場合。

220 ：デフォルトの名無しさん：02/04/09 13:46

age

221 ：|Dﾟ)：02/04/13 17:00

　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　|　まずアレ作れ。アレ。　　　　,＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　|　次はこれだ。　　　　　　　　　|　が、
　　Director　　|　つーかﾁﾝﾀﾗすんなｺﾞﾙｧ！　|　　がんばらせて頂きます…
.　　　　　　　　　￣|/￣￣￣￣￣￣￣￣￣￣　￣)ﾉ￣￣￣￣￣￣￣￣￣￣
　　　　 ∧∧　　　　　　　　　　　　　∧＿∧　　Builder　　∧＿∧　　　　　　　　　　　　＿
　　　　 (#ﾟДﾟ)　　)）　　　　　　　　　（´∀｀；,）　　　　　　　（,；´∀｀）　　　　∧＿∧　　／／L__
　　,＿（_う　つ＜i　　　　　　　　　と_　と　）　　ΞΞ　（　つ　つ　ヾヽ（；´∀｀）　 |￣|＿／|
　　ﾄ-人　,　〉　　　ﾊﾔｸｼﾛﾔ！　.　　　ヽY　ﾉ　　　 .Ξ　　）　）　）　　　 ,（　つ　づ｢　|　　 |／|
　　ヽ＿(/　J　　　　　　　　　　　　　　（＿_）_）　　　　　（＿_）＿）　　　（＿_）＿ソ　`|＿＿|／
　　　　　　　　　　　　　　　　　　　　　　　　　　　　ｱｸｾｸ　　　　　ｱｸｾｸ　　　　　　　　　　　　　Product

222 ：|Dﾟ)：02/04/13 17:00

　　　　＜￣￣￣￣￣￣￣￣￣￣￣￣￣ﾞﾞ＞
　　　　＜　げっとりざ～～～～ると！！！＞
　　　　＜＿　＿＿＿＿＿＿＿＿＿＿＿＿.＞
　　　　　　　|/
　　　　 ∧∧　　　　　　　　　　　　　　　　　　　　　　　　　　　ﾋﾞｸｯ！　　　　　　　　　　＿
　　　　 (#ﾟДﾟ)　　)）　　　　　　　　　　　　　　　　　　　　　　　　　　　　Σ　∧＿∧　　／／L__
　　,＿（_う　つ＜i　　　　　　　　　　　　　　　　　　　　　　　　　　　　Σ　（；´∀｀）　 |￣|＿／|
　　ﾄ-人　,　〉　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ,（　つ　づ[] .｢　 . |／|
　　ヽ＿(/　J　ｹｯｶﾓｯﾃｺｲ！　　　　　　　　　　　　　　　　　　　　（＿_）＿ソ　`|＿＿|／

223 ：|Dﾟ)：02/04/13 17:01

　　　　　　　　　　　　　　　|　結果です… どうぞ
　　　　　　　　　　　　　　　|＿＿＿＿　＿＿＿＿＿
　　　　 ∧∧　　　　　　　　　　　＿　ヽ(　 .∧＿∧
　　　　 (　ﾟД)　　　　　　　　　／／L__　　（´∀｀；）　)）
　　,＿（_う　つ＜i　　　　　　　|￣|＿／| と　と　　） "
　　ﾄ-人　,　〉　　　　　　　　.｢　 . |／| 　〈　（　（
　　ヽ＿(/　J　　　　　　　　　 |＿＿|／　（＿（＿_）
　　　　　＿＿＿＿|＼＿＿＿＿＿＿
　　　　 |　あ、やっぱそれイラネ。
　　　　 |

224 ：ｵﾜﾘ：02/04/13 17:01

　　　　　　　　　|　はりきって次逝くぞｺﾞﾙｧ！
　　　　　　　　　|　も一度、アレ作ってくれ
　　　　　　　　　￣￣)ﾉ￣￣￣￣￣￣￣￣￣
　　　　 ∧∧　　　　　　　　　　　　　　　　　　　　　　　　　　 .::;;|　ﾌﾞﾂﾌﾞﾂ…
　　　　 (；ﾟД)　　　…ｯﾃｷｲﾃﾙｶ?　　　　　　　　　　　　　　　::;;|　　∧＿∧　ｶﾞﾝﾊﾞｯﾃ
　　,＿（_う　つ＜i　　　　　　　　　　　　　　　　　　　　　　　　　::;;|＿（三三　）　　ﾂｸｯﾀﾉﾆ…
　　ﾄ-人　,　〉　　　　　　　　　　　　　　　　　　　　　　　　　　　::;;;／　（三０三）
　　ヽ＿(/　J　　　　　　　　　　　　　　　　　　　　　　　　　 :::;;;／　　　ゞ三(__ｿ　　ﾌﾞﾂﾌﾞﾂ…

225 ：デフォルトの名無しさん：02/04/13 18:40

>>224
結城さんですか（藁

226 ：デフォルトの名無しさん：02/04/14 09:07

ﾜﾗﾀ

227 ：デフォルトの名無しさん：02/04/14 11:24

Visitorパターンの質問です。
ElementとVisitorがこんな感じでたくさんあるとき、
　　　　＿＿＿＿　　　　　　　　　　　　＿＿＿＿__
　　　　| AbElem |　　　　　　　　　　　　| AbVisitor |　　　　　　　　
　　 . 　~∧￣ .iヽ~　　　　　　　　　　 . 　~∧￣ .iヽ~　　　　　　　　
　　＿＿|＿___　＼＿＿＿　　　　＿＿_/＿＿　＼＿＿＿__
　　 |CnElem1.|　|CnElem2| …　　|CnVisitor1|　|CnVisitor2| …
　　￣￣￣￣　￣￣￣￣　　　　￣￣￣￣ ~　￣￣￣￣~
AbVisitorに全Elementの受け皿を大量に書かなくてすむ方法はないでしょうか？

class AbstructVisitor　{
　　　virtual void Visit(ConcreteElement1* e){ };
　　　virtual void Visit(ConcreteElement2* e){ };
　　　virtual　　　　　　　　　　.　　　　　3
　　　　　　　　　　　　　　　　　　　　　　　：
};

ConcreteVisitorの方は、CnElemの一部しか使わないので。。。

class ConcreteVisitor1{
　　　virtual void Visit(CncreteElement1* e){　e->Hoge();　};
　　　virtual void Visit(CncreteElement2* e){　e->Hoge();　};
};
class ConcreteVisitor2{
　　　virtual void Visit(CncreteElement2* e){　e->Hoge();　};
　　　virtual void Visit(CncreteElement3* e){　e->Hoge();　};
};

228 ：|Dﾟ)：02/04/15 01:09

　　　　　　　　　　　ｳﾌﾌ、わたしは遂にやったわ …

　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣＼
　　　　　 |　モナ影さま：：いんすた～んす！　|
　　　　　　＼＿＿　＿＿＿＿＿＿＿＿＿＿／
　　　　∧＿∧ 　 |／
　　　Ｘノﾊﾍ X
　　　 |ﾟﾉ*^∀^）　　　　　　　　　　　　　　　　　　　　　ｼｭｯ
　　　§、]つとﾉ　　　　　　　　　　　　　　　　　.|
.　　!!｜｜｜　　　　　　　　　　　　　　　　 .|　|
　　　（＿_）＿）　　　　　　　　　　　　　　　　　||　|l

229 ：|Dﾟ)：02/04/15 01:09

　　　　　　　　　　　　　　　　|　あれ、ここは…？　　 |
　　　　　　　　　　　　　　　　＼＿＿　＿＿＿＿＿／
　　　　∧＿∧　　　　　　　　　　　　＼(
　　　Ｘノﾊﾍ X　　　　　　　　　　　　　　 ∧＿∧＿∧
　　　 |ﾟﾉ　 ∀ ）　　　　　　　　　　　　Σ （´Д｀三´∀｀）
　　　§、]つとﾉ　ｳﾌﾌ　　　　　　　　　　　と[　 y　 ]つ
.　　!!｜｜｜　　　　　　　　　　　　　　　 /　,〈　〈
　　　（＿_）＿）　　　　　　　　　　　　　　　（＿_）､＿）
　　　　　　　　　　　　　　　／(
　　　　　　　　　／￣￣￣　　￣￣￣＼
　　　　　　　　　|　ってレモ菜！！！ .|
　　　　　　　　　＼＿＿＿＿＿＿＿_／

230 ：|Dﾟ)：02/04/15 01:09

　　　　　　　　　そう … モナ影さまをしんぐるとんにしてやったの …
　　　　　　　　　これでいつでも …

　　　　∧＿∧　　　　　　　　
　　　Ｘノﾊﾍ X　　　　　　　　　　　　　　　　　　ｱﾜﾜﾜ　∧＿∧
　　　 |ﾟﾉ　 ∀ ）　　　　　　　　　　　　　　　　　　　　　　（；(´∀｀）
　　　§、]つとﾉ　　　　　　　　　　　　　　　　　三　　　/　]つy]つ
.　　!!｜｜｜　　　　　　　　　　　　　　　　三　　　ﾉ　ヽ〈
　　　（＿_）＿）　　 .|＼　　　　　　　　　　　　　　　（＿_）､＿）
　　　　　　／￣￣￣　￣￣￣￣￣￣￣￣￣＼
　　　　　 |　モナ影さま：：いんすた～んす！　|
　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿／

　　　　　　　　唯一の実体を呼べるわ …

231 ：ｵﾜﾘ：02/04/15 01:10

　　　　　　　　もう分身の術でわたしをごまかすことはできないわよ … ｳﾌﾌ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ｳﾌﾌ
　　　　　
　　　　　　　;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;|　 … よっぽど楽しい夢見てるんだろうな …
　　　　　　　;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::::＼　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　;;;;;;;;;;;;::::::::::::::::::::::....|/:::....
　　　　　　　＿__∧＿∧＿＿＿＿＿＿＿＿＿＿＿
　　　　　　＿＿（；(´Д｀）＿＿＿＿＿＿＿＿＿＿
　　　　　＿＿（　」つ',」つ /＿ｳﾌﾌ＿＿＿＿＿＿
　　　　＿＿__と＿）＿ｿi /＿＿＿＿＿＿＿＿＿　[天井裏]
　　＿＿＿＿＿＿＿＿＿＿＿＿ｳﾌﾌﾌ＿＿__
　　￣￣｜｜￣￣￣￣￣￣￣￣￣￣｜｜￣￣￣
　　　　｜｜
　　　　｜　　　　　　　　　　ｳﾌﾌﾌ
　
　　　　　　　　　　　　＼　　ｼﾝｸﾞﾙﾄ～ﾝ　　　/　／

232 ：デフォルトの名無しさん：02/04/15 02:04

ｳｻﾞｯ

233 ：デフォルトの名無しさん：02/04/15 02:08

面白いので期待age

234 ：デフォルトの名無しさん：02/04/15 02:29

はぁ？

class AbVisitor{
　　　virtual void Visit(AbElem* e)=0;
};
class AbElem{
　　　virtual void Hoge()=0;
}

これでええやん。
ポリモルフィズム分かってる？

235 ：デフォルトの名無しさん：02/04/15 03:35

おおもりよしはる＝ロリペドオタ、アニオタ、モツオタ、ベトオタ、ブルオタ、セガ信者
ひまわりと幼女のすじまんこに異様な執着心を燃やしているﾛﾘﾍﾟﾄﾞ絵描き
２浪して九州大学歯学科に進むがプロのイラストレーターになるために大学を中退、
同人活動とＵＯに専念する日々を送るが、その生活は苦しいらしい（藁
自らを画家と呼び、ともすれば不真面目なものと見られかねないアニメ絵を「芸術」
の域にまで高めようとしている（らしい）。　もう、死ねよ…と。
UOではKanaeというテイマーと、SASAWOという斧戦士（赤キャラ）を持っている。＠Izumo
【すじ】　おおもりよしはる
http://yasai.2ch.net/test/read.cgi/doujin/1016348976/
オリジナルキャラ七瀬香奈恵抱き枕（すじ丸出し抱き枕）
http://www.p80.co.jp/p/k_sinki/yoshiharu/kanae2002.html
http://mentai.2ch.net/test/read.cgi/otaku/1016198191/

どっかのスレに上がってた写真（藁
tp://blake.prohosting.com/ccsakura/img-box/ccsakura20020405055756.jpg
tp://blake.prohosting.com/ccsakura/img-box/ccsakura20020405055901.jpg

236 ：デフォルトの名無しさん：02/04/15 11:37

>234
ｽﾏｿ、Visitor側ではCnElement個別のメソッドを呼び出すことがあるので
わざわざ分けてるのでした。書き忘れw
呼び出すのがHoge()共通ならそれで良いね。
とりあえず力技で解決しときます。ありがとう。

237 ：デフォルトの名無しさん：02/04/18 00:17

>>236
そこを共通化してしまうと、あとで困るような・・・。
たとえ面倒でも、いまのままでいいと思うよ。

238 ：デフォルトの名無しさん：02/04/21 13:36

デザインパターンってGOFとやらの２３個を覚えればとりあえずは良いわけ？

239 ：デフォルトの名無しさん：02/04/21 13:44

他にもいろいろあるけど、通じない可能性大。
ヘタに使わない方がいいかも。

240 ：デフォルトの名無しさん：02/04/21 13:44

>>238
実践を伴わないアンキは、うざい厨房の第一歩。
「俺はできる！オブジェクト指向もわかってるぜ！」という
新入社員は大抵このパターン。氏ねおまえら。

241 ：デフォルトの名無しさん：02/04/21 13:54

この業界って実践よりお勉強の方が高度だよね。

242 ：デフォルトの名無しさん：02/04/21 13:55

>>241
実践との賜っている連中が、体力勝負の非効率な作業に何の疑問も
懐いてない馬鹿ばかりだから。

243 ：242：02/04/21 13:59

ただ、大学講義レベル程度の、「入り口」だけのぞいて理解した
気になっているアホには、偉そうな事をいわれたくない。

244 ：デフォルトの名無しさん：02/04/21 14:18

実践も勉強も、上を見ると果てしなく続いてるよ。
どっちが高度か、なんて（以下略）

245 ：デフォルトの名無しさん：02/04/21 16:36

「ファイナライザガーディアン」パターンよりも
カッコいい名前のデザパタがあったら教えてくだちい。

246 ：デフォルトの名無しさん：02/04/22 02:06

Facadeって何て読むの？

247 ：デフォルトの名無しさん：02/04/22 03:17

ふぁさーど

248 ：デフォルトの名無しさん：02/04/22 05:11

>>246-247
確かフランス語だったっけ

249 ：デフォルトの名無しさん：02/04/22 09:32

ばんぺい君

250 ：デフォルトの名無しさん：02/04/22 15:48

>>238
初期設計よりもリファクタリングで使った方がよいかな。
そんときに Observer や Command、State/Strategy Templete Method はあったりまえのように使う。

251 ：デフォルトの名無しさん：02/04/22 16:28

センチネルっていうとｶｺｲｲ>>249

252 ：デフォルトの名無しさん：02/04/22 18:16

>>251
そういや GOF本に書いてあったが、解説用の言語にC++やSmalTalk使わんかったら
カプセル化や継承・ポリモーフィズムもパターンに入れるつもりだったといってたな。

253 ：デフォルトの名無しさん：02/04/22 18:41

>>251
あさのまさひこ叩きは模型板で。

254 ：デフォルトの名無しさん：02/04/22 19:39

「再帰みたいなことをしたいんですけどどんなデザインパターンを使ったらいいですか？｣
という質問を見たことがある。何ですなおに再帰使わないのかおれにはわからなかったよ。

255 ：デフォルトの名無しさん：02/04/22 22:15

>>254
？？？再帰構造のクラス関連とかの話じゃなくて？？？

256 ：デフォルトの名無しさん：02/04/22 22:19

>>254
もしも適用するとスッキリする形なら、Compositeパターンを適用。
再帰1レベルをツリーノード1個に対応させる。
…単純な再帰なら単なる無駄かも知れんけど。

257 ：デフォルトの名無しさん：02/04/22 23:28

>>251
センチネルもデザインパターン？

258 ：デフォルトの名無しさん：02/04/22 23:29

>>256
単純な再帰ならパターンでなくてアルゴリズムの話になんだろ。
しかし、クイックソート内の比較を様々なデータ・・・
単純型からレコード、さらにはクラスのメンバでできるようにしたいというなら
話は全く変わってくるが。。。

259 ：デフォルトの名無しさん：02/04/22 23:30

>>257
いやデザインのつかないパターンでしょう。
日本語で言うと「定跡」ってか。

260 ：デフォルトの名無しさん：02/04/22 23:42

今まで見てると「パターン」と「アルゴリズム」の問題を混同してるのが多くないか？

261 ：デフォルトの名無しさん：02/04/26 16:49

Java言語で学ぶデザインパターン入門　結城浩著

の次は何を読めばいいのですか？

262 ：デフォルトの名無しさん：02/04/26 18:53

>>261
デザパタの本を読むより普通にプログラミングの経験値を積んだ方がいいと思うよ。
無理矢理にデザパタを使おうとしないほうがいい。気がつかないうちに
いつの間にかデザパタを使っていた、というのが理想的なのかもしれない。
でも本を読みたいならC++プログラマならGoF本が王道。
JavaプログラマならEffective Java(値段の割りに薄いが間違いなく良書)に
デザパタが登場するので選択肢としてはありかもしれない。
この本は初心者向けじゃないけど。

263 ：デフォルトの名無しさん：02/04/26 20:43

デザインパターンってフローチャートが新しい名前になったものなの？

264 ：デフォルトの名無しさん：02/04/26 20:48

>>263
違う。
ソフトウェアの典型的構造に名前を付けたもの。

265 ：デフォルトの名無しさん：02/04/26 22:34

フローチャートって実際使われてたりするんすか？
俺は試験以外見たことないのですが

266 ：デフォルトの名無しさん：02/04/27 16:29

>>261
すでに >>262 でレスついてるが、後は「パターンハッチング」もお勧め。
パターンをどう実際の現場での設計に導入するか？その基本的な考え方(？)というかポイント(？)というかを、
GOFの一人がうまく解説している。薄いし安いがこれも間違いなく良書。

267 ：デフォルトの名無しさん：02/04/27 16:31

>>266
もひとつは「リファクタリング」。これでしょ、やっぱ。。。
「デザインパターンはリファクタリングの目標を提供する」

268 ：デフォルトの名無しさん：02/04/27 16:32

>>265
フローチャートみたいな図は書くけど、
情報処理技術者試験で出るような
プログラムをそのまま引き写すようなのは無駄なので使わない。

269 ：デフォルトの名無しさん：02/04/27 18:14

>>267

はげどう。

「リファクタリング」をよんだとき、
デザインパターン、ユニットテスト(XP)、リファクタリング
がおれのなかで激しく結合して世界が変わる音が聞こえました。

270 ：デフォルトの名無しさん：02/04/27 18:19

言ってることわかんない。

271 ：デフォルトの名無しさん：02/04/27 18:19

ここはパソコン詳しい人多いのか？

272 ：デフォルトの名無しさん：02/04/27 19:11

>271 多くないので質問は他の板でしてください。

273 ：デフォルトの名無しさん：02/04/27 23:06

くぅ、そんなこと言われると読みたくなるなぁヽ(；ﾟ∀ﾟ)ノ=3ﾊｧﾊｧ
明日にも買ってきたいのですが、この本で合ってますか？

パターンハッチング
http://www.pearsoned.co.jp/washo/prog/wa_pro18-j.html
リファクタリング
http://www.ogis-ri.co.jp/otc/hiroba/ogisbooks/Refactoring.html

GW、これ読んで潰れそうな予感…。

274 ：デフォルトの名無しさん：02/04/29 11:14

>>273 桶

275 ：デフォルトの名無しさん：02/04/29 11:24

>>269
でしょうでしょう！！

276 ：デフォルトの名無しさん：02/04/29 12:56

>>269
GOFや結城さんの本だけだとデザパタホントに使いモンになるんかて疑問だらけだったけど
これ読んで漏れも世界が全く変わりました。
いまじゃファウラ-まんせー！！

277 ：デフォルトの名無しさん：02/04/29 13:54

「リファクタリング」はともかく
「パターンハッチング」は買って損した

278 ：デフォルトの名無しさん：02/04/29 14:23

>>277 同意。
「アナリシス・パターン」もつまらんかった。

279 ：デフォルトの名無しさん：02/04/29 15:02

>>278
そうか？？第二章のファイルI/Oクラスの設計における Composite や Proxy、Visitorの効果的な
使用例を通して、デザパタの運用法がより立体的につかめると思うが？

280 ：273：02/04/29 15:05

>>274
thx!!!

これからこっそり抜け出して買ってきまさぁ！！
……とりあえずリファクタリングだけにしようかなぁ(;´Д`)

281 ：デフォルトの名無しさん：02/04/29 15:10

>>280
リファクタリングだけで取り敢えずはいいでしょ。
パターンハッチングの方は、ある程度パターンわかった時点で読んで
初めて「なるほど！」て唸らせられるもんだし。。。

282 ：デフォルトの名無しさん：02/04/29 19:03

>>269
漏れも試しに読んでﾐﾀｰﾖ。
しばらくじーと読んでたら・・・・・・・・・・・・

キタ━(°∀°)━( °∀)━(　　°)━(　　)━(´　　)━(∀´ )━( `.∀´)━!!!!!

これ、ｲｲ!!ｲｲ!! 頭の中でﾓﾘﾓﾘとｱｲﾃﾞｨｱが回り始めてｷﾀｰﾖ!!

283 ：デフォルトの名無しさん：02/04/29 19:08

漏れも読んでみようかな・・・

284 ：デフォルトの名無しさん：02/04/29 23:21

質問です。
ファイルを読み込んで、その情報にあったインスタンスを作成したいと思っています。
ファイル名を指定して、ファイルのヘッダ部分を読み、
ヘッダ情報から生成すべきインスタンスを判別し、
具象インスタンスを作成し返す。という一連の操作をきれいにまとめたいのです。

Factory Method が良いのではないかなと思い GoF本を見たところ、
実装の２の所で「Unidrawの図形編集フレームワークでは…」という部分で
どうやら私の考えている事にぴったりの事が書かれていました。

しかし、よく読んだつもりなのですが、イマイチ理解できない部分があります。
「フレームワークはその識別子をパラメータとして Create オペレーションを呼び出す。」
という部分なのですが、
Create オペレーションは Creator::Create() でしょうか？
それとも (Some)ConcreteCreator::Create() でしょうか？

Creator の Create() だとした場合、Creator が識別子について
一元管理していないといけないので Creator を
具象クラスとして作成(Creator を一切継承しない)した方がいいのでしょうか？

それとも ConcreteCreator の Create() なのでしょうか？
だとすると識別子から具体的な Creator を探すのはこのパターンと
関係ない所で行うのでしょうか？

(だとするとGoF本の
「Create オペレーションはその識別子に対応するクラスのコンストラクタを探して…」
という部分の説明がおかしいですよね…？）

私の勘違いしている部分に対するご指摘、そうでなくても
よくありがちなコードだと思うので、皆様の
「私の場合はこうしているよ」的なものでもよいので
教えていただけないでしょうか？
(どういう実装がいいのか↑の説明では不足 or 「お前の文章は理解不能じゃ」という場合はご指摘願えればもっと詳しく書きます)

どなたかよろしくお願いいたします。

285 ：デフォルトの名無しさん：02/04/30 02:01

できるインスタンスは、全部（例えば）Productのサブクラスで良いんだな？
だったらたぶんFactoryMethodの節にあるParameterized Factory Methodがぴっ
たりだろう。

フレームワークが呼び出すのは
Creator::Create(ProductID id)
だろう。

実装は言語によっていろいろ。
C++やJavaなら、識別子からFactoryオブジェクトへの表を引くとか。

286 ：デフォルトの名無しさん：02/04/30 03:40

>>284
＞「フレームワークはその識別子をパラメータとして Create オペレーションを呼び出す。」
は、まんまParameterized Factory Methodのところの文だね。
ちゅーことは、>>285の言うとおり、つか、そこのサンプルコードの通り、
Product* Creator::Create (ProductId id);
つーことだろう。

＞Creator の Create() だとした場合、Creator が識別子について
＞一元管理していないといけないので Creator を
＞具象クラスとして作成(Creator を一切継承しない)した方がいいのでしょうか？
ＧｏＦ本では、一元管理できるのがメリットだって説明されてると思う。
それから、Creatorは識別子とConcreteProductクラスの対応は、Creator クラス
にデフォルトの実装を与えて、必要ならオーバーライドしれ、って書いてあるようだ。
だから、具象クラスはフレームワークとして用意して、具体的なアプリケーションの
実装時にはCreate()をオーバーライドする（ってことは当然サブクラスを派生する）
っていうのがＧｏＦ本に書いてあることだと思う。
（ここでいうフレームワークは、ＧｏＦ本で図形編集のフレームワークって書いてあるそれね）

Parameterized Factory Methodは、あくまで、*Factory Methodの変形*として
解説されているので、違いに注意して読んだほうがいいかも。
とくに、Factory Methodが実装時のフレームワークなのに対して、
Parameterized Factory Methodは、実行時に複数のConcreteProductオブジェクトを
生成する拡張が入ってるところとか。

どでしょ？

287 ：Delphi使い：02/04/30 03:49

Factory の場合、GOFとか見てると　CreateメソッドがどうしてもDelphiのコンストラクタメソッド名と
かぶさって少々混乱気味（爆

288 ：Delphi使い：02/04/30 03:51

>>283
烈しくお勧め！！
「実装しながら設計する」という概念が、ある意味革新的。

289 ：デフォルトの名無しさん：02/04/30 03:53

>>286
「フレームワーク」という言葉の使い方がカナーリ混乱してるみたいだが
どうよ？

フレームワークって実装するときにオーバーライドしたりいじったりは
しないもんだと思うが。（実装に依存しないところだけくくり出したもので
あるはず。）

290 ：284：02/04/30 05:10

ね、眠れなかったよぉ…(昨日昼まで寝てて、夕方にまた昼寝？したからな…)

>>485-486
ありがとうございます。
おかげでやっと GoF本に書いてある事の意味が理解できました!!
↓のような形(まぁほとんど GoF 本のサンプルそのままみたいなものですが)
にしようと思います。
ありがとうございました。

// FactoryMethod::Product
class Polygon{...};

// FactoryMethod::ConcreteProduct
class Triangle : public Polygon {...};
class Rectangle : public Polygon {...};

// FactoryMethod::Creator
class StandardObjectLoader
{
　public:
　　virtual Polygon* LoadFromFile(const char* fileName)
　　{
　　　FILE* pFileI = fopen(fileName, "rb");
　　　fseek(pFileI, 0, SEEK_SET);
　　　HEADER header;
　　　fread(&header, sizeof(header), 1, pFileI);
　　　Polygon* pResult;
　　　switch(header.ID){
　　　　case POLYID_TRIANGLE:
　　　　　pResult = new Triangle(pFileI); break;
　　　　case POLYID_RECTANGLE:
　　　　　pResult = new Rectangle(pFileI); break;
　　　}
　　　fclose(pFileI);
　　　return pResult;
　　}
};

291 ：286：02/04/30 06:15

てにをはがヘンだけど、通じたみたいだから、いいや。

292 ：デフォルトの名無しさん：02/04/30 11:07

パターンハッチングは訳が一部変なので注意が必要。

293 ：デフォルトの名無しさん：02/04/30 11:48

>>292
逆に「リファクタリング」の日本語訳はこなれてるから読みやすいよね。

#最近リファクタリング厨になりつつある（ｗ

294 ：デフォルトの名無しさん：02/05/01 17:51

Singletonの様に生成するインスタンスが一つだけではなく、
有限個のインスタンスを生成する場合に適用するパターンってありますか？

たとえば、コマンドキューにコマンドを流し込んで、
それを受理する実体が複数個（可変）ある場合など。

295 ：デフォルトの名無しさん：02/05/01 20:08

>>294
それも Singleton だと思うが。。。
記憶違いかも試練が単数もしくは有限個にインスタンスの生成を限定するパターンが Singleton だと。

296 ：デフォルトの名無しさん：02/05/01 22:56

>>294はｎ個以上インスタンスを作らない、っていう制限がありそうに見えないんだが…

297 ：デフォルトの名無しさん：02/05/01 23:40

>>296
時間のかかる処理をスレッドで走らせて、
ユーザーが設定により走らせるスレッド数を決定できるんだけど、
現実的に２，３個同時に走らせる位が限界なので、
限界といえば一応あります。

298 ：デフォルトの名無しさん：02/05/02 00:12

蝿の重さ。。。

299 ：デフォルトの名無しさん：02/05/02 01:58

>>294
そのものずばり、というパターンはないけどMediatorパターンでコマンドと
スレッドの仲介をやってやるのがいいかな、とは思う。

並行動作するオブジェクトの協調パターンは「プログラムデザインのための
パターン言語」にいくつか載ってるので参考になるかも。

300 ：デフォルトの名無しさん：02/05/05 20:36

age

301 ：デフォルトの名無しさん：02/05/06 07:11

>>277
激しく同意。
漏れの精進が足りないだけかもしれん、
日を改めてもう一度読んでみよう。

302 ：デフォルトの名無しさん：02/05/08 08:44

リファクタリング
目からうろこが落ちたーよ。
リファクタリングしている間は一切機能の追加はしてはいけないって言うの。
言われてみればそのせいで収拾がつかなくなったプロジェクトがｲﾊﾟｰｲ。

303 ：デフォルトの名無しさん：02/05/08 09:50

いてれたパターンの存在意義おせーて。
yuki本読んだけど意味わからず。

304 ：デフォルトの名無しさん：02/05/08 10:00

>>277
ハッチングは，訳が下手なので×．原書をあたったほうが良い．
この本の監訳者の本は訳の具合を品定めして原書を買うかどうか
を判断した方が吉．

305 ：デフォルトの名無しさん：02/05/08 14:16

>> 303
同じところで悩んだよ。サンプル見ても単一の走査パターンなので、
まったく存在意義が感じられなかったよ。走査パターンを増やしてみて
はじめて存在意義が感じられたよ。

306 ：デフォルトの名無しさん：02/05/08 14:37

>>303
C++のSTLのコンテナクラスなんかだと、データ構造が違っても
同じ方法でアクセスできるね。

307 ：デフォルトの名無しさん：02/05/08 20:35

>>303
一つの集約オブジェクトに対していっぱい走査位置を持てる

308 ：デフォルトの名無しさん：02/05/08 20:36

>>303
実装がツリーだろうがハッシュ表だろうが
線形リストだろうが配列だろうが
同じ方法でスキャンできる。

309 ：デフォルトの名無しさん：02/05/20 08:26

質問です。
現在3Dのラッパークラス(D3D/OpenGL)を作ってるのですが、
下のような感じになりますよね、これだけ見るとAbstractFactoryっぽいのですが、

class Driver {
public:
　Texture* createTexture();
　Mesh* createMesh();
　...
};

当然レンダリングはドライバの機能なので、Render()というメソッドも用意することになります。
そうすると、AbstractFactoryとしては微妙なクラスになっちゃいますよね。
で、次に考えたのが、

class Factory {
public:
　Driver* createDriver();
　Texture* createTexture();
};

こうなるのですが、テクスチャはドライバに依存するので、
Texture* createTexture(Driver*);
このようにせざるを得なくなります。
どっちの方がスマートな設計と言えるのでしょうか？
個人的には前者かな、と思っているのですが。

310 ：309：02/05/20 08:30

どこのAbstractFactory/FactoryMethodの解説を読んでも、
ツールキットや部品を提供するフレームワークは決定されている前提で、
その状態からのConcreteProductを生成する解説しかなく、
フレームワークから選択自由な状態での解決手法がよく分からないんです。

311 ：デフォルトの名無しさん：02/05/20 08:37

class DriverFactory
{
public: static Driver* create();
};

class ObjectFactory
{
public:
Texture* createTexture();
Mesh* createMesh();
}

class Driver
{
public: ObjectFactory* createObjectFactory();
};

こう。

312 ：81：02/05/24 01:52

デザインパターンってノストラダムスの大予言みたい。
あいまいでなんとでも解釈できる。
そして事件が起こった後で「これは予言されていた」とか言うの。

313 ：デフォルトの名無しさん：02/05/24 06:49

>>81
がんがれよ、応援してるよ。

314 ：デフォルトの名無しさん：02/05/25 12:02

http://www-6.ibm.com/jp/developerworks/java/020524/j_j-bitterjava.html
「Bitter Java」の味
アンチパターンによってプログラミングはどのように改善されるか
面白かったのでage

315 ：デフォルトの名無しさん：02/05/25 12:11

今更だけど、やっぱりIBMはすごいな。
いい人を抱えてるよ。MSDNの記事より資料価値も高い

316 ：デフォルトの名無しさん：02/05/25 13:10

IBMの人じゃなくて独立コンサルタントと書いてあるけど。

あと、アンチパターンはデザインパターンほど役に立つとはどうしても思えない。

デザインパターンはコードの形で明確に定義されて、誰でも学ぶことのできる技
術だけど、開発プロセスにおけるアンチパターンはなんだか曖昧で、単に「あり
そうな話」を羅列しただけの気がする。たしかにもっともらしいけど、具体的に
は役に立たない精神論というか。

「人に迷惑をかけないように気をつけましょう」「常に積極的に学ぶ姿勢を大切
にしましょう」とかの標語と同レベルに思える。

記事にあったバグパターンまで細分化すると、これはずいぶん明確ではあるけれ
ど、「パターン」と名をつけるまでもなくありがちなバグ類型の収集はそれこそ
何十年も前から行われていたわけで、パターン化したこと自体に価値があるデザ
インパターンとは大きく異なる。

だいいち、こういうバグパターンを挙げていったらそれこそ何千にもなるに違い
ないが、それを暗記して避ける努力をすることに価値があるかというと甚だ疑問
だ。

317 ：デフォルトの名無しさん：02/05/25 18:12

>>316
あんたみたいな人がありがちな罠に陥らないようにするためのアンチパターンだろ。

318 ：316：02/05/25 19:42

>>317
意味わからん。デザインパターンみたいにカタログに整理したら
全２００巻くらいになるんじゃないか、といってるんだが。

319 ：デフォルトの名無しさん：02/05/25 19:51

縦読みなんで間違ってるかも知らんが、
成功例をパターン化したものがデザインパターンで、
失敗例をパターン化したものがアンチパターン？

320 ：デフォルトの名無しさん：02/05/26 00:36

>>318
あなたのケースを「「「アンチパターンは具体例として有効である」症候群」アンチパターン」として、私のアンチパターンに登録しますた。

321 ：デフォルトの名無しさん：02/05/26 01:28

抽象的なお話なら当然役にたたんし、具体例も役に立たないのか。
アンチパターンは役に立たないというアンチパターンか。
パラドックスだね。

322 ：320：02/05/26 05:38

ま、印象だけで語ってないで、「アンチパターン　-ソフトウエア危篤患者の救出-」の
第四章「アンチパターン使用上の注意」だけでも、読んでみれ。
８ページしかないから、立ち読みでも頭に入るよ。
したら、アンチパターンっていうのは、役に立つ、しかも抽象的な事だってわかるよ。
それから、アンチパターン本は網羅するのが目的じゃない、ってことも。

それから、プログラミングで「抽象」といったら、abstractで、
「事物や表象を、ある性質・共通性・本質に着目し、それを抽（ひ）き出して把握すること。」
の意味で使うこと、わかっといてね。

323 ：322：02/05/26 05:47

「abstractの意味の中でも」だ、

324 ：デフォルトの名無しさん：02/05/26 23:39

結城さんの本読んでるけど
Factory Method パターンの Factory class の
create メソッドがどうして (String owner)
なんていう argument を取るか小一時間考えても
わからない漏れはダメかもわからんね(;´Д`)

325 ：デフォルトの名無しさん：02/05/27 11:05

>>322
『全社的おんぼろ煙突システム』パターンなら結構みかけるぞ。
某社では、部署ごとに使ってるシステムやソフトが全く違うので、部署間のデータのやり取りは殆どアナログ。
デジタルデータもネットワーク組んでるにも関わらず、フロッピーでやり取りしてる！（大藁）

326 ：デフォルトの名無しさん：02/05/27 11:45

>>324
カードの持ち主（＝owner）でしょ。
なにが引っかかるの？

327 ：デフォルトの名無しさん：02/05/27 12:12

>>326
もしかして実装ベースで考えすぎて、抽象的に考えられないのかも知れんね。

328 ：デフォルトの名無しさん：02/05/29 15:05

保守age

329 ：デフォルトの名無しさん：02/06/02 18:56

http://www.hyuki.com/dp/dpfaq.html
「デザインパターンFAQ」有名だとは思うけど念のため
一番面白いと思ったのはこれ↓

>結局のところ、うちのおばあちゃんに聞けば教えてくれるような
>アドバイスになるだけなのに、手間ひまかけてパターンを書くのは
>どうしてですか？
>
>パターンの中には、あなたのおばあちゃんですら知っているくらい
>とても良くて役に立つものがあるからです。
>パターンを書くことによって、そのアドバイスのコンテキスト、
>価値(value)、そしてその意味(implications)が
>おばあちゃんのアドバイスよりも明確になるのです。

330 ：デフォルトの名無しさん：02/06/07 16:27

Builderパターンで、Directorの存在意義が分からないのですが、教えてもらえませんか？
Builderパターンはそれ自身でProductの生成をラップしているので、
Clientが直接Builderをいじればいいと思うのですが。

たとえば、以下のページで解説されている様な例の場合、
ttp://www.seto.nanzan-u.ac.jp/~amikio/NISE/member/yamada/Builderhtml/Builder.html
DirectorもほぼBuilderと同一のメソッドを持つので、
Directorの定義の分だけ余分な手間がかかるだけで、メリットは皆無な気がします。

複雑な生成を一つのメソッドで行える以下の様な形式なら、
ttp:/\www.dmz.hitachi-sk.co.jp\Java\Tech\pattern\gof\builder.html
Directorの存在意義もあると思うのですが、
これだとコードに記述したとおりのみの静的な解決になってしまうと思います。

勿論、Directorがそれ自身パラメータを見ながら生成手順を変える事も出来るだろうけど、
それならやっぱりClientがBuilderを直接操作しても良いじゃないかという気になってしまいます。

・ClientがBuilderを直接操作する（ClientがDirectorを兼ねる）のはよくないやり方ですか？
・Directorクラスに、生成に関するメソッドを持たせるというのは、よくないやり方ですか？

331 ：デフォルトの名無しさん：02/06/07 16:28

２番目のURLは
ttp://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/gof/builder.html
です。

ローカルに保存したままの形式だった物で。

332 ：デフォルトの名無しさん：02/06/07 17:54

Builder = 単体でオブジェクトを生成する者
Director = Builderを使用して一つのオブジェクトを作り上げる者

それぞれ分けて抽象化することで再利用性を高めてるんだと思われる。
ただ、Builderに限った話じゃないがデザパタはかなり丁寧に
汎用化されているので状況に応じてステップを省略したり
融合したりするのはよくある事だと感じてる。
というか完全に当てはまるパターンはそんなには出てこない。
が、変形してでも役に立つならそれでいいと思ってる。

333 ：デフォルトの名無しさん：02/06/08 15:39

『Java言語で学ぶデザインパターン入門』マルチスレッド編
(結城浩著)が6/26に発売されるとのこと。
目次がウェブに公開されてるので買うかどうかの判断材料になるだろな。
http://www.hyuki.com/dp/dp2.html

334 ：逝って良しの１：02/06/08 16:06

>>324
多分動的に呼び出したいんじゃない？
メソッドで分けると静的なのしか書けないし、数値ーラベルは割り当てやら
名前やらで２段階必要になるので面倒。

335 ：デフォルトの名無しさん：02/06/11 21:23

protoype ベースの OOP では、
Singleton パターンも Prototype パターンも
意味が無いと言うかパターンとして成り立たないのだが、
GoFの再利用のためのデザパタはクラスベースが前提なのだろうか？

336 ：デフォルトの名無しさん：02/06/12 18:03

デザインパターンって何よ？

337 ：デフォルトの名無しさん：02/06/12 18:12

>>336
google 逝け

338 ：デフォルトの名無しさん：02/06/12 18:21

>>336
とりあえず>>329のリンク先のデザパタFAQを嫁

339 ：デフォルトの名無しさん：02/06/13 00:01

>>335
それはGoFも触れてたと思ったけど。
言語によっては特定のパターンはそもそも不要な場合もある、みたいな感じで。

340 ：デフォルトの名無しさん：02/06/17 12:18

ほらほら！読んで見れ！
http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1490-1

341 ：デフォルトの名無しさん：02/06/17 13:15

>>340(←ちなみにコイツはマルチ野郎)のリンク先の
「Java開発者のためのアンチデザインパターン～失敗を回避する秘訣」
(安藤利和著)は本屋で読んだがはっきりいってクソ。
デザパタの悪い面として、
・デザパタを知らない人にデザパタの言葉でしゃべっても通じない云々
などと書いてある。わざわざイラスト入りでだ。そりゃあ通じないだろう。
でもな、そんなのデザパタに限った話じゃないだろ。もうアフォかと(略
あと、何ページも渡って
・コーディングをする時にコピペを使うと良くない云々
とも書いてある。そりゃその通りだけどさ、だからなんだってんだ？
今さら金払って読みたいようなことではない。
普通にGoF本か、Java使いのデザパタ初心者なら結城本あたりを
買うべきだろう。頭を悪くしたい人にはこの本をお勧めするが。

342 ：デフォルトの名無しさん：02/06/17 13:18

>>341
当たり前のことが書いてある本って入門者にはとても良いと思われ。
その狭い視野もデザインパターンのおかげかい？

343 ：デフォルトの名無しさん：02/06/17 15:40

>>342

> その狭い視野もデザインパターンのおかげかい？

実は結城タンのレスだったりしてね（藁

344 ：デフォルトの名無しさん：02/06/17 16:23

デザインパターンはかなり有用。
age

345 ：デフォルトの名無しさん：02/06/17 17:06

>>344
結城タンの本も、確かに判りやすい事は判りやすいのだが、イマイチ実戦でどう使いこなすのかが
見えてこないのよね。『デザインパターン』を勉強するための本であって、実戦向きではないと思我。
その点 http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1490-1 はじっくり読んでくと
「おいお前ら！この手は使えるじゃねーか！ｺﾞﾙｧ！！」てのが学べて結構（・∀・）ｲｲ！

346 ：デフォルトの名無しさん：02/06/17 17:11

>>345
それならいいんだ。ただデザインパターンがすべてで工夫しないアフォに困ってるんだ。

347 ：デフォルトの名無しさん：02/06/17 17:13

本を読まねばならない。
お金が無い。

↓くれ

348 ：デフォルトの名無しさん：02/06/17 17:20

AIをあげます。

349 ：デフォルトの名無しさん：02/06/17 17:31

>>346
「アンチデザ・・」にも書いてあったね。確か「デザパタ症候群」って。（・∀・）

350 ：347：02/06/17 17:40

病気になるほど使えるものなのか？
かーやってみてぇなぁ

351 ：デフォルトの名無しさん：02/06/17 17:46

>>349
アンチデザって何？アンチパターンのこと？

352 ：デフォルトの名無しさん：02/06/17 17:50

>>350
って言うか死ぬほど考えてクラス設計してたらデザインパターンの一つに行き着くみたいな。
じゃあ、初めから知ってた方が速いと。

353 ：デフォルトの名無しさん：02/06/17 17:52

>>351
>>340

354 ：デフォルトの名無しさん：02/06/17 17:58

>>353
サンクス
面白そうな本だね。
買ってくるよ

355 ：デフォルトの名無しさん：02/06/17 18:01

>>352
その過程を大事にしなよ。。

356 ：デフォルトの名無しさん：02/06/17 18:10

>>355
いや、わかってる。

その課程でデザパタを知ってた方が良いなと思った。

自分が思いつきもしない問題点があるかも知れないし。
それに固執する気はさらさら無いけどね。

357 ：デフォルトの名無しさん：02/06/17 18:11

C++のキチンとオブジェクト指向で書かれた大規模なソースみたいんだけど
いいのない？

358 ：デフォルトの名無しさん：02/06/17 18:17

デザパタは飲んでも飲まれるな。

359 ：デフォルトの名無しさん：02/06/17 18:32

>>358
デザパタを有効に使う場面は、リファクタリングしてる時が一番いいね。(･∀･)

360 ：デフォルトの名無しさん：02/06/17 18:36

>>358
なんつうか当たり前
そんな議論しても無駄

361 ：デフォルトの名無しさん：02/07/07 09:35

http://hccweb1.bai.ne.jp/tsune-1/
VB.NETでデザパタ

362 ：デフォルトの名無しさん：02/07/07 09:52

デザパタママ～♪デザパタママ～♪デザパタ～♪

七時～朝もデザパタイテレェタ～♪
八時～みんなお出かけ早くもシングルト～ン♪

替え歌しようにも原曲と歌詞が思い出せない…誰か後を頼む……ぐふっ！

363 ：デフォルトの名無しさん：02/07/08 16:32

最後は死ぬんだっけ？

364 ：デフォルトの名無しさん：02/07/09 08:42

８時～今日もかたかたコーディング～♪

365 ：デフォルトの名無しさん：02/07/10 05:20

パタパタママくらい、ぐぐれよ（ｗ

366 ：デフォルトの名無しさん：02/07/25 11:36

●Ｃ＋＋で読むデザインパターン
http://www.tomozo.ne.jp/yamazaki/download/doc_design_pattern.htm
＞パターンの解釈の仕方が間違っているかもしれません

と本人も言っているようなのでここに晒す。
あってる？＞有識者ら

367 ：デフォルトの名無しさん：02/07/25 14:59

囚人のジレンマについてお尋ねしたいがいかがなものか。

368 ：デフォルトの名無しさん：02/07/25 15:00

いかがなものかというのはいかがなものか。

369 ：デフォルトの名無しさん：02/07/25 15:02

スレ違いだ確信犯め（w

370 ：デフォルトの名無しさん：02/07/25 15:07

>>366
本人なら正直にそう名乗れよ
別にﾀﾞﾚも叩きはしないから

371 ：デフォルトの名無しさん：02/07/25 15:12

>>366
とりあえず、1 ページに全部書くのはいかがなものか。

372 ：デフォルトの名無しさん：02/07/29 15:24

すみません、デザパタ初心者なんですが、gofパターン、
一度に全部は無理なので、役に立ちそうなものから順々に
やっていきたいと思ってます。
どこいらへんから手を付ければいいでしょうか？

373 ：デフォルトの名無しさん：02/07/29 15:37

役立たず

374 ：デフォルトの名無しさん：02/07/29 16:22

>>372
プログラム初心者ならプログラムの勉強から手をつける
プログラム初心者でなければ、デザパタにあてはまるコードを
すでに知らないうちに書いている

375 ：デフォルトの名無しさん：02/07/29 16:44

デザインパターンの勉強をして、知らないうちに書いていた記憶のない
俺はまだプログラム初心者ですか？

376 ：372：02/07/29 17:54

>>374
それはなんとなくわかるんですが、一応知識として
整理しておこうと思っていまして。
なんか、重要な４つとかいうのがあるとかという話を
きいたこともあるんですが。

377 ：デフォルトの名無しさん：02/07/29 19:03

結城本の目次を見れ。
多分あの順序が一番わかりやすかろうて。

378 ：デフォルトの名無しさん：02/07/29 20:39

>>372
体系的(というほどのものでもないが)な知識を身に付けるのに
つまみぐいという根性が気に食わん(藁
端からガリガリ読んでけよ。

もし飽きっぽいなら全体を一読して馴染み深い
(=自力で開発済みの)パターンから攻略してけば
気分的には楽かもね。

どうしても有用有名にこだわるんなら
googleのヒット件数の多いものからやっとけ。

379 ：デフォルトの名無しさん：02/07/29 21:14

どうでもいいが、ファサードって読めなかった人何人くらいいますか？
わしだけですか？

380 ：デフォルトの名無しさん：02/07/29 21:17

読めなかたﾖ

381 ：デフォルトの名無しさん：02/07/29 21:34

わしだけじゃなかったか。安心しますた。

382 ：デフォルトの名無しさん：02/07/29 22:52

今の今までファケイドって読んでたよっ！ヽ( `Д´)ﾉ

おや、結城さんとこのギコ、新作がでてるね。禿ガイ？

383 ：逝って良しの１：02/08/02 22:47

あげ

384 ：デフォルトの名無しさん：02/08/02 22:55

オブザーバーって、イベントリスナーと同義だよね？
ちょっと違う？

385 ：デフォルトの名無しさん：02/08/02 23:17

デザパタってあんまり流行らないうちに時代遅れになっちゃったね

386 ：デフォルトの名無しさん：02/08/02 23:35

※デザパタをオブジェクト指向に置き換えて読んでみよう

387 ：デフォルトの名無しさん：02/08/02 23:38

何が流行ってんの？

388 ：逝って良しの１：02/08/03 00:44

夏風邪

389 ：デフォルトの名無しさん：02/08/03 01:12

>>387
「どの言語にしたら」系スレ

390 ：デフォルトの名無しさん：02/08/07 19:19

デザインパターンってよく知られたアルゴリズムとかと同じでしょ？

391 ：デフォルトの名無しさん：02/08/07 19:26

…お父さん、390がかわいそうだよ…。

392 ：デフォルトの名無しさん：02/08/07 20:08

どこが違うんですか？

393 ：デフォルトの名無しさん：02/08/07 20:14

どこが同じなの？

394 ：391：02/08/07 20:24

>>392
デザパダの勉強しなおし。
GoFってデザパタ≠アルゴリズムって書いてなかったっけ？
他の本で見たのかな…失念してしまった。

395 ：デフォルトの名無しさん：02/08/07 20:27

やっぱり2ちゃんて低レベル･･･。

396 ：デフォルトの名無しさん：02/08/07 20:30

これだけ大きな掲示板になると、厨から神まで
いろんな人間が来るから仕方ないだろ。ただ、
厨が目立つだけだよ、恥ずかしげもなく書き込むから。

…まぁ俺も人のこと言えないけど

397 ：390：02/08/07 20:30

すいません先生(´Д ⊂ヽ
でもそういう意味で逝ったんじゃないんです。

398 ：デフォルトの名無しさん：02/08/08 01:48

>>382
同じくヽ( ´Д`)ﾉ
フランス語が語源なのね・・・それなら仕方あるめぇ、てやんでえぇ、ばろめ。

399 ：デフォルトの名無しさん：02/08/08 17:30

　　　　　　 ∫
　　　∧,,∧ ∬　　　　　／￣￣￣￣￣￣￣￣￣
　　ミ,,ﾟДﾟノ,っ━~　　＜　フサーど。
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣　 .┻

400 ：デフォルトの名無しさん：02/08/08 19:53

ふぇけいど

401 ：デフォルトの名無しさん：02/08/10 11:58

おい、おまいら
　　　　　　　　　　　＿＿＿　００　　　　　　　　／
｜＿＿　＿＿　　＿＿＿＿　　　　　　　　　／
｜　　　＿_｜　　　｜　　　＿＿＿＿　　／｜
｜＿＿　＿_｜　／　　　　　　　　　　　　｜　

を流行らすのじゃ！

参考スレッド森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
http://comic.2ch.net/test/read.cgi/comic/1025843878/551-591

402 ：デフォルトの名無しさん：02/08/11 11:34

>>681
hyoderi pattern ですか？

403 ：デフォルトの名無しさん：02/08/11 13:44

デザインパターンを駆使したオープンソースのプロジェクトってありますか?
ある程度大きいソースを見たいのですが。

404 ：682：02/08/11 13:44

>>402
違うよ。

405 ：デフォルトの名無しさん：02/08/14 05:47

>>403
Java 製なら大体はデザインパターン使ってる。
適当に探してみ。

406 ：デフォルトの名無しさん：02/08/14 22:42

|-`).。oO(>>403 xUnitなんてどうかな・・・)

407 ：デフォルトの名無しさん：02/09/02 05:21

State パターンって、それぞれの状態ごとに固有のデータとか持たないもんなんですか？
↓のソース(C++)の State_1::counter みたいなやつのことです。

class State {
public:
　　virtual ~State(){}
　　virtual State* Update( Context& c ) = 0;
};
class State_1 : public State {
private:
　　int counter;
public:
　　State_1( int a ) : counter( a ) {}
　　State* Update( Context& c ){
　　　　if( counter > 0 ){
　　　　　　--counter;
　　　　　　return 0;　　// 状態を維持
　　　　}
　　　　else
　　　　　　return new State_2;　　// State_2 へ移行
　　}
};
struct State_2 : public State {
　　State* Update( Context& c ) { return new State_1( 10 ); }　　// State_1 へ、初期値 10 で移行
};

408 ：403：02/09/02 16:05

>405 >406
ｳｵｰｻﾝｸｽｺ
さがしてみます

409 ：デフォルトの名無しさん：02/09/06 23:31

まことに勝手ながら、ただいまからこのスレは

「デザインパターンは戦場では必要なし」

となりました。よろしこ。

410 ：デフォルトの名無しさん：02/09/07 00:02

本当に勝手だな

411 ：デフォルトの名無しさん：02/09/21 19:04

デザインパターンをマスターするとどうなるの？

412 ：デフォルトの名無しさん：02/09/21 19:08

パターンに合ったコードをすんなり読めるようになるだろ

413 ：デフォルトの名無しさん：02/09/21 19:08

Producer-Consumerパターンというのを聞いたことがあるんだけど
これはObserverパターンの別名って事でいいのかな。

414 ：デフォルトの名無しさん：02/09/21 19:33

想像だと違う。むしろストリームのパイプとかじゃないかな。
Producerは適当に生産しつづけるんだけど、
在庫がいっぱいなったら倉庫に空きができるまで待つ。
Consumerも気まぐれに消費するんだけど、
在庫がなくなったら、入荷するまで待つ。
そんなんじゃない？同期しないのがポイントとか

415 ：デフォルトの名無しさん：02/09/21 19:52

>>413
デザパタより、マルチスレッドプログラムのモデルで使われる単語だと思うが。

416 ：デフォルトの名無しさん：02/09/21 20:01

有限バッファ問題とかいうやつかな

417 ：デフォルトの名無しさん：02/09/22 23:35

http://www.hyuki.com/dp/dp2.html#contents

418 ：413：02/09/23 02:59

解答ありがとう。その後結城浩のデザパタ本のマルチスレッド編も読みました。
ところが、質問を間違えてしまいました。非常に申し訳ない。
Publisher-SubscriberパターンというのはObserverパターンの別名ですか?
ぐぐってみたら
http://www.google.co.jp/search?q=%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3+Publisher+Subscriber+Observer&ie=UTF-8&oe=UTF-8&hl=ja&lr=
このページには別名であるかのように書いてあり
http://objectclub.esm.co.jp/observer-multithread/
このページにはObserverはPublisher-Subscriberの一種のように書かれています。
http://www.freeml.com/ctrl/html/MessageForm/[email protected]/1199/

419 ：デフォルトの名無しさん：02/09/23 06:58

>>418
それを読む限り、後者の「Publisher/Subscriber」は分類名であって、
パターン名ではないよな。なぜ言葉の使い方の違いと気がつかないのか君は

420 ：デフォルトの名無しさん：02/09/25 18:10

簡易HTTPサーバを作るため、
GET DELETE POST PUT 等のリクエストを処理するクラスを書こうと思っています。

そこでお伺いしたいのですが、どのパターンを参考にすれば良いでしょうか。
アドバイスください。

421 ：デフォルトの名無しさん：02/09/25 18:14

コマンドパターン

422 ：デフォルトの名無しさん：02/09/25 18:15

>>420
その

パターンいくつかくっつければプログラムかんせーい！

と言うのが一番怖いと。

その人のデザインによってどのデザインパターン使うかって変わってくる気がした。

423 ：デフォルトの名無しさん：02/09/25 18:26

>>421
的確な回答ありがとうございます。非常に参考になりました。
>>422
勝手にデザパタ房扱いしないでくれ。
それに後半の意見には賛同しかねる。
パターンとは目的に応じた定石なのだから。

…と質問した分際で言い放ってみるテスト。

424 ：デフォルトの名無しさん：02/09/25 18:34

>>423
その目的（簡易HTTPサーバを作りたい♪は大きな目的ではあるがココデハそれを指してはいない）がはっきりしてないのにデザインパターン？笑止千万。
と、火蓋を切ってみる。

425 ：名無しさん＠ＸＥｍａｃｓ：02/09/25 21:46

>>424

> はっきりしてないのにデザインパターン？笑止千万。

もとの質問では「リクエストを処理するクラスを書こうと思っています」
ってあるからある程度ははっきりしてるのでは？
ある程度やることが決まってるんなら、適用できそうなデザインパターンを
列挙して、イメージしてくのが普通では？

426 ：デフォルトの名無しさん：02/09/30 22:26

ＧＯＦ以外で良いのはないすか？

427 ：426：02/09/30 22:27

マルポスになっちまった失礼

428 ：デフォルトの名無しさん：02/10/01 03:11

つうか、デザパタってそんなに使う？
Singleton, Flyweight, Composit, Observerは
考えなくてもやるから置いといて、他に普通使うのあるか？

429 ：デフォルトの名無しさん：02/10/01 03:21

Flyweightなんて使うか？

430 ：デフォルトの名無しさん：02/10/01 05:15

>>428の他に
Adapter,Bridge、Proxy、TemplateMethod、State、
Strategy、Chain of Responsibility、Mediator、Facade
もそいや使ってるよ普通に

431 ：デフォルトの名無しさん：02/10/01 08:09

実際に使われているプロジェクトのソース見てみたいな。
昔のような目から鱗ソースをみる感激がほしい。

432 ：デフォルトの名無しさん：02/10/01 10:34

デザパタのStateパターンって、無理矢理作りましたって感じで
エラく汚い気がするんだがどうよ。

433 ：デフォルトの名無しさん：02/10/01 22:42

＞Chain of Responsibility
使うのか･･･

434 ：名無しさん＠ＸＥｍａｃｓ：02/10/01 23:05

>>433
たまにChain of Responsibilityだ!!と思って設計始めるけど
やっぱやーめたってなる事が多いな。
フィルタとか、リカバリ処理とかに使えると思うのだが。

435 ：デフォルトの名無しさん：02/10/01 23:26

>>433
パケット処理でswitchの分岐が複雑になる場合につかうなぁ。

436 ：デフォルトの名無しさん：02/10/03 12:50

>>432
パターンありきで無理矢理作ると、どんなパターンも汚くなりがち。
そうじゃなくて、既存の汚い（または汚くなりつつある）コードに
ほどほどにパターンを適用すると良い効果がでてくる。

437 ：デフォルトの名無しさん：02/10/04 23:04

「ツリー構造のノードから値を取得する」状況ってよくあるはずだけど、
必ずといっていいほどChain of Responsibility になるだろ

438 ：デフォルトの名無しさん：02/10/05 01:27

>>437
Visitor。

　　　　　　　　　　　　　　　　　　　　　　　　　　　…漏れは使わんが。

439 ：デフォルトの名無しさん：02/10/05 02:15

>>437
ノードへのアクセスって、それ程メッセージのフォワーディングが
発生するかな。

>>438
>>437のいう条件だけだと、マルチディスパッチを要するとは言えない。
この時点でVisitorを持ち出すのは早すぎる。

　　　　　　　　　　　　　　…どっちにしろ漏れは使わんが。

440 ：デフォルトの名無しさん：02/10/05 23:07

いや、ノードへの順次アクセス(=Visitor)じゃなくて、
ノードから値をとる→値が設定されてない→デフォルト値の提供っつー形で

441 ：デフォルトの名無しさん：02/10/22 22:50

背伸びしてAlexanderの原書購入してみたが、
文体も構文も難しくて理解できそうにない。

敗北age。

442 ：デフォルトの名無しさん：02/10/23 00:06

結局デザパタ知っていても使わないねー。

使うのは、イレテータと、プロキシくらいか。ビジターもちょっと使ったけど。
とにかく要らないのが多すぎ。実用度が低い。所詮ブームの１つだったって感じ。

443 ：デフォルトの名無しさん：02/10/23 00:07

>>442
http://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm

444 ：デフォルトの名無しさん：02/10/23 00:13

>>442がVisitorを理解していないに一票。

>>443が今夜金縛りにかかるにもう一票。

445 ：デフォルトの名無しさん：02/10/23 00:15

>>443が呪われるに一票。

446 ：デフォルトの名無しさん：02/10/26 15:17

パターンそのものの有用性より、そのパターンに名前がつけられてることに意味がある
､､､と思ってる俺は厨房？

447 ：デフォルトの名無しさん：02/10/26 16:43

>>446 所詮、その程度のものでしたってこった。

448 ：デフォルトの名無しさん：02/10/26 16:57

>>446 厨房ではない
>>447 厨房

449 ：名無しさん＠ＸＥｍａｃｓ：02/10/26 17:23

>>446
名前だけじゃなく、適用することにも意義がある。

デザインパターンを適用している場合、クラス名からどんなクラスか
想像できるし、hogehoge役はどれかな～って想像しながらソースを読
めるので、ソースの解析が楽になる。

450 ：デフォルトの名無しさん：02/10/26 19:15

同意。
使っていかなきゃ意味が無い罠。

451 ：デフォルトの名無しさん：02/10/27 02:10

VB.NET は屑!!

452 ：デフォルトの名無しさん：02/10/27 02:23

>>449
そんなもんコーディング規約で解決することも出来ると思うが。

453 ：名無しさん＠ＸＥｍａｃｓ：02/10/27 10:46

>>452
ハァ？コーディング規約で何が解決するの？ハンガリアン記法とかアフォ
事言わないよね？
デザインパターンを使ってれば、「クラス名」から「デザインパターン名」
が連想できて、さらに、「デザインパターン名」から「UML図」まで連想
できますが。

454 ：デフォルトの名無しさん：02/10/27 11:16

>>452
どこまで踏み込んだコーディング規約作ってんだ？

455 ：デフォルトの名無しさん：02/10/27 11:16

>>452
煽ってばかりなのもつまらんので、ちょっとまじめに書いて見るけど、
コーディング規約とデザインパターンが互いに置き換えられないのは、
抽象度が違うから。

パターンと言われてるものを、抽象度の高い順に有名どころを並べて見ると、
・アナリシスパターン（ドメインの話）
・デザインパターン（デザインの話）
・イディオム（言語の話）
・コーディング規約（書き方の話）
って感じ。
# ちょっと作為的なんだけど突っ込まないでください。

書き方の問題に対する解法でデザインの問題を解くことに無理があるの
は分かってもらえると思うんだが。
もしオブジェクト指向が苦手な人だったらデザインパターンをアルゴリズム
に換えて考えて見ても、納得してもらえるんじゃないでしょうか。

456 ：デフォルトの名無しさん：02/10/27 15:46

「デザインパターンを使う理由」
→>>267

じゃいかんのか？

457 ：デフォルトの名無しさん：02/10/27 16:57

>>456
Gof本の最終章のやつね。

でもあれって、「一度テストを通ったプログラムは決していじってはいけない。」
って思ってる人（今でも結構多いと思いませんか？）にはなかなか通用しない
ところが難しい。

458 ：デフォルトの名無しさん：02/10/27 19:21

>>457
目的もよく理解出来ずに手段だけ取り上げて
「こんなの使えない」「こんなパターンなんて俺でも知ってる」
とか言ってる程度の奴には使えるようにはならんよ。

デザインパターンを有効に使える場面がある訳だから
分かってる人が有効に使えばいい話だよな。

459 ：デフォルトの名無しさん：02/10/27 20:44

他のものはともかく、テンプレートメソッドパターンも使わないやしっているんだろうか？

460 ：デフォルトの名無しさん：02/10/27 21:11

俺はシングルトンとテンプレートメソッドしか使えない
氏んでくる・・・

461 ：デフォルトの名無しさん：02/10/30 23:02

>>460
実装側じゃなくて抽象側でテンプレートメソッドが使えるとしたら
大丈夫です。氏ななくて良いです。
きっとオブジェクト指向の基本は既に理解できていると思うんで、
これから必要に応じて語彙を増やしていくのは割と簡単なはず。

まあ遅レスですけど。

462 ：デフォルトの名無しさん：02/10/30 23:31

>>458
禿同。パターンを侮るとパターンに泣くね。

463 ：デフォルトの名無しさん：02/11/01 12:05

Java 最高 !!

464 ：デフォルトの名無しさん：02/11/01 16:25

質問す。
アグレゲーションとコンポジションの違いがわかりません。
絶対必要な部品とそうでない部品というように思うんだけど、
それって主観の問題っていうか、微妙な当落ラインがある
んじゃないかと思うのですが、どうなんでしょう。
それとも、ビチッと決まるのでしょうか。

解答、あながいしますねー。

465 ：デフォルトの名無しさん：02/11/01 21:10

>>464
微妙にスレ違いな気がするが…

compositionはaggregationの一種で、aggregationは
associationの一種。
生成と消滅のタイミングが部分と全体で共通なのがcomposition。

c++の実装レベルなら「ビチッと決まる」けど、分析・設計レベルだと
グレーゾーンはある。ってかcompositionをふくめたaggregation自体、
「気休め」「使うべきでない」と言う人もいる。

466 ：464（あげます）：02/11/01 22:46

>>465
だめもとで聞いてみたんですが、レスありがとうございます。
なんか、前半のお話は勉強になりました。

ただ、
>生成と消滅のタイミングが部分と全体で共通なのがcomposition。
だと、compositionでないaggregationは、C++の実装レベルでは
何になるのでしょう？それと、
>「気休め」「使うべきでない」と言う人もいる。
俺の勘違いだと思うんすけど、コンポジションを使うべきでない？
というのは、まったくわかりません。メンバ変数を使うなというように
聞こえるのですが。。。

スレ違いならすみません。
でも、できたら教えてください。
お願いします。（今度はマジです。）

467 ：464：02/11/01 22:53

>>465
連続質問ですが。。。
そもそも「C++の実装」とUMLの書き方の対照がわかるような
本かサイトか資料をご存知でしたら、教えてください。
お願いします。

468 ：デフォルトの名無しさん：02/11/02 01:46

465 ではないが。

>>466
＞だと、compositionでないaggregationは、C++の実装レベルでは
＞何になるのでしょう？それと、
なんにせよ実装レベルでは関連はメンバ変数になる。

＞俺の勘違いだと思うんすけど、コンポジションを使うべきでない？
＞というのは、まったくわかりません。メンバ変数を使うなというように
＞聞こえるのですが。。。
単なる関連として記述した方が、記述者による解釈のゆれが少なくて済む、
ということかと。

>>467
分析・設計と実装は分けて考えよう。
UML はどっちかというと分析・設計に用いるのがメイン。

469 ：464 == 466：02/11/02 08:14

一夜明けてみると、やっぱりスレ違いであることに気が付きました。
すみません。

>>468
にもかかわらず親切なレス。ありがとうございます。

470 ：デフォルトの名無しさん：02/11/02 13:43

Bridgeの意義を誰かわかりやすく教えてください

471 ：デフォルトの名無しさん：02/11/02 15:59

機能を提供する側が実装を提供する側のオブジェクトを使って
何かやっているようなケースは、みんな Bridge じゃないのかなあ?

たとえばプログラム中にデバッグ用のオブジェクトダンプルーチンを
組み込んだとして、ostream& なんかを引数にとって、状況に応じて
コンソールに出力したりファイルに出力したりできるようにすれば、
これは立派な Bridge だと思うんだけど、どうかな。

472 ：　：02/11/02 16:50

>>470
デザパタは名前からイメージしてみるのが吉。
Bridgeなら何か二つのものが橋渡しされてる構造を思い浮かべる。

とは言え、既にある二つの何かに橋を架けるイメージより、むしろ
何となく一枚板っぽい何かを、一方通行の橋だけ残して二つに
切り離すイメージに近い。

「Bridgeの意義」の中にはオブジェクト指向を使う意義と、
パターンを適用する意義が自動的に含まれるわけだが、それらを
置いといて敢えて一言で言うと「片側ごとの拡張」だと思うんだが。
どうよ？

473 ：　：02/11/02 17:19

>>471
それはBridgeじゃないのでは。
Implementorは外には見せない。
ちなみにBridgeの別名はHandle/Bodyという罠。

カタログ記載の構造はある程度大事にしてしかないと、パターンの
良さが失われるなり。

474 ：デフォルトの名無しさん：02/11/02 19:06

・Bridgeの（超かんたんな）具体例
・その具体例でBridgeを使うことでどういうメリットが得られるたのか。

を教えてください。
１割くらいはなんとなくわかってるつもりなんですが、残りの９割が
どうしてもわかりません。

475 ：デフォルトの名無しさん：02/11/02 19:14

・JDBC
・インタフェイスと実装が分離でき、実装の入れ替えができる

476 ：デフォルトの名無しさん：02/11/02 19:44

>>471
>>475
実装をクライアントが選択できればBridgeなんですか？
単なる多態とはどうちがうんでしょう？

477 ：デフォルトの名無しさん：02/11/02 19:56

>>476
クライアントをコンパイルしなおさなくても実装を入れ替えられる。
場合によっては（言語によっては）実行時に実装を選択できる。

478 ：　：02/11/02 20:30

>>476
手元に何かDesignPatternのクラス図とかある？
無かったら用意した方がいいし、あったらじっくり眺めてみるといい。
それを飛ばしてメリデメだけ考えてもいつまでたっても理解できない。

単なる多態との違いもクラスの構成を見れば分かる。
例えば単なる多態をこんな風に表現するとする、
　クライアント→抽象クラス⇒実装クラス
Bridgeにはこんな関係が二つ出来る。
　クライアント→Abstract抽象クラス⇒Abstract実装クラス
　Abstract抽象クラス→Implementor抽象クラス⇒Implementor実装クラス
（これは、多態との違いを示しただけで、Bridgeの構成には
まだ他にいつかのポイントがある。自分で確認してみてください。）

ある程度、基本を理解していないと具体例を示されても結局ピンと
こないんじゃなかろうか。

479 ：デフォルトの名無しさん：02/11/02 20:38

抽象クラスって必要か？
実地じゃ絶対に使わないんだが

480 ：デフォルトの名無しさん：02/11/02 20:46

使わなくて済むところもあれば、使わないと済まないところもある。
どんな技術でもそんなもんでしょ。

481 ：デフォルトの名無しさん：02/11/02 20:52

>>479
インターフェースも絶対に使わない？
>>480
抽象クラス使わないと済まないところってある？

482 ：480：02/11/02 21:03

>>481
俺の場合もう6年以上プログラマやってるけど、オブジェクト指向の
仕事しかしたことが無いから、当然OOD/OOPは飯の種だし、抽象クラス
なしに仕事はできない。

だけどプログラマの仕事といってもいろいろいる。
汎用機でCOBOLやってる人も、まだまだたくさんいるよ。
Webの仕事でもPerl4を使い続けてるとこともいまだに多い。

483 ：479：02/11/02 21:13

抽象クラスっていっても
実際にコード書くときは最初にスタブでラップしない？
作りこみを後回しにするなら当然そうするし
それなら抽象クラスじゃなくて
最初から適当なスタブでいいじゃんと思った。
まあそれだけです。
結局抽象的な意味としては変わらないか。

484 ：デフォルトの名無しさん：02/11/02 21:30

>>483
おれの場合、仮コード書くとしたら実装クラスに書くなあ。
つまり、抽象クラスは最初に書くわけだが。

485 ：デフォルトの名無しさん：02/11/02 21:43

>>484
いや、仮コードをわざわざ書くのが面倒ってことで。

486 ：デフォルトの名無しさん：02/11/02 22:16

ちょっとずれますがJavaのabstract classって中途半端な気がしませんか？
interfaceがあればいらない気がするのだけど。
「interfaceとclassをいっぺんに定義したいときの手抜き用」みたい。

487 ：デフォルトの名無しさん：02/11/02 22:34

>>486
昔、c++の仕事してたので、interfaceがあるだけ
進歩に思えるけど、そう言われるとそうかもしれん。

とはいっても手を抜けるとこは抜けるようになって
た方が実用的には良かったりする。

デメテルなんかも一理はあるけど、こだわり過ぎる
と無理が生じたり。

488 ：名無しさん＠ＸＥｍａｃｓ：02/11/02 23:22

>>486
Interfaceはpublicな物しか定義できないけど、abstractなら、
非publicな物を定義できる。
ある事をするメソッドを、複数クラスに持たせたいが、public
にはしたくないって時とか。

まぁ基本的には、テンプレートとしての使い方がメインだが。

489 ：デフォルトの名無しさん：02/11/03 00:27

>>488
>Interfaceはpublicな物しか定義できないけど、abstractなら、
>非publicな物を定義できる。
それはpublicでないinterfaceを別に作ればよいのでは。

>ある事をするメソッドを、複数クラスに持たせたいが、public
>にはしたくないって時とか。
それは実装の問題で、インターフェースや抽象クラスの使い道とは
ずれるのでは。

490 ：U ◆CZtFsGiu0c ：02/11/03 01:58

抽象クラスはTemplate Methodパターンを実装する時は当たり前の
ように使うし、そうでなくても共通の実装を基底クラスに抜き出して
共通化して、その基底クラス自体はインスタンス化したくない場合には使う。

491 ：デフォルトの名無しさん：02/11/03 02:13

ホワイトボックス再利用のTemplateMethodなんかより
ブラックボックス再利用のStrategyの方がｲｲじゃない。

492 ：U ◆CZtFsGiu0c ：02/11/03 03:32

>>491
Template MethodパターンとStrategyパターンって単純に置き換えられる
ものじゃないでしょ。もちろん、Template Methodを使わなくても同様の
実装はできる。Template Methodのサブクラス実装部分を外に出して
コールバックオブジェクトとして渡すとか。その方が柔軟性はあるけど、
どっちがいいかはケースバイケースでしょう。

493 ：名無しさん＠ＸＥｍａｃｓ：02/11/03 11:51

>>489
勘違いしてるようだが、
Interfaceで、protected なメソッドやフィールドが作れますか？
という話をしてる。

494 ：デフォルトの名無しさん：02/11/03 12:25

>>492
TemplateMethodからStrategyへは
カナーリ単純に置き換えられると思うが。逆は困難かも。

>>493
protectedなメソッドを使ってコードを共有するというのは実装法の話でしょ。
abstract classを使えばインターフェース定義と実装の一部が同時に書けて
「手抜き」ができるというのは>>486で既出。
フィールドも実装の話ね。フィールドを公開したりしちゃいかんでしょ。

495 ：デフォルトの名無しさん：02/11/03 13:09

interfaceとabstractの使い方って明らかに違うと思うけど。

496 ：デフォルトの名無しさん：02/11/03 13:17

>>493 未確認だが C# ではできるらしい

497 ：デフォルトの名無しさん：02/11/03 13:37

こんなの見つけた。

『Synthesizing Object-Oriented and Functional Design to Promote Re-use』
http://www.ifs.uni-linz.ac.at/~ecoop/cd/papers/1445/14450091.pdf

やってることは、Visitorパターンをエンハンスしてるだけっぽいけど、薀蓄は
たくさん書いてあるんで、デザパタと関数型言語の両方興味ある人はどうぞ。

498 ：U ◆CZtFsGiu0c ：02/11/03 14:59

>TemplateMethodからStrategyへは
カナーリ単純に置き換えられると思うが。逆は困難かも。

それって、

>Template Methodのサブクラス実装部分を外に出して
コールバックオブジェクトとして渡すとか。

このコールバック部分をStrategyで実装するって事?
確かにできるけどその分複雑になるでしょ。だからケースバイケースだと:-)

>逆は困難かも。

困難っていうか、ロジックの枠組みを基底クラスで共通化できないと
Template Methodにする意味ないよね。

499 ：デフォルトの名無しさん：02/11/03 16:55

>>494は単に、間接層は増やすより減らすほうが難しいっていう事を、
一般論として言ってるだけと思われ。

500 ：デフォルトの名無しさん：02/11/04 03:07

だからシンプル設計で作っておいて、
必要が生じてから複雑にするのが望ましいのれす。

# UML PRESS vol.2 で似たような趣旨の記事があったな。

501 ：デフォルトの名無しさん：02/11/04 13:52

>>498
Javaで書けば、
this.template_method1(...)をstrategy.method1(...)に変えるだけだろ。

502 ：U ◆CZtFsGiu0c ：02/11/09 09:46

>>501
派生クラスが基底クラスのprotectedメンバを参照していなければね。

503 ：　：02/11/09 14:44

TemplateMethod VS Strategy・・・ｱﾌｫか。

と思ったけど、割とティピカルな継承 VS 委譲の図式でも
あるわけで、結構まともなテーマなのね。

504 ：デフォルトの名無しさん：02/11/09 23:56

>>490
C++ だと template method には template class 使っちまうな、俺。

505 ：デフォルトの名無しさん：02/11/13 14:56

属性文法の実装にビジターパターンを使うのって当り前でしょうか？
自分では画期的な思いつきのような気がしてるんですけど。

506 ：デフォルトの名無しさん：02/11/13 15:02

test

507 ：デフォルトの名無しさん：02/11/13 15:25

VisitorはCommandの拡張みたいな気がする。
呼び出したクラスへの参照をもたないのは、Commandナリ。しかし、
呼び出したクラスへの参照をもっていて、呼び出したクラスのメソッドを呼ぶことでVisitorになる。

Controller --> Command

Controller --> Visitor
Controller <-- Visitor

この解釈って、あってる？

508 ：デフォルトの名無しさん：02/11/14 03:08

>>507
ぜんぜん違うと思う。

509 ：　：02/11/16 05:47

>>507
Visitorはいいんだけど、Commandがちょっと・・・
GoF本にCoplienのFunctorとCommandパターンの違いが
書いてあるんで参照してみてはいかがでしょうか。

というかそのCommandと対比してVisitorを理解してるとすると
Visitorの方の理解もちょと怪しいかも。

510 ：デフォルトの名無しさん：02/11/17 16:13

age

511 ：デフォルトの名無しさん：02/11/17 16:20

ジャンに散々恥をかかされ復讐に燃える大谷は
偶然、キリコが自分の手先が経営している店で
食事をしているのを見かけた。
「げへへへ・・・おい、あの女の食べるものに
これを混ぜて来い・・・」
大谷の手先の店長はキリコの食べる食べ物の中に
大谷に指示された薬を混入した。
キリコは何の疑いも無く食べ始めた。
それは、五行に作らせた強力な睡眠薬の一種だった。
しばらくするとキリコは意識が無くなり始め食堂
の机に倒れこんでしまう。
「げぇへへへおい、あの女をを奥の部屋まで運べ」
店長は大丈夫ですか？といいつつ奥の部屋にキリコを
連れ込んだ。
全ては大谷の指示だった。
「さぁて、このクソ生意気な女をどう調理してやろうか
・・・ぐふふっ考えるだけで唾ができそうじゃわい」
意識を失っているキリコを目の前に大谷の目が妖しく光る・・・
　　　　　　　　　　　　　　　　　　　　　　　　　　　続く

512 ：デフォルトの名無しさん：02/11/17 16:39

クラスをどうやって設計するのかがわかるような気がする＜GoF本で
まだ全然読んでないけど有用な予感。

513 ：デフォルトの名無しさん：02/11/19 22:12

>>512
自分の5年前を見てるようだ。
ｶﾞﾝｶﾞﾚ

514 ：デフォルトの名無しさん：02/11/28 11:55

ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝ必死こいて学ぶﾔｼはチンカス

515 ：デフォルトの名無しさん：02/11/28 14:05

>>511
自分の5年前を見てるようだ。
ｶﾞﾝｶﾞﾚ

516 ：デフォルトの名無しさん：02/11/28 14:48

>>515
ジャン? 大谷? キリコ? 店長? 五行?

517 ：デフォルトの名無しさん：02/12/08 02:46

518 ：デフォルトの名無しさん：02/12/08 02:46

519 ：デフォルトの名無しさん：02/12/08 02:47

520 ：デフォルトの名無しさん：02/12/10 21:42

自分もまだ全部読んでいないのですが、
オブジェクトコンポジションが
何のことか具体的に良く分かりません。
文法用語なのでしょうか？

521 ：デフォルトの名無しさん：02/12/10 21:56

>>520
ガイシュツ。このスレを検索せよ。

522 ：デフォルトの名無しさん：02/12/10 22:13

>>521
すいません。
すべて読んではいませんが検索してから書き込みました。
またさらっと見てみたのですがありませんでした。
オブジェクトコンポジションというのは
compositionとなにか関係あるということでしょうか？

523 ：デフォルトの名無しさん：02/12/10 23:40

しょうがないなぁ。ほれ >>464-468

524 ：デフォルトの名無しさん：02/12/11 23:11

>>523
ありがとう。
オブジェクトコンポジションてこれのことなんですか？

525 ：U ◆CZtFsGiu0c ：02/12/12 13:20

>>524
どういう文脈で出てきたのかわからないと誰も答えられないと思うぞ。

526 ：デフォルトの名無しさん：02/12/12 17:35

サーバー・クライアントソフトでサーバーはクライアントの出来る行為を
アカウント情報参照して許可・不許可するソフトの場合

if( アカウント情報参照結果が許可の時 ){
クライアントの要求を実行して結果を送信}
else{
その行為は許可されていない旨をクライアントに送信}

って感じのコードがあちこちに散在することになるんだけど、
なにかうまいデザインパターンはないでしょうか。
不許可の時に例外飛ばせばif文はなくなるけど例外ってコスト的に問題あるし・・
皆さんならどうしますか？

527 ：U ◆CZtFsGiu0c ：02/12/12 18:25

>>526
「クライアントのできる行為」とやらをCommandパターンまたはStrategyパターン
でカプセル化。実行許可されている場合にはその処理を実行するオブジェクトを
生成し、不許可の場合は不許可時の処理を行うオブジェクトを生成して実行する。

Null Objectパターンと似てるけど、多分どっかで誰かがやってて名前がついて
そうな気がする。

528 ：デフォルトの名無しさん：02/12/12 21:10

>>525
失礼しました。
GOF本改訂版にてオブジェクト指向において機能を再利用する
技法としてクラス継承とオブジェクトコンポジションがある
とありました。

JAVAにおけるインタフェース実装のような技術で
文法用語なのかと思ったのですが、調べてみても
よく分かりませんでした。

529 ：デフォルトの名無しさん：02/12/12 21:35

>>527
レスありがとうございます。
なるほどNull Objectパターンですか。こうやって指摘されてみると
用途にぴったりのようです。
これをヒントに設計してみたいと思います。
ありがとうございました。

530 ：デフォルトの名無しさん：02/12/13 09:09

アナリシスパターンってプログラム設計には必要なんでしょうか？
DB設計には使えそうかなとも思うんですが。。。

531 ：U ◆CZtFsGiu0c ：02/12/13 12:07

>>528
それは要するに、コードの再利用を実装継承で実現するか、集約+委譲で実現
するか、ということだよね。シンプルに説明すれば、既存のクラスインスタンスを
プライベートメンバとして持ち、そのインスタンスのメソッドを実行することで
再利用する方法です。

このスレッドで出てきたcompositionの説明は(現バージョンの)UMLにおける
composition(とaggregation)の定義ですね。

532 ：U ◆CZtFsGiu0c ：02/12/13 12:48

>>530
その名の通り「分析」のパターンなので、プログラム設計レベルの話ではない
です。難解で有名な本なので、あまりお薦めしません。

533 ：デフォルトの名無しさん：02/12/13 14:21

オブジェクトコンポジションを利用した設計は継承を利用した設計よりも
柔軟性があります。

カプセル化という考え方からすると継承はメソッドのオーバーライドなどにより、
既存の設計を大きく変えれてしまいます。
また、コンパイル時に仕様が確定しないなど、セキュリティ上大きな欠点があります。

ただし、継承はプログラミング時にオブジェクト生成のための冗長なコードを書く必要が無かったり、
スーパークラスでメソッドを書き換えれば全てのコードにその影響を反映させることが
できるなど、メンテナンス性においてはオブジェクトコンポジションより優れています。
また既存の優れたデザインパターンを利用できるというメリットもあります。

どちらをとるかは要件により決定します。

534 ：528：02/12/14 23:24

>>531,533
ありがとうございます。
なんとなく分かりました。

535 ：デフォルトの名無しさん：02/12/20 22:18

jdkのソース読むとデザインパターンの勉強になりますか？

536 ：デフォルトの名無しさん：02/12/20 23:00

>>526-527
例外をそんなに嫌うこともないとは思うけど。

Command を実行する時点で例外を出したかったら、
Command + Proxy + Delegate で。

interface Command {
　　void invoke();
}

class CommandProxy implements Command {
　　private Command cmd;

　　CommandProxy(Command c) {
　　　　this.cmd = c;
　　}

　　void invoke() {
　　　　/* security check */
　　　　thic.cmd.invoke();
　　}
}

// client code
Command targetCommand = new CommandProxy(new CommandImpl() );
targetCommand.invoke();

537 ：デフォルトの名無しさん：02/12/20 23:06

アナリシスパターンはよいよ～。
1回目はちいとも分からんけど、通読だけはしておくことを薦めるよ。

ある時はたと悩んでアナリシスパターンをパラパラめくったら
「あらやだ！こんなところに解決策が」ということも多い。

>>530
DB設計というよりはモデル設計に使うよ。
モデルを作ってからDBの論理設計を行う人には役立つはず(自分はこっち)。
DB設計してからアプリを設計する人は使わないと思う。

538 ：デフォルトの名無しさん：02/12/22 21:54

質問いいスか？結城本の次に何読もうかなと思ってるんですけど、
>>273の書籍って「買い」ですか？
もっといいのが出てるよ、とかあるのかな？

539 ：デフォルトの名無しさん：02/12/23 01:22

『リファクタリング』は、あたりまえのことがあたりまえに書いてある。
そういうのは、実はなかなか無い。
「何がよいこととされているか」という価値観を知るのにも役立つ良書だと思う。
お勧め。結城本の次くらいのレベルなら、間違った癖をつけて欲しくないからなおさらお勧めだよ。。

『パターンハッチング』は、まあ暇があったら読んでみたら程度。

540 ：デフォルトの名無しさん：02/12/23 04:17

>>537
アナリシスって、ひと言でいうとどんな感じ？

541 ：デフォルトの名無しさん：02/12/23 05:21

>>540
分析

542 ：デフォルトの名無しさん：02/12/23 12:09

書籍名は忘れたが、たしか会計システムの設計例みたいな本が出てたな。
そこでパーティとかの概念使われてたから、アナリシスパターンがよう分からんという人にはいいかも

スレ違いにつきsage

543 ：542：02/12/23 17:41

ごめん、"企業情報システムの一般モデル"だった。

544 ：デフォルトの名無しさん：02/12/24 22:35

ちょっと違う話なんですが、GOF読んだあとに
憂鬱なプログラマ～って本読んでみようと思うのですが、
よんだ人いますか？

545 ：デフォルトの名無しさん：02/12/24 22:56

>>504
読む順序が逆っぽい（ｗ

546 ：デフォルトの名無しさん：02/12/24 23:27

>>545
やはりそうですか。
JAVAを使うことでオブジェクト指向がわかるか的に思って
きてしまったのできちんと本を読もうと思っています。
憂鬱な～以外によいＯＯの本教えてください。

547 ：デフォルトの名無しさん：02/12/24 23:41

http://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/gof/list.html
既出だがここが一番わかりやすいと思う

548 ：デフォルトの名無しさん：02/12/25 10:29

>>546
初心者にとってはそれが一番いい本だよ。

>>547
お礼にいいページ見つけたんで紹介。
http://www.jahis.jp/about/katsudou/ki-gihou/2001/giho/giho2001-12.pdf

549 ：デフォルトの名無しさん：03/01/02 20:52

メリクリ！！

550 ：デフォルトの名無しさん：03/01/02 21:26

メリクリ！とかアケオメ！とかで女体の一部を連想してしまう私は
病気でしょうか？

551 ：Delﾌｻｷﾞｺ ◆A6VzDeLphI ：03/01/02 21:48

　　　　　　　　　　　　　　＿＿＿＿＿＿＿＿
　　　　　 ∧,,∧　　　　／
　　　　　ミ　　彡　＜　あなたさては
　　　　　(ﾐ　　ﾐ)　　＼
　　　　　ﾐ　　ﾐ　　　　　￣￣￣￣￣￣￣￣
　　　　　 ∪ ∪

　　　　　　　　　　　　　　＿＿＿＿＿＿＿＿
　　　　　 ∧,,∧　ｻｯ　／
　　　　　ミ,,ﾟДﾟﾐ　　＜　やらしい人ですね。
　　　　⊂ 　　Ｏm　　＼
　　　　　ミ､,, ﾐ,　　　　　　￣￣￣￣￣￣￣￣
　　　　　 .しヾJ

552 ：デフォルトの名無しさん：03/01/03 23:12

あけオメコとよろ～

553 ：デフォルトの名無しさん：03/01/05 04:14

パターンのリファクタリング前、リファクタリング後の良いソースとかないかなぁ

554 ：デフォルトの名無しさん：03/01/07 12:20

デザインパターンをCで書いたサンプルのコードはないかな？

555 ：デフォルトの名無しさん：03/01/07 12:27

>>553-554
ぐぐれ。あるいは書籍購入。
海外にいろいろある。

556 ：デフォルトの名無しさん：03/01/07 12:31

http://www.malib.net/api/ja/node2.html
これを参考に自分で書いてみるとか

557 ：名無し＠沢村：03/01/07 12:47

ヌヒ等よ、俺はプログラムで使う全ての変数を基底クラスにprivateで宣言し、それにアクセスするメソッドをpublicで基底クラスに宣言することがよくあるよ。
そして派生クラスではそれらを操作するメソッドをそのクラスに応じて定義するわけだ。
そして必要に応じてそれからクラスをさらに派生したりコンポジションで包含したりするわけだ。
こうすると基底クラスですべての変数を管理できるとても見通しのよいＯＯになるよ。
俺はこの方法を自己流だが、もっともすぐれたデザインパターンのひとつだと思っているね。

558 ：デフォルトの名無しさん：03/01/07 12:53

>>557
これはたぶん沢村本人のものでは無い。
この昼休み時間中に、どこかのヒマなｱﾌｫがコピペして回っている模様。

オリジナル：
http://pc3.2ch.net/test/read.cgi/tech/1041658161/255

ｺﾋﾟﾍﾟﾆﾏｼﾞﾚｽ､ｶｺﾜﾙｲ｡

559 ：デフォルトの名無しさん：03/01/09 02:49

>>638
こらっ！しんのすけ。

560 ：デフォルトの名無しさん：03/01/09 03:30

いよいよ終焉か

561 ：デフォルトの名無しさん：03/01/09 04:12

ID:ZBsKvw39さん

宿題終わった？
お風呂に入った？

湯冷めしないようにね・・・

562 ：デフォルトの名無しさん：03/01/09 13:43

217 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:49 ID:rLfxQ17l
　　　一定期間でログは消しますです。

249 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:52 ID:rLfxQ17l
　　　＞荒らしとか犯罪のためなの？
　　　そす。

246 名前：心得をよく読みましょう[] 投稿日：03/01/08 17:52 ID:BH998yxV
　　　>ひろゆき
　　　俺のお気に入りのスレとか荒されてるんだがそういうのにも有効？

257 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:53 ID:rLfxQ17l
　　　>>246
　　　いずれは。

563 ：デフォルトの名無しさん：03/01/09 14:48

2ちゃんねるはボランティアの削除人が書き込みをチェックして、
好ましくない書き込みを一所懸命削除している、
ということになっているが、あれはウソ。

削除人には給料が支払われ、その給料の原資となっているのが、
まずいことを書き込まれた企業が削除要求とともに渡す裏金。

564 ：デフォルトの名無しさん：03/01/09 17:34

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 138720人　発行日：2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

565 ：デフォルトの名無しさん：03/01/09 23:25

>>493
いくらなんでも、無差別にIP公開はしないと思うが。

566 ：デフォルトの名無しさん：03/01/10 08:26

>>578
誰でもみれる様になるの？

567 ：デフォルトの名無しさん：03/01/10 09:48

http://www.shitaraba.com/cgi-bin/read.cgi?key=991158920_1&bbs=robi&res=122
プロフィールです(^_^;)

>>171
今かかってきたのお前か！お前か！

568 ：デフォルトの名無しさん：03/01/10 10:27

なんか急速にスレのﾚｳﾞｪﾙが落ちたな

569 ：デフォルトの名無しさん：03/01/10 11:00

＞ある程度の人が集まって

それが重要だよね。
残念だが故郷を離れる、ミンゾク大移動の日は近いのだろう。
DQNも厨房も1人残らず移住できる箱舟が現れるのか・・・

570 ：デフォルトの名無しさん：03/01/10 11:45

どうしてmitutoとオカヤンのサイトのURLだけＮＧワードなのですか。
商用でもないのに。

571 ：デフォルトの名無しさん：03/01/10 12:15

正直、S/N比が改善されると思うのは俺だけ？
別にIP表示されるわけでなし。責任とれないような書き込みせにゃいいだけやろ？

572 ：デフォルトの名無しさん：03/01/10 13:05

ヤフーの投票文、「2ちゃんねるがアクセスログ記録を始めましたが何か？」にしてﾎｽｲ。

573 ：デフォルトの名無しさん：03/01/10 15:28

上のスレでは★付きボランティアの発言原則禁止。
ボランティアである事を匂わせる発言も同様。
こことは趣旨が正反対のウォッチスレ。
　
のはずだった。

574 ：デフォルトの名無しさん：03/01/10 16:54

各板「のトップに｢当インターネットはフィクションであり・・・・｣ってのせとけばそれで良くない？

575 ：デフォルトの名無しさん：03/01/10 23:16

実況・番組ｃｈには無意味ですな

576 ：デフォルトの名無しさん：03/01/10 23:21

>>705
来週も番組が無事でありますように

577 ：デフォルトの名無しさん：03/01/11 00:39

【２ちゃんねる七厨板】

1 ：水先案名無い人：02/08/02 02:14 ID:uMrNSS+/
２ちゃんねる七厨板【にちゃんねるななちゅういた】［名］
２ちゃんねるの中でも特に厨房の多い７つの板のこと。
どの板のことを指すのかは人のよって意見がわかれる。
例えばLeaf・key板、ハングル板、学歴板、厨房板、ペット大嫌い板、ネット事件、政治思想板など。
<<２典より>>

って、曖昧じゃん！明確に決まってないんかい！
なんか、だれが最初に言ったか知らんが『七厨板』って響きの良い言葉だけが先走って、
内容がおろそかになっている様子。
ガイドライン公認の『七厨板』を定めてはどうだろ

投票所
http://cgi.members.interq.or.jp/snake/watanabe/y/anc/main/anc/ancmulti.cgi?mode=enquete&number=21

【２ちゃんねる七厨板のガイドライン】本スレ
http://ton.2ch.net/test/read.cgi/gline/1028222092/

２典
http://freezone.kakiko.com/jiten/

578 ：デフォルトの名無しさん：03/01/11 00:47

今からこのスレッドは87氏を応援するスレッドになりました(^_^;)

579 ：デフォルトの名無しさん：03/01/11 03:39

コマンドって結局スイッチ文の嵐になるだけだよね？
Cみたいにメソッドを配列にできないもんかな？

580 ：デフォルトの名無しさん：03/01/11 03:44

>579
> Cみたいにメソッドを配列にできないもんかな？
C++ でもメンバ関数へのポインタはとれるけど。そういう話じゃなくて？

581 ：デフォルトの名無しさん：03/01/11 03:46

Command パターンの話？
switch 文なんて使わないけど。

582 ：デフォルトの名無しさん：03/01/11 03:47

>>579
使用言語はいったいなにを？
ファンクションへのポインタが使えるC,C++や、
メソッドをオブジェクトとしてあつかえるJavaとかなら楽そう

583 ：デフォルトの名無しさん：03/01/11 09:56

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

584 ：デフォルトの名無しさん：03/01/11 10:49

111 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:33 ID:rLfxQ17l
　　　＞datの書いた内容とIPが対になってることを証明すんのもめんどくさいもんな。
　　　そゆことです。

114 名前：心得をよく読みましょう[] 投稿日：03/01/08 17:34 ID:ZxrhkN5z
　　　幼女をレイプします

119 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:35 ID:rLfxQ17l
　　　　　　携帯電話からご苦労様です。

139 名前： ◆FruitsMIpE [sage] 投稿日：03/01/08 17:38 ID:s/ESWpsO
　　　「携帯から」とか公開しないでほすぃ。。

150 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:40 ID:rLfxQ17l
　　　みたいなことを書いたらそうなりますです。さん

170 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:42 ID:rLfxQ17l
　　　負荷が高そうなサーバにも入れて見ます。

217 名前：ひろゆき ◆3SHRUNYAXA [] 投稿日：03/01/08 17:49 ID:rLfxQ17l
　　　一定期間でログは消しますです。

585 ：デフォルトの名無しさん：03/01/11 11:19

な～～んか怪しいな・・・

586 ：デフォルトの名無しさん：03/01/11 12:20

　　　　　　　言いたいことも言えないこんな世の中じゃーー

ついに聖域まで汚染されました、

587 ：デフォルトの名無しさん：03/01/11 12:54

快速ﾀﾝ書き初めはみてもらえたでしょうか。
http://newsplus.jp/~thomas/bbs/img-box/img20030103203150.jpg

588 ：デフォルトの名無しさん：03/01/11 15:42

やっぱり、運営者の判断力が重要だと思う。
今までは、判断してこなかったからやってこれたが、
今後は、真の「管理能力」が問われることになる。

589 ：デフォルトの名無しさん：03/01/11 15:48

ひろゆきの腐れチンコめ
氏ね

590 ：名無し＠沢村：03/01/11 20:31

へにょろっヌヒ等よ、大変だぞ！！
俺はふと思って２ちゃんねるのあっちこちの板を見て回ったのよ。
格闘技板とかアナウンサー板とかプログラマー板とかをな。
そうしたらな、どこのスレ開いても最近ひろゆきの話題が出てる板はプログラム技術板だけだったぞ！！
ヌヒ等よ、ここは２ちゃんねるいっちゃん恥ずかしい板だぞ！！

591 ：デフォルトの名無しさん：03/01/11 22:09

コマンドパターンでJava使うとスイッチばっかり

>>582
メソッドをオブジェクトとして扱う方法ってなんなの？
知らないよ俺。

592 ：デフォルトの名無しさん：03/01/11 22:22

>>591
「Object.getClass().getMethods()で取って来て、Method.invoke()叩く。」
ってことじゃない？（Strutsでもやってるはず）

でも、素直にスイッチ使った方が遙かにマシ。

593 ：デフォルトの名無しさん：03/01/11 23:29

２ちゃんの普通が基準なのか、それとも現実世界での普通が基準なのか
問題だよ！犯してーなんて２ちゃんではどこでも見かける言葉じゃん
でも、現実世界では人前では言わない言葉だ、そこらへんどうなのよ？

594 ：デフォルトの名無しさん：03/01/11 23:30

2chの解説本が出てました。たわいないです。

http://shopping.yahoo.co.jp/shop?d=jb&id=07107411
-----------------------------

「２ちゃんねるのウラオモテ超入門」

マイウェイムック、143ページ

監修・２ちゃんねる
発行・マイウェイ出版株式会社
発行日・2003年2月20日
値段・1429円

595 ：デフォルトの名無しさん：03/01/11 23:40

>>592
Methodの参照をコレクション系の何かに入れておいて...とか、
HashMapに入れておいて...とか、俺ならする。

switchやifの嵐の方が処理的には早いと思うが、拡張する時の手間考えたら、
その方がスマートにできる..とか言ってみるテスト。

596 ：595：03/01/11 23:47

ついでに言うと、拡張する時の内容によるが、場合によってはMethodに共通の
「俺仕様インタフェース」を取り付けてメンバの操作をしたいので、
ここでアダプタorブリッジパターンを使って、俺仕様化したMethodの参照を、
クライアント側（この場合はコマンドパターンの実装側）で、操作するようにすると、
さらにいい感じのような気がする。

597 ：592：03/01/12 00:45

>>595
Methodクラスなどリフレクションは型チェック出来ないんで極力使わない方が良いのでは？
拡張性に関しては、プロトタイプパターン使って解決すれば多分Methodクラス使うよりも
パフォーマンス的にもマシで、かつJava本来の型チェック機能も損なわないかと。

//コマンド登録
HashMap map = new HashMap();
map.put("hoge", new HogeCommand() );

//コマンド呼び出し
HogeCommand exec = (HogeCommand)map.get("hoge").clone();
exec.execute();

自分としては、コマンドパターンを適用する箇所は結構ホットスポットになるんで、
int系のキーとswitch文（テーブルアクセスしてくれるはずなんで）使ってます。
（コマンドの拡張はコマンドのファクトリーを継承して数増やす）

598 ：デフォルトの名無しさん：03/01/12 01:15

>>597
フレームワークの中とかで部分的に使うなら
リフレクションも悪くないと思うけどな。
リフレクションだらけのコードはいやだけど。

599 ：582：03/01/12 02:11

>>592
そうそう。そういうこと。
でも書いてから気がついたけど
C++やJavaでのCommandパターンなら多態性つかえばすむよね。

ていうか>>591の
>コマンドパターンでJava使うとスイッチばっかり
はどういう意味？
むしろ俺はそっちを聞きたい。
JavaでCommandパターンを実装するとして
switchをどういう風に使うの？

600 ：デフォルトの名無しさん：03/01/12 02:14

泣くかと思った。

601 ：デフォルトの名無しさん：03/01/12 02:18

全鯖ログ記録ｷﾀ━━━(ﾟ∀ﾟ)━━━ !!!!!

602 ：デフォルトの名無しさん：03/01/12 02:54

> JavaでCommandパターンを実装するとして
> switchをどういう風に使うの？

そうそう、確かにこれには同意する。
多分、Strategyパターンのコンテキストスイッチ部分と勘違いしてないかな？

603 ：デフォルトの名無しさん：03/01/12 09:51

4nd　ボー　カレー

604 ：デフォルトの名無しさん：03/01/12 11:23

>>591 の
＞コマンドパターンでJava使うとスイッチばっかり
ってのは、たぶん

class FooCommand {
　public final static int COMMAND_0=0;
　public final static int COMMAND_1=1;
　public void doCommand(int cmdCode) {
　　switch(cmdCode) {
　　　case(0): // COMMAND_0
　　　　// some proc ..
　　　:
　　　:

のような物を想像しているのでは。
でも、これだとcaseに指定できる値はリテラルだけなので、
なんぼ final staticでも、引数と分岐のキーの一致保証は、メソ内のコード依存
って事になるが。やっぱスマートじゃないな。

605 ：604：03/01/12 11:24

だいたいJava固有な書き方じゃないし。

606 ：604：03/01/12 11:33

つーか、int全部OKはちょっと問題だし。やるとしたら、むしろこうか？

public interface CommandArg {
　　public int getCommand();
}

public class CommandArgA implements CommandArg {
　　public int getCommand() { return 0 }
}

public class CommandArgB implements CommandArg {
　　public int getCommand() { return 1 }
}

class FooCommand {
　public void doCommand(CommandArg arg) {
　　switch(arg.getCommand()) {
　　　case(0): // COMMAND_0
　　　　// some proc ..
　　　:
　　　:

607 ：デフォルトの名無しさん：03/01/12 19:07

なんかそれだと Interpreter っぽいね。
コマンドを突っ込む Queue を作らない？

608 ：デフォルトの名無しさん：03/01/12 20:39

岡田克彦ファンクラブからのご案内です。岡田克彦氏の卒業した早稲田大学
政治経済学部に比べて著しい低学歴、特に、ひろゆきの卒業した中央大学文学部
のようなヘボい大学に共通しているのは、文化水準が低いという事です。18歳から22歳を
ヘボい大学で過ごすということは、致命傷と言えます。２ちゃんねらーの大半は
岡田克彦氏に比べて、著しい低学歴ですから、取り返しはつかないのです。
せめて、http://www.geocities.co.jp/MusicHall-Horn/1091/で、氏の作品に触れましょう。

609 ：デフォルトの名無しさん：03/01/12 20:44

Internet Service Providerが契約者に対し
顧客情報の開示を行うことを明らかにするだけだ。
責任は書き込んだ奴が取るだけ。

610 ：602：03/01/12 20:50

>>604

ってかswitch部分は、Commandの具象クラスの外に出すべきだと思われ。
(でないと、CommandパターンでMacroやUndoの実装がしにくくなるでしょ？)

んで、Commandインスタンスの生成は、Factory Methodパターンを使い、
Factoryの具象クラスが分岐に責任もてばいいのでは？
Commandパターンでは、invokerはAbstractCommandのメソッドを実行するだけ
なんだから。

611 ：デフォルトの名無しさん：03/01/12 20:52

最近カール★さん見ない・・・

612 ：604-606：03/01/12 21:06

>>607
＞なんかそれだと Interpreter っぽいね。

形が、って事？確かにこんだけのソースだとそう見える気も。気づかんかった。
でもデザパタって、「形は似てるけど目的が違う」みたいなの多いよね。

＞コマンドを突っ込む Queue を作らない？

そだね。マジでやるなら、そうした方がいい。

613 ：604-606：03/01/12 21:07

>>610
＞Commandインスタンスの生成は、Factory Methodパターンを使い、
＞Factoryの具象クラスが分岐に責任もてばいいのでは？

そこまでやるならファクトリからCommand部を取るより、Storategyにした方が
良くない？
実装の拡張(Macroとか)を意識するなら、Commandの実体をビルドする形より、
むしろその部分を挿げ替えてしまえる方が自然な気が...。どうか。

614 ：デフォルトの名無しさん：03/01/12 23:17

多分、純粋に591が言いたいのはFactoryのswitchが面倒と言うことでは？

615 ：デフォルトの名無しさん：03/01/13 00:00

GoF通りのFactory Methodならswitch文なんか出てこないような
気がするのだが。。。

616 ：デフォルトの名無しさん：03/01/13 00:26

一箇所（一メソッド内）で複数種の Command を作成する設計なんじゃない？

617 ：山崎渉：03/01/13 18:29

（＾＾）

618 ：デフォルトの名無しさん：03/01/13 22:19

☆★☆
|・∀・)♪　　おあよーおあよー！
|⊂ ノ
|` Ｊ　　　　朝だす、みんな起きるだす！！

619 ：山崎渉：03/01/15 17:53

（＾＾）

620 ：デフォルトの名無しさん：03/01/16 01:51

gof読んだけど
JAVAで学ぶデザインパターンも読もうかと思っています。
学ぶことは多々ありますか？

621 ：デフォルトの名無しさん：03/01/16 01:55

>>620
一言でいうと、gof本よりもわかりやすい言葉で書かれている。
Javaで書かれた実際に動くサンプルコードがついてくる。

622 ：デフォルトの名無しさん：03/01/16 02:32

憂鬱本よんでいたら
クラスライブラリがアプリケーションクラスを用意してる場合もある
というようなことが書いてあったのですが、
どのようなものがあるのでしょうか？
できればJAVAで教えてください。

623 ：デフォルトの名無しさん：03/01/16 03:03

>620
イラストの投げやりっぷりが笑える

624 ：デフォルトの名無しさん：03/01/16 03:13

＞＞621
スレッド編をよみたいので先にこちらを読もうかと思ったのですが、
gof本で理解できれば飛ばしても問題ないですかね？

625 ：デフォルトの名無しさん：03/01/16 05:46

>>624
GoFで理解できたのなら、読み飛ばしても問題ないかと。

626 ：デフォルトの名無しさん：03/01/19 13:14

>539
ありがとうございます～。間ができたのでやと買いますた。
今日からちょいちょい読んでいきます。

627 ：山崎渉：03/01/23 20:13

（＾＾）

628 ：デフォルトの名無しさん：03/02/03 22:41

ただあげてみる

629 ：デフォルトの名無しさん：03/02/04 21:22

質問です。getter/setterを実装するときに、たとえばVector(String)型を保持したい場合には
どのように実装すればいいのでしょうか？

public Vector getVector() { return this.vector; }
public void setVector(Vector v) { this.vector = v.clone(); }

で実装してしまうと、String以外のObjectのVectorを渡すことが出来てしまうので
あまり良くないと思ってしまったのですが…。

public String[] getStrings() { return makeStrings(this.vector); }
public void setStrings(String[] strings) { makeVector(strings); }

このように実装すると、どうせ両者ともVectorで実装されているので、いまいち美しくない感じがします。

正しいデザインパターンではどのように実装すべきでしょうか？

630 ：デフォルトの名無しさん：03/02/04 21:29

そりゃデザパタじゃなくって言語の機能だよ｡
言語のサポートが得られなければ
取り出すときに型をチェックするしかない｡

631 ：デフォルトの名無しさん：03/02/04 21:34

あ、確かに
スレ違いすみません。

632 ：デフォルトの名無しさん：03/02/04 21:44

まあまったく無関係というわけでもないけど｡
一度型を指定してしまうと後からさらに
型を限定するのが困難なのはデザパタ・OOPL共通の問題だからね｡
GoFのCompositeでそこら辺に言及してたような｡

633 ：デフォルトの名無しさん：03/02/08 23:20

シングルトンってオブジェクトを生成する必要あるか？

634 ：デフォルトの名無しさん：03/02/08 23:56

全部staticにすればインスタンスを生成する必要は無いけど
実装がstaticまみれになるのがいやだったりインスタンスの参照を渡せなかったり
使い方がオブジェクトと違うのがいやだったりでインスタンス化することもある｡

635 ：デフォルトの名無しさん：03/02/09 01:11

>>634
（ﾟ∀ﾟ）ｻﾝｸｽｺ
staticに生きるよ

636 ：デフォルトの名無しさん：03/02/09 10:57

結城さんの ML で思ったんだけど、実務の世界ではデザインパターンはほとんど浸透していないのですか?
もしかして、いま勉強してもあまり意味がないの?

637 ：デフォルトの名無しさん：03/02/09 12:22

>>636
そんなことないと思うよ。使うことは使うと思うけど、
メンバー全員が理解している状態ではないという感じ。

638 ：デフォルトの名無しさん：03/02/09 18:54

デザインパターンは、「考え」を正規化してライブラれるから便利。

639 ：デフォルトの名無しさん：03/02/10 03:22

アレキサンダーのデザパタ本読んでないのに
デザパタわかったつもりになってる奴って痛すぎ｡
なんつーか底の浅さが見え見えだよな｡

640 ：デフォルトの名無しさん：03/02/10 20:46

オマエガナー

641 ：デフォルトの名無しさん：03/02/11 17:00

>>636
特定のフレームワークや、クラスライブラリを使うときに、デザインパターン
知らないより知ってた方がいいよ。知らないとサンプル見ても意味わからん
ときがあるから。

サンプルとか、既に造ってある使い方以上の改造が必要になった時にフレーム
ワーク造った人の意図を推測できるかどうか、どのパターン適用してる判別可能
かどうかが、結構効いて来る。（クラス名から推測できるようにしてあるとあり
がたい）

642 ：デフォルトの名無しさん：03/02/15 13:02

アレキサンダー読んでない大工はドキュン
プログラマについてはその限りにあらず

643 ：デフォルトの名無しさん：03/02/15 14:03

他人にクラス構造を説明するとき、あるいは３ヶ月後の自分に思い出させるとき
一言で済むのがいい。

644 ：デフォルトの名無しさん：03/02/21 20:40

Gof日本語改訂版98ページの

AbstractFactoryクラスでは、部品を生成するためのインタフェースが
宣言されるだけであり、実際の生成はConcreteProductに任されている。

がよくわかりません。教えてください。

645 ：デフォルトの名無しさん：03/03/09 15:44

gofよんたので、今はリファクタリングよんでます。
次はスレッド編を読もうと思ってるのですがそれ以外にいいのありますか？

実践しろと言わないでください。読むのが好きなので。

646 ：デフォルトの名無しさん：03/03/09 16:26

>>645
Eiffel や smalltalk なんかにも手を出してみるのはどう？

647 ：世直し一揆（コピペ推奨）：03/03/09 17:42

＜血液型A型の一般的な特徴＞（見せかけのもっともらしさ（偽善）に騙されるな！！）
●とにかく気が小さい(神経質、臆病、二言目には「世間」(「世間」と言っても、同じＡ型を中心とした一部の人間の動向に過ぎないのだが・・・）、了見が狭い）
●他人に異常に干渉し、しかも好戦的でファイト満々（キモイ、自己中心、硬直的でデリカシーがない）
●妙に気位が高く、自分が馬鹿にされると怒るくせに平気で他人を馬鹿にしようとする
（ただし、相手を表面的・形式的にしか判断できず(早合点・誤解の名人)、実際にはた
いてい、内面的・実質的に負けている）
●本音は、ものすごく幼稚で倫理意識が異常に低い（人にばれさえしなければＯＫ！）
●権力、強者（警察、暴走族…ｅｔｃ）に弱く、弱者には威張り散らす（強い者にはへつらい、弱い者に対してはいじめる）
●あら探しだけは名人級でウザイ（例え10の長所があってもほめることをせず、たった１つの短所を見つけてはけなす）
●基本的に悲観主義でマイナス思考に支配されているため性格がうっとうしい（根暗）
●単独では何もできない（群れでしか行動できないヘタレ）
●少数派の異質、異文化を排斥する(差別主義者、狭量）
●集団によるいじめのパイオニア＆天才(陰湿＆陰険）
●悪口、陰口が大好き（Ａ型が３人寄れば他人の悪口、裏表が激しい）
●他人からどう見られているか、人の目を異常に気にする（「～みたい」とよく言う、
世間体命）
●自分の感情をうまく表現できず、コミュニケーション能力に乏しい（同じことを何度
も言ってキモイ）
●表面上協調・意気投合しているようでも、腹は各自バラバラで融通が利かず、頑固(本当は個性・アク強い）
●人を信じられず、疑い深い（自分自身裏表が激しいため、他人に対してもそう思う）
●自ら好んでストイックな生活をしストレスを溜めておきながら、他人に猛烈に嫉妬
する（不合理な馬鹿）　　
●後で自分の誤りに気づいても、強引に筋を通し素直に謝れない（切腹するしかない！)●自分に甘く他人に厳しい（自分のことは棚に上げてまず他人を責める。包容力がなく冷酷）
●男は、女々しいあるいは女の腐ったみたいな考えのやつが多い(例：「俺のほうが男
前やのに、なんでや！（あの野郎の足を引っ張ってやる！！）」）

648 ：デフォルトの名無しさん：03/03/25 21:13

commandパターンむづい．．．

649 ：デフォルトの名無しさん：03/03/29 15:45

>648
どの辺？
いまさらだけど。
コマンドパターン自体は難しくない気が、、、、

650 ：デフォルトの名無しさん：03/03/29 15:52

http://www.pink-angel.jp/betu/linkvp2/linkvp.html
　　　　　　　　★みんなの情報局★

651 ：デフォルトの名無しさん：03/04/02 13:15

// よく見かけるSingletonの実装。
// 最初のGetInstance()でインスタンスを作る。

// xxx.h ファイル側
class Singleton {
  static Singleton* instance;
  Singleton() {}
public:
  Singleton* GetInstance() {
    if( instance == 0 ) instance = new Singleton();
    return instance;
  }
}

// で、xxx.cpp 側が
Singleton::instance = 0;
ってなってたりするんだけど、これ
Singleton::instance = new Singleton();
ってやっちゃだめなのかな。

「GetInstance()メソッドでマルチスレッドの時の排他が～」
なんて問題について議論してるWebサイトとか結構見るのだけど、
GetInstance()の外でインスタンスを作ればええやん。なぁみんな。

652 ：U ◆CZtFsGiu0c ：03/04/02 17:28

>651
インスタンスの生成時に例外処理が必要なければいいと思いますよ。

653 ：デフォルトの名無しさん：03/04/06 04:41

ゲームとか作るときに敵キャラやプレイヤーのクラスにDrawってメソッドを作るとして、
この場合どのパターンを使ってどんな感じで絵画させればいいの？
1,DrawメソッドにWindowクラスのポインタか参照を渡す。
2,敵キャラやプレイヤーのクラスにWindowへのポインタのメンバを含める
3,その他

654 ：デフォルトの名無しさん：03/04/06 04:48

キャラなんてロジカルなものが描画コードを持つのは良くないだろ｡
Screen.Draw(Player)とかのが良くないか｡

655 ：別人ですけど：03/04/06 05:29

その場合、Screenが、大量にオーバーロードされたDraw関数を一手に引き受けることになって
case文みたいでオブジェクト指向らしく無い、つか、
Playerに関するコードがPlayerクラスの外にも分散してしまうのが、
俺の脳味噌の貧弱な管理能力を無駄に消費してしまうようで気持ちよく無いです。

しかし画面と関係無しに存在できるはずのPlayerクラスが描画コードを持つのも
Playerクラスを再利用することなんてまずあり得ないとわかっていても、やはり良く無い気が。
それでも多態を利用できるのは便利なので、俺は渋々PlayerのようなクラスにDrawを持たせてます。

ミックスジュースとかなら、画面と無関係に作ったPlayerクラスに、
後からDrawメソッドを追加できていい感じ？？(ミックスジュース使ったことないので詳細不明)

656 ：デフォルトの名無しさん：03/04/06 05:44

>>655
普通、そういうコードにはしないと思うよ。

657 ：デフォルトの名無しさん：03/04/06 06:57

>>656
普通どういうコードにするの？

658 ：デフォルトの名無しさん：03/04/06 07:23

古いからちょっと割り引いて読むべし
ttp://www.fujigoko.tv/rev/prof/doc4/index.html

659 ：デフォルトの名無しさん：03/04/06 09:37

Screenクラスは基本的な作画クラスを集約し、それらを使って作画をサポートする。
細かい作画指定は、Prayerクラスが持つDrawSettingクラスあたりから取得する。
設定は、DrawSettingクラスを継承したクラスに書いて、各Prayerクラスで使い回す。

660 ：あぼーん：03/04/06 09:56

（　´∀｀）/＜先生！！こんなのを見つけました。
http://muryou.gasuki.com/moe/jaz08.html
http://muryou.gasuki.com/moe/jaz07.html
http://muryou.gasuki.com/moe/jaz10.html
http://muryou.gasuki.com/moe/jaz09.html
http://muryou.gasuki.com/moe/jaz06.html
http://muryou.gasuki.com/moe/jaz05.html
http://muryou.gasuki.com/moe/jaz04.html
http://muryou.gasuki.com/moe/jaz03.html
http://muryou.gasuki.com/moe/jaz02.html
http://muryou.gasuki.com/moe/jaz01.html

661 ：Screenクラスの実装例：03/04/06 10:02

public void Draw(HasDrawSettingInterface argHasDrawSettingInterface) {
this.SetDrawSettingInterface(
argHasDrawSettingInterface.GetDrawSettingInterface()
);
//DrawSettingInterfaceをもとに描画するコード
}
インターフェイスじゃなくて仮想クラスとかでも可。命名規則は説明のためにあえて冗長になってまつ。

662 ：デフォルトの名無しさん：03/04/06 13:23

PlayerクラスとPlayerDrawerクラスをペアで定義して
Screenはその対応付けをするだけでいいでしょ｡
こんなかんじで
Player.Drawer = new PlayerDrawer();

663 ：デフォルトの名無しさん：03/04/07 21:32

こんな事いったら怒られるだろうな…。でもいいまつ…。

GoF本の正式名称教えて下さい！

664 ：デフォルトの名無しさん：03/04/07 21:34

>>663
> こんな事いったら怒られるだろうな…。でもいいまつ…。
> GoF本の正式名称教えて下さい！
http://www.google.com/search?lr=lang_ja&num=50&q=GoF%96%7B

665 ：デフォルトの名無しさん：03/04/07 22:13

>>664
うわーい。ありがとーー。

666 ：デフォルトの名無しさん：03/04/07 23:17

それこそMVCの適用事例。

667 ：デフォルトの名無しさん：03/04/07 23:44

>>651
遅レスですが、あなたの主張では
>最初のGetInstance()でインスタンスを作る。
を満たしてないような気がする

668 ：デフォルトの名無しさん：03/04/07 23:50

>>667
いいたかったのは
「最初のGetInstance()でインスタンスを作るような
　Singletonの実装をよく見かけるけど、
　GetInstance()で作んなくてもいいじゃん」
ってことです。

669 ：デフォルトの名無しさん：03/04/08 00:09

>>668

class A{
static A *inst_;
public:
static A *instance()
{ return inst_; }
void foo(){}
};
A *A::inst_ new A;

class B{
static B *inst_;
public:
static B *instance()
{ return inst_; }
B()
{ A::instance()->foo(); }
};
B *B::inst_ new B;

BのコンストラクタでAのfooを呼んでいるが、Aが生成されてる保証は無い
このように生成順序によってはうまくいかないから

670 ：デフォルトの名無しさん：03/04/08 00:32

>>669
初回のA::instance() をコールした時、
A::instが0になってるって保証するコードすらC++では書けない、
と言うことすら暗示してますか？

671 ：670：03/04/08 00:38

あ、もしかして、
class C {
static C* c;
};
C* C::c = 0;
と
class C {
static C* c;
};
C* C::c;
って等価なのか？

672 ：デフォルトの名無しさん：03/04/08 01:09

>>670
暗示してません、それは大丈夫です
inst=new Aは実行時じゃないと初期化できないので問題となります
inst=0は実行時以前に処理できるので処理されます

>>671
どっちもNULLで初期化されることは確か

673 ：デフォルトの名無しさん：03/04/14 18:25

今、vc++ で　visitorパターンやってみたんだけど、なんか感動した。

674 ：デフォルトの名無しさん：03/04/14 18:53

俺的にビジターつうと、
ちょっと昔やってた宇宙人侵略Ｂ級ドラマの方だな。
月の裏側には・・

675 ：デフォルトの名無しさん：03/04/14 23:39

なつかしーな、おい。
値が緑なんだよな。

676 ：山崎渉：03/04/17 15:25

（＾＾）

677 ：山崎渉：03/04/20 04:32

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

678 ：デフォルトの名無しさん：03/04/23 13:10

Singletonパターンのためにこんなtemplate書いてみたんだが添削ｷﾎﾞﾝﾇ

// Singletonパターン[GoF]を使用するためのテンプレート
// これを使うときは普通にインスタンスを宣言しないで、
// グローバルでtemplate T Singleton<T>::instance = 0;を宣言した上で
// (VC++6の場合はtemplateつけちゃ駄目)
// T* t = Singleton<T>::Instance();で取得すること。

template <class T> class Singleton
{
public:
static T*Instance(void) {
if (instance_ == 0) {
instance_ = new T;
}
return instance_;
};
static voidDeleteInstance(void) {
if (instance_ != 0) {
delete instance_;
instance_ = 0;
}
};
protected:
private:
Singleton() {
};
~Singleton() {
};
static T*instance_;
};

679 ：デフォルトの名無しさん：03/04/23 13:31

1行削った

template <class T> class Singleton
{
public:
static T*Instance(void) {
if (instance_ == 0) {
instance_ = new T;
}
return instance_;
};
static voidDeleteInstance(void) {
if (instance_ != 0) {
delete instance_;
instance_ = 0;
}
};
private:
Singleton() {
};
~Singleton() {
};
static T*instance_;
};

680 ：デフォルトの名無しさん：03/04/23 13:35

>>678
Q1 どうやって使うの？
Q2 メンバを追加したい時は？
Q3 コンストラクタでなんか処理をしたい時は？
Q4 つか、これ、サブクラス作らなきゃ使い物にならんだろ。
Q5 そこんとこ、明記しとけよ。

681 ：デフォルトの名無しさん：03/04/23 13:36

>>680
Q6 Q4とQ5が質問形式でないのはなぜ？

682 ：678：03/04/23 13:52

>>680
A1:
シングルトンにしたいクラスをTとして、
template Singleton<T>::instance_ = 0;
をグローバルにおいた上で
使いたいところで
T *t=Singleton<T>::Instance();
して、あとは適当に。

A2A3:
Singleton<T>とTは独立したクラスなのでTにいくらでも追加してください。
Tのコンストラクタ、デストラクタも好きに書いてください。
A4:
んなこたあない。
A5:
ｽﾏｿ

683 ：デフォルトの名無しさん：03/04/23 20:38

シングルトンの用件を満たしてないわけだが

684 ：678：03/04/23 21:34

インスタンスが一つしかないことをちっとも保証しないからですね。

GoF本に書いてあるSingletonパターンの効果の１以外(４は要改造)を
手軽に得るための手段(シングルトンもどき)ってことで駄目ですか、駄目ですね。

685 ：デフォルトの名無しさん：03/04/24 10:57

>>684 こんな風に使うのかと思ったよ。

class Hoge : private Singleton<Hoge> {
};

Hoge* Hoge::instance = 0; // この行は、どう書けばいいのかわかんない...

686 ：デフォルトの名無しさん：03/04/24 18:14

DirectX SDKのCD3DApplicationが意味もなく信用できなかったので
自分で何日もかけてフレームワークらしいものいじくり倒して、
気がついたらCD3DApplicationとほとんど同じ形に収束していて、
はたと「そうか、これがTemplate Methodパターンか」とようやく気づく俺。勘が悪すぎです。

まあ、いろいろと勉強になったからいいや。

687 ：デフォルトの名無しさん：03/04/24 22:50

ハリウッドスタイルってやつか

688 ：デフォルトの名無しさん：03/04/25 18:21

public abstract class AbstractMovie {

public abstract void 主人公が危機にあう();
public abstract void ヒロインと出会う();
public abstract void ヒロインと恋に落ちる();
public abstract void 主人公が活躍する();
public abstract void 主人公がヒロインと喧嘩する();

public void play() {
    主人公が活躍する();
    ヒロインと出会う();
    主人公が活躍する();
    ヒロインと恋に落ちる();
    主人公が危機にあう();
    主人公がヒロインと喧嘩する();
    主人公が活躍する();
    ヒロインと恋に落ちる();
}

}

689 ：デフォルトの名無しさん：03/04/25 19:25

もうObserver.update()の名前がウンたらとか
どうでもいいだろ

690 ：デフォルトの名無しさん：03/04/26 14:23

>>689
なんかそれに付いてめっちゃ語りたがってるな。

691 ：デフォルトの名無しさん：03/04/26 20:08

>>689
俺もそう思う。
そろそろうざいな、あれ。

692 ：デフォルトの名無しさん：03/05/10 20:56

保守

693 ：デフォルトの名無しさん：03/05/18 02:20

Singletonにしようしようと思いつつ、クラス関数だけのクラスにしてしまいまふ。

694 ：デフォルトの名無しさん：03/05/18 12:28

>>693
それ最悪､Cプログラミングやってんじゃねーんだから
継承とかコンポジションとかできねーじゃん

695 ：デフォルトの名無しさん：03/05/18 12:31

> 継承とかコンポジション
いやあ、どっちもどう考えても想定できないようなクラスなもんで。

696 ：デフォルトの名無しさん：03/05/18 13:00

Monostateパターンだね。

697 ：デフォルトの名無しさん：03/05/18 13:00

>>695
じゃあnamespaceでいいじゃんって思ったが､あんたはJavaか
俺は習熟するにつれてよりクラス抽出できるようになった経験がある｡
もしかしたら問題のフレームをとらえられてないだけかもよ｡
ほんとのところはソースみないとなんとも言えんけど

698 ：デフォルトの名無しさん：03/05/18 16:03

デザインパターンって一般のプログラマにも必要な概念なの？
それともフレームワーク書く人だけ知ってればいいの？

699 ：デフォルトの名無しさん：03/05/18 16:45

デザインパターンを使ったフレームワークを使うときに必要かと。

700 ：デフォルトの名無しさん：03/05/19 02:19

>>694 どこからも使い得るユーティリティ関数を変なオブジェクトに入れたせいで、
そのオブジェクトを末端オブジェクトまで渡しつづけなければならなくなるよりよっぽどマシ。
ちなみにクラスメソッドの集合ではなく singleton にしといて良かった～と後で
思うことなんてまれ。必要になったら利ファクタリングで十分過ぎ。

701 ：r：03/05/19 02:44

>>700
シングルトンなオブジェクトを"末端オブジェクトまで渡さなきゃならない"状況ってのも
かなり異常だけどな。

# 末端オブジェクトで、インスタンス取得( XXX::getInstanceとか)すりゃいいだろ。

702 ：デフォルトの名無しさん：03/05/19 03:12

（ﾟ∀ﾟ）でもユーティリティ関数はクラス関数だけのクラスとして
外に放り出したほうが使いまわしが利いて便利だけどな。

なんでもかんでもオブジェクトにするのがいいわけじゃねーだろ。

703 ：デフォルトの名無しさん：03/05/19 06:45

>>698
他のプログラマとコミニュケーションをとる必要があるプログラマに必要。

704 ：デフォルトの名無しさん：03/05/19 06:56

>>703
H-age-Doe

705 ：デフォルトの名無しさん：03/05/23 00:57

>>703
「明日の自分は『他のプログラマ』」なニワトリ頭のプログラマにも必要。

706 ：デフォルトの名無しさん：03/05/23 01:03

>>702
言語による。
Java でそういうクラスが必要だと思ったことが無い。

707 ：デフォルトの名無しさん：03/05/23 01:06

>>706
ホントに思ったことないの？
どんなの作ってるの？

708 ：デフォルトの名無しさん：03/05/23 01:18

Math とかそうじゃないの？

709 ：デフォルトの名無しさん：03/05/25 01:52

>>707
俺は706じゃないけど、俺も必要性をほとんど感じない。
計算関係とかは十分にそろってるしね（Math.class）。

あらゆる処理は誰か(A)がトリガーになって誰か(B)が実行するわけだけど、
AもBもオブジェクトになるからにはそれらが実装すべきだと思う。
静的なクラスを最近作ったのはRobocodeで遊んだ時かな？

ただし、静的クラスを作ることは否定的ではないし、必要が出てくれば
迷わず作るよ。分野によっては結構必要になりそうだし。。

710 ：デフォルトの名無しさん：03/05/25 08:13

文字列操作とかいちいちつくるのか？
replaceとか単純な奴は普通ユーティリティでまとめるべ。

711 ：デフォルトの名無しさん：03/05/25 08:17

>>710
あほか。普通は文字列クラスのメンバにするだろうが。

712 ：デフォルトの名無しさん：03/05/25 08:28

>>711
String#replaceAll()はJDK1.3以前にはなかったのですよん。
なんでなのでしょうかねえ。

713 ：デフォルトの名無しさん：03/05/25 11:12

ユーティリティは普通に使うよ

俺は適度にオブジェクト、粒度が細かくなりすぎるようだったら
ユーティリティで分けてるけどなぁ。

それなりの人数が集まるプロジェクトだと、粒度を細かくしすぎると地獄。

小規模だったら理想どおりいける事も多いガナー

714 ：デフォルトの名無しさん：03/05/25 11:15

>>711
普通に文字列操作用のユーティリティクラスって意味だったんだが…
※コンストラクタをprivateにして、後はstaticね

いちいちアンタはプロジェクト毎に文字列クラスを作るのか？

715 ：709：03/05/26 01:57

文字列操作に関しては自作ライブラリでがっつり作ってたよ、俺も。

716 ：山崎渉：03/05/28 12:45

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

717 ：デフォルトの名無しさん：03/06/08 23:09

718 ：_：03/06/08 23:09

http://kame.kakiko.com/hiroyuki/hankaku_b01.html

719 ：デフォルトの名無しさん：03/06/16 12:32

　　　　　　　　,,,,,..,,.,.,,,
　　　三　　　ﾐ,,　・д・ﾐ　　＜　ﾎｯｼｭﾎｯｼｭ!!
　　三　　　　ﾐ,,,,,,,.,,.,.,,,ﾐ　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　三　　　　　 (　・∀・∩　＜　それ今だ!!　ホシュ━━━━━!!!!
　　三　　　　 ( つ　　丿　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　三　　　（　ヽノ
　　　　三　　し（＿）

720 ：デフォルトの名無しさん：03/06/16 12:32

age忘れ

721 ：デフォルトの名無しさん：03/06/28 13:21

>>604-606のどこをどう読んだら「Interpreterっぽい」って言えるのかと
>>607を問い詰めたいが、遅すぎか・・・

722 ：デフォルトの名無しさん：03/06/28 18:06

結城さん、最近神様にはまってるみたいですね。
中級プログラマにとっての神様が、神様（ほんもの）にはまってるのは
なんというか、結構びっくり。プロテスタントの方なんかな。

デザインパターンでいうと「神様」はなんだろうな。
ていうかパターンの外ってことでJavaでいうなら神＝VM？

723 ：デフォルトの名無しさん：03/06/28 21:10

最近というより昔からクリスチャンじゃないんですかあの方は？

724 ：デフォルトの名無しさん：03/06/28 21:15

>>723
マジレスすんなよ。

725 ：デフォルトの名無しさん：03/07/02 01:28

GoF本を最近買ってきて勉強中なんですが、質問です。

Singletonパターンでの実装例のことなんですが、
例のこのままでは、インスタンスがdeleteされませんよね。

class Singleton{
public:
　static void Delete();
};

void Singleton::Delete(){
　if(_instance==0) delete _instance;
}

こんな感じのを加えたらいいんですか？

726 ：デフォルトの名無しさん：03/07/02 01:42

>>725
Singletonのインスタンスはたいてい明示的に削除する必要がないから、
GoF本にはインスタンスの削除について触れてないんだと思う。
GoF本の例だと、Singletonパターンの使いどころとして
Abstract FactoryやBuilderの実装を挙げているけど、
こういった例ではインスタンスを削除する必要がない。
もちろん、あなたがSingletonのインスタンスを削除したくてたまらない
理由があるのならそうすればいいけど、多くのケースでは不要でしょう。

727 ：デフォルトの名無しさん：03/07/02 08:28

必要性ってよりも、インスタンス数を0にするメソッドを
Singletonは公開したりしないと思うんだがね。

728 ：デフォルトの名無しさん：03/07/03 03:12

デザインパターンって「ものなき関係論」？

729 ：デフォルトの名無しさん：03/07/03 07:15

>>20
大体そんなもんです。
複数実装されたFactoryのエントリポイントをひとつにして集約しようという試みです。
個人的にはこれがデザインパターンに入っているのが不思議なのですが・・・。

730 ：r：03/07/04 11:22

>>729
...2年越し...

731 ：デフォルトの名無しさん：03/07/04 17:23

>>20 = >>729
ｼﾞｻｸｼﾞｴﾝ

732 ：デフォルトの名無しさん：03/07/04 17:29

>>725
そういう実装だとバグの元になりそう。
まだインスタンスを参照してるところがあるのに、うっかり削除してしまうとか。

733 ：デフォルトの名無しさん：03/07/04 19:44

>>725
たとえば、シングルトンとはいえ明示的にnew/deleteするような実装なら
コンストラクタで最初の一回だけポコッと作って2回目以降は再利用て、
デストラクタではカウンタがゼロになるまでは消さないとか。
まーいらんけどね。

734 ：デフォルトの名無しさん：03/07/04 23:32

デザパタなんか要らないとずっと思っていたが、最近デザパタが重要な理由が分ったよ、
構造化プログラミングもできないおバカがオブジェクト指向を始めてスパゲッティープログラムを作ると
そのスパゲッティ度合いは構造化プログラミング系言語の比ではなくなるんだな
それでチームリーダーやってんじゃねぇ、うぁぁぁぁもうマジで勘弁してくれよぉ

735 ：デフォルトの名無しさん：03/07/05 00:34

>>725
「シングルトンのインスタンスを作ったは良いけど、削除されない」のが心配なら、
Modern C++ Designに載ってるローカルstatic変数を使ったシングルトンは？

736 ：デフォルトの名無しさん：03/07/05 04:40

>>734
偉くなって直接言ってやれ。

737 ：725：03/07/05 05:39

あれからもうちょっと読み進めてみました。そうしたら、ヒントが載ってました。次のようにしたら明示的な削除がいらないように思いました。
デザインパターンって読めばすぐ使えるものでもないようですね。いろいろなパターンが相互に絡み合っていて難しい・・・。
>>735
それは読んだことないです。今度立ち読みしてみます。
class Singleton{
private:
　class SingletonPtr{
　private:
　　Singleton* p_;
　public:
　　SingletonPtr(Singleton* p):p_(p){}
　　~SingletonPtr(){if(p_!=NULL) delete p_;}
　　operator Singleton*(){return p_;}
　　SingletonPtr& operator =(Singleton* p){p_=p;return *this;}
　};
　static SingletonPtr pInstance;
protected:
　Singleton(){}
public:
　~Singleton(){}
　static Singleton* Instance();
};

Singleton::SingletonPtr Singleton::pInstance=Singleton::SingletonPtr(NULL);

Singleton* Singleton::Instance(){
　if(pInstance==NULL) pInstance=new Singleton;
　return pInstance;
}

738 ：735：03/07/05 22:05

>>737 基本的にはこんな感じで。
Singletonのインスタンスは、最初のSingleton::Instance()呼び出し時に生成されて、
main()からreturnした後（またはexit()したとき）に自動的に破棄されます。

class Singleton {
  static Singleton* Instance();
};

Singleton* Singleton::Instance()
{
  static Singleton theInstance;
  return &theInstance;
}

"Modern C++ Design"には、これを改良したPhoenix-Singletonの話なども載っていて、
結構面白いです。
main()からreturnしたあとにもSingletonのインスタンスが必要になる可能性がある場合
（例えば、他のstaticオブジェクトのデストラクタや、at_exit()に登録された処理の中で
Singletonのインスタンスが必要になる場合）、上記では対処できませんが、
Phoenix-Singletonなら対処できます。

739 ：デフォルトの名無しさん：03/07/06 15:29

なんかデザパタってよりイディオムの話になってるけど、>>17で>>1が
「パターンを全般的に扱うスレ」って遺言してるし、OKなんだね。

740 ：デフォルトの名無しさん：03/07/07 12:22

今のとこ、「Singletonパターンを実現するためのC++のイディオム」だし、
広い意味でデザパタの話ってことで。

741 ：デフォルトの名無しさん：03/07/15 00:46

「読書百遍意自ずから通ず」
これを「GoF本のパターン」と呼ぶ。

742 ：山崎渉：03/07/15 10:04

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

743 ：山崎渉：03/07/15 14:30

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

744 ：デフォルトの名無しさん：03/07/24 12:35

質問お願いします。GoF本にあるMementoとCommandの組み合わせ(P308-)をみて、
これは素晴らしいと自分でもやってみたのですが…。

例えばGoF本のように、図形オブジェクトを移動する様な場合、
実際にはマウス等で図形の移動操作をしている最中も、座標は変わりまくってると思うんです。
移動開始点から、終了点へ、Command->Execute()で一発…というイメージにはならないな、と。

この辺はやはり、多少汚くなっても妥協するしかないのでしょうか？

745 ：　：03/07/24 13:10

>>735

　それだと静的変数のデストラクタからシングルトンオブジェクトを
安全に使えないよ。。シングルトンオブジェクトの寿命が何時尽きる
べきか、というのはケースバイケースだから、あまりデザインパターン
っぽい話とはなじまないような気がする。

746 ：_：03/07/24 13:17

http://homepage.mac.com/hiroyuki44/hankaku06.html

747 ：735：03/07/24 15:23

>>745
それを安全にするのが>>738で書いたPhoenix Singletonらしいのだけど、
結局自分では使ったこと無い。

748 ：744：03/07/24 20:05

すいません、一度だけ渾身のage

749 ：デフォルトの名無しさん：03/07/25 02:52

>>744
渾身のageで気付いたよん。
汚く妥協するって、具体的にどうすることを指してる？

図形の移動操作中にずっとMoveCommandが発行されるわけではないよ。
GoF本Mementパターンの例は、
コマンドの実行が確定した時点でCommandオブジェクトが生成されて、
そのときの差分がMementとして作られることを示している。

たとえば、平面上のShapeを次のように動かすとする。
初期状態：(1, 1)
[1] (1,1) → (2, 3) に移動させる
[2] (2, 3) → (3, 1) に移動させる

[1] や [2] の操作中にShapeをドラッグしているときは、移動は確定していない。
アプリは、グラフィカルに何らかの描画をしていることだろう。

[1] が確定した時点で MoveCommand を生成する。
移動開始点と移動先の差分から移動量(1, 2)というMementオブジェクトを作り、
MoveCommand にインスタンス変数としてセットする。
(おそらくこのMoveCommandオブジェクトは、何らかのCommandキューに入れられることになる)
[2] が確定した時点では、同様にして移動量(1, -2)のMementをもつMoveCommandが作られる。

サンプルコードのようにすれば、きれいにRedo/Undoを実装できる。

750 ：749：03/07/25 02:58

このmementに座標だけじゃなくConstraintSolver の復元に必要な情報も添えてあげれば、
Undo/Redoの中で、関連する情報も提供してあげられる。

751 ：744：03/07/25 20:33

>>749
遅レスですいません、昨日はずっとネットに張り付いてたのですが…。
偽Shapeを作って操作はそっちにしたり、あるいは全ての状態を逐一、保存してみたりと
今日一日とんでもないことをやっていました＞汚く妥協

本当に丁寧な説明で、私にもようやく理解することができました。
確定時点でCommand生成すれば良いんですね。しかも生成された時点で
全ての情報が既に固まってるから、扱いもすごい容易で…。

Undoどころか、Redo（←考えてませんでした）も楽々ですねぇ…。
いやはや、感謝してもし足りません。ありがとうございました。

752 ：デフォルトの名無しさん：03/07/27 21:57

>>198
> >>197
> そういえば、StateとStrategyの違いってよくわからん。

State の別名が Strategy だと思っとけ。

753 ：デフォルトの名無しさん：03/07/29 01:11

>>752
漏れはStrategy自身が新しい他のStrategyを作るのがStateだと思ってる。

754 ：デフォルトの名無しさん：03/07/30 06:46

>>753
StrategyはPlayerアルゴリズムを動的にごっそり取り替えるパターンです。
TemplateMethodも似たようにアルゴリズムの切り替えを実現しますが、こちらは静的です。
Stateは状態をタイプコードではなくクラスそのものであらわすパターンです。
アルゴリズムの切り替えは行いません。

755 ：デフォルトの名無しさん：03/07/30 23:33

いわゆるＦｌｙWeightパターンを日本語処理に適用したいのですが
(テキスト中に現れる日本語一文字づつをオブジェクトとして扱いたい)
英語圏の人たちと違ってやるメリットは無いですかね？
結局参照用のFlyWeightPoolが膨大になって意味がない気もするんですが

756 ：無料動画直リン：03/07/30 23:38

http://homepage.mac.com/miku24/

757 ：デフォルトの名無しさん：03/08/01 06:14

>>755
そんなこたないんじゃないですか。使いそうな文字なんか結構決まっているような気もしますし。
ただメモリリークしないためにも、Poolできる最大文字数を決めておくのがよいかと。

758 ：山崎渉：03/08/02 02:06

（＾＾）

759 ：デフォルトの名無しさん：03/08/03 16:15

無駄です（＾＾）。

760 ：デフォルトの名無しさん：03/08/05 22:04

質問です

売り上げ集計表示。このとき最初にDBからメモリに展開してメモリから表示
させる。

DB構造としては
支社＞部署＞個人
という風になっていて（個人ごとに売り上げ額もってます）

支社別に表示、部署別に表示、支社別部署別に表示
させる場合（表示条件切り替え可能）
メモリに展開させるのに有効なパターンてありますか？
もし無いのであればどのようなメモリ展開でおこなえるでしょうか？
言語はJavaです

761 ：デフォルトの名無しさん：03/08/05 23:54

検索条件をStrategyパターン？

762 ：デフォルトの名無しさん：03/08/06 01:02

>>760
Compositeパターンによるツリー構造が基本？

データ量が多くてメモリ上限があるなら、弱参照によるキャッシュが有効かもな。
パターンと関係無いが。

763 ：デフォルトの名無しさん：03/08/06 01:37

>弱参照によるキャッシュが有効かもな。
>パターンと関係無いが。
Proxyか複数インスタンスのSingletonと言えなくもないかな。

764 ：山崎渉：03/08/15 15:58

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

765 ：デフォルトの名無しさん：03/08/20 20:05

豆蔵社員によるかなり大きなファイルサイズの PDF 添付メールは何かの嫌がらせですか？

766 ：デフォルトの名無しさん：03/08/21 05:51

静かな余生を送っていたこのスレに意味不明な質問を書き込んだのは何かの嫌がらせですか？

767 ：デフォルトの名無しさん：03/08/24 16:28

コーディネータはこーでねーと

768 ：デフォルトの名無しさん：03/08/24 22:58

752番は危険。あげるにょ。

769 ：デフォルトの名無しさん：03/08/24 23:13

>>765
MLに流れてきたのは驚きました。新手のウイルスかと思ったよ。

770 ：デフォルトの名無しさん：03/08/25 00:32

http://hv.ws37.arena.ne.jp/swf/mother.swf

771 ：デフォルトの名無しさん：03/09/03 14:47

Undo機能を搭載しようと、Command&Mementoを採用したのですが、
全てのコマンドに対して膨大なCommandのサブクラス群が…。

テンプレートも使えないし…こ、こんなもんですよね？ちょっと不安が…。

772 ：デフォルトの名無しさん：03/09/03 15:07

>>771
全てのサブクラスで処理手続きを分岐する必要がなければ、クラスは
処理の流れごとで纏めて、パラメータはコンパイルの必要のない外部
ファイル(XMLなど)に定義するとか。

どうせ定義情報は増えるけどさ。

773 ：デフォルトの名無しさん：03/09/03 16:12

>>772
レスを参考に再検討していました。
パラメータ化により、かなりの部分をまとめることができそうです。
ありがとうございました。

774 ：デフォルトの名無しさん：03/09/03 16:25

Commandパターンまだ使ったことないけど、自分がやるとしたら
パラメータ化のところでStateパターンの併用も考える気がしる。

775 ：デフォルトの名無しさん：03/09/03 16:41

教科書にあるStateの使い方とは違うのかも知れないけど、
でかいクラスのごく一部だけ違う派生クラスをたくさん作る必要
が出てきた場合、その「ごく一部」だけを別クラスにしてState
にするのは好き。

でかいクラスのツリーが広がる代わりに、その小さいState
の方のクラスのツリーが広がって行く感じ。
Command でなく CommandType みたいな。

776 ：デフォルトの名無しさん：03/09/03 17:11

ダブル(またはそれ以上)ディスパッチをどう実装するかは、永遠の課題ですの。

777 ：デフォルトの名無しさん：03/09/03 20:14

なんかいいdizpatない

778 ：デフォルトの名無しさん：03/09/06 03:49

もう文字コードはやめてくれ。。。。

779 ：デフォルトの名無しさん：03/09/14 15:07

Singletonとメンバ全部staticにするのとはどう違うのですか？

780 ：デフォルトの名無しさん：03/09/14 15:21

>>779
意味なんてね――！！
スカッとするからしてるだけなんだよこのボケ――！！

というのはうそ。
同期処理とか、後から拡張とか継承とかが
追加できたりするから。
あとあと使いまわしが効くように出来てんのよ。

781 ：デフォルトの名無しさん：03/09/14 15:52

>>779
要するに、いつ（どのタイミングで）コンストラクタを走らせるかをコントロールしたい場合、
Singletonのパターンを使用しなきゃならない。
そうでなけりゃ、staticでも構わないよ。

782 ：デフォルトの名無しさん：03/09/15 21:21

Martin Fowlerの"P of EAA"の中で紹介されている Metadata Mapping
ttp://martinfowler.com/eaaCatalog/metadataMapping.html
のコード例はどこかにない？
できれば
ttp://martinfowler.com/articles/dblogic.html
のようにRubyで。

783 ：デフォルトの名無しさん：03/09/19 05:54

リアルタイムのシミュレーションゲームを考えます。
「ユニット」クラスを継承した「車両」「航空機」「艦船」クラスなどがあるとします。
各ユニットのインスタンスは他のユニットの位置・所属軍などのフィールドを認識して
行動する必要があるわけですが、これにはObserverパターンを使えば良いのでしょうか？
ユニットが増えると負荷が級数的に上がりそうですが・・・。

784 ：デフォルトの名無しさん：03/09/19 07:42

>>783
そこはMediatorの方がいいんじゃないかな。
全ユニットは司令部を経由して友軍の情報を得る、って感じ。
RMA以前の軍隊の乗りで。

785 ：783：03/09/19 21:06

>>784
なるほど、有難う御座います。
参考書片手にパターンを組んでみたいと思います。

786 ：デフォルトの名無しさん：03/09/20 19:08

非オブジェクト志向の言語にGoFのデザインパターンって適用できないの？

787 ：デフォルトの名無しさん：03/09/20 19:12

>>786
志向じゃなくて指向。んで、適用できます。

788 ：デフォルトの名無しさん：03/09/27 04:17

デザインパターンを学ぶとオブジェクト指向の現実を分析するという方向から外れてきた気がする…。

789 ：デフォルトの名無しさん：03/09/27 18:18

>>788
そのとおり
デザパタは、中毒性の高い変態コーディング・テクニック集
使いすぎは禁物

790 ：デフォルトの名無しさん：03/09/28 03:00

>>789
なるほど。気をつけます。

791 ：デフォルトの名無しさん：03/10/15 23:52

ｆｒｏｎｔｃｏｎｔｒｏｌｌｅｒパターンを適用しすぎるのは実際のとこどうなんですか？

792 ：デフォルトの名無しさん：03/10/16 01:22

HotSpot と FrozenSpot を分ける意味では素晴らしい。

793 ：デフォルトの名無しさん：03/10/22 02:56

Observerって、じっと観察しているのかと思ってたけど、
読んでみたら、どうやら「何かあったら起こしてね」と
さっさと寝てしまうように感じたのですが、そんな解釈で
いいのでしょうか？

なにか他にいい別名とかついているのでしょうか？

794 ：デフォルトの名無しさん：03/10/22 04:32

>>793
Publish-Subscribe

795 ：793：03/10/23 05:49

>>794
そんな別名があるのですか…

ところで俺の解釈はあってますか？

796 ：U ◆CZtFsGiu0c ：03/10/23 15:41

>>793
その解釈でいいと思います。メタファとしては「観察者」だけど、実装上は
対象のオブジェクトに通知してもらう形でないと難しいからです。

797 ：デフォルトの名無しさん：03/10/23 16:52

名前通りに実装すると…一つのSubjectを複数のObserverが所持
一定周期毎にObserverがSubjectを参照ってとこか…。

あまりスマートじゃないね。ネットプルグラムなんかじゃありそうだけど。無いか。

798 ：デフォルトの名無しさん：03/10/23 20:02

別スレッドでHTTPGetして、
メインスレッドからGetの進行状況表示及び、取得済みの部分の表示を行う場合、
どういうパターンにするのが適切ですか？

799 ：793：03/10/24 06:01

回答ありがとうございます。

他のパターン名は、いろいろと変更があったものもあるとか
いうけど(6.2経緯)、Observerというパターン名には
そういう動きはなかったのかな

800 ：デフォルトの名無しさん：03/10/26 13:28

>>798
>>794

801 ：デフォルトの名無しさん：03/10/26 22:51

まだ半分ぐらいしかパターン勉強してないけど、どれもこれも同じようなもの
に見えてしまいます。

インターフェイスや抽象クラス使って多用性にしとけばパターンなんて
覚えなくてｲｲや！と思ってしまった僕は粛清されるべきですか？

802 ：デフォルトの名無しさん：03/10/26 23:00

>>801
せっかく勉強するなら、違いが分かる程度までは
理解しておいて損は無いでしょうな。

803 ：デフォルトの名無しさん：03/10/29 11:18

IEのお気に入りやネットスケープのブックマークのようなデータ構造に、
Compositeパターンを使いました。
そこまではいいんですが、このデータ構造をViewクラスに表示する時にはどうすればいいですか？
Viewクラスに色々処理を書けばいいんですか？
それとも、Mediatorとかいうパターン使えば良いんですか？
それとも、他にもっと良い方法がありますか？

804 ：デフォルトの名無しさん：03/10/29 13:48

>803
Visitor+Commandかな？
規模によっては単純に、各Compositeに処理を書いてもいいかも。

805 ：デフォルトの名無しさん：03/10/29 23:09

＞規模によっては単純に、各Compositeに処理を書いてもいいかも。

描画処理とモデルを厳密に切り分ける必要がなければ、これが良いな。
GoFの例もそうなってる。

＞Visitor+Commandかな？

Visitorと言うと、CompositeのComponentクラスとVisitorのElementクラスを
対応付るってことか。だがここでマルチディスパッチなんて必要かな？
YAGNIという言葉もあるわけだが。

Componentに描画メソッドを書けないなら、ここは型情報使ってもいいのでは？
各Component派生クラス用に応じた描画メソッドと、それらの描画メソッドと
Componentの実型を対応付けるテーブルを、外部のutilityクラスか何かに
用意して置くとかさ。Visitor使うにしても、実型に応じた書き分けはどうせ
必要なんだし。

グラフィカルな描画だけじゃなく文字列でのトレースも同じ仕組みでやりたい
といった新しい要件が出てきたら、そこでおもむろにVisitorにリファクタリング
すれば良いわけでさ。ま、リファクタリング禁止なら仕方ないかもしらんが。

あと、なんでCommandなのか分からなかった。

806 ：デフォルトの名無しさん：03/10/30 20:42

>>803
javaだったらinstanceofと再帰で十分。ダブルディスパッチはあんましお勧めしない。

807 ：デフォルトの名無しさん：03/11/05 15:52

インターナルイテレータを、
コマンドパターンを使って実現しようと思うんですけど、
漏れは変態ですか？

コンテナに対してコマンドを投げる。
コンテナは、全要素に対して command.Execute( 要素 ) を実行する...

808 ：デフォルトの名無しさん：03/11/05 18:34

>>807
だからそれがダブルディスパッチだっちゅーの。

809 ：デフォルトの名無しさん：03/11/05 18:57

>>808
ダブルなの?

810 ：デフォルトの名無しさん：03/11/05 19:02

二重殺?

811 ：デフォルトの名無しさん：03/11/05 22:12

>>807
それはベストプラクティスパターンのEnumeration Method。

812 ：デフォルトの名無しさん：03/11/05 23:52

ちげーよ、お前らマジヤベーよ

813 ：デフォルトの名無しさん：03/11/05 23:56

Singletonの意味、必要性が最近マジわかんね
Monostateで十分じゃねーか！

814 ：デフォルトの名無しさん：03/11/06 09:43

ストラテジーやステートみたいに、そのオブジェクト自身がコンテキストを持たないでいいとき、

815 ：デフォルトの名無しさん：03/11/06 13:45

>>813
Singletonなら複数の状態を持たせる事も出来るし、
非Singletonなオブジェクトとinterfaceを共有できる。
他にも利点はあるかもしれないが、
とりあえずMonostateはOOらしくないと思う。

816 ：デフォルトの名無しさん：03/11/07 01:39

Singletonの利点って、インスタンスの数を管理できることだよね？
大抵「プロセス全体で1個」でつかうみたいだけどさ。

「どこからでも簡単なパス指定でアクセスできること」は、「Single
tonの利点」ではないよね。グローバル変数の利点ですよ、それ。

817 ：デフォルトの名無しさん：03/11/08 23:49

ストリームから派生クラスのオブジェクトを読み込む場合にFactory Method
パターン使いますか？生成すべきオブジェクトのタイプ番号をストリーム
から読み込んでswitch文で切り替えて対応するコンストラクタを呼び出した
方が簡単だと思うのですが。

Product番号(タイプ番号)を与えるとそれに応じたProductを生成できる、
といってもproduct番号と対応するコンストラクタの呼び出しを事前に
登録しておかなければならないし、ましてやそのために関数ポインタまで
使うとなると、かえって問題を難しくしているように思えてならないのです。

818 ：デフォルトの名無しさん：03/11/09 00:32

817です。

やっぱりFactory Methodの理解が変ですね。逝ってきます。
でも、switch文でコンストラクタの呼び出しを切り替えた方が
簡単だと思うけどなぁ。

819 ：デフォルトの名無しさん：03/11/09 01:28

>>816
あとはあれだ
あれ

アトミックな参照・変更を保証したいときとか
えーと
うｓｐ

820 ：デフォルトの名無しさん：03/11/09 02:32

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　ほう、Singletonﾊﾟﾀｰﾝですか？
＼
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　な、なんですか？あなた・・・
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿__
￣￣￣日∇￣＼|ThinkPad|＼
　　　　　￣　　　=========　＼

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　・・・それって、全部 static にして
|　ユーティリィティクラスにしたほうが早くないですか？
＼
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　・・・・・・
　（　　　　）　 (；ﾟДﾟ)　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿__
￣￣￣日∇￣＼|ThinkPad|＼
　　　　　￣　　　=========　＼

821 ：デフォルトの名無しさん：03/11/09 03:27

>>817
Factory Method うんぬんより、switch/case と関数テーブルの違いだけになってない？
とりあえず種類が少なかったり、一度タイプ番号とオブジェクトの関係を決めたら変わらない
というのなら switch/case でもいいだろうけど、タイプ番号が追加される度に判断ロジックを
追加するのはあまりきれいじゃないと思う。

822 ：デフォルトの名無しさん：03/11/09 13:55

全部staticにしてユーティリティクラスにするのと、
namespaceに閉じこめるのは何が違うの？

823 ：デフォルトの名無しさん：03/11/09 14:32

>>817
>>821
ええと、こういう感じじゃいかんの？

public class SuperFactory {
static final HashMap factories;

static {
factories.put( Subfactory01.TypeID, SubFactory01.getInstance() );
factories.put( Subfactory02.TypeID, SubFactory02.getInstance() );
...
};

public SuperProduct load( InputStream stream ) {
SperProduct superproduct;

... 共通部読み込み処理 ...

SuperFsctory fact = factorues.get( superproduct.ProductTypeID );
fact.load( stream );

}

}

824 ：デフォルトの名無しさん：03/11/10 00:51

すごーく厨な質問かもしれないですけど

ビジターパターンみたいにデータと処理を分離するためのパターン
ってOOでよく言われてる「オブジェクトとは、状態と振る舞いをもつ」
みたいなことに反してるような気がするんですけど、私の捉え方が
間違ってるだけですかね？

825 ：デフォルトの名無しさん：03/11/10 02:35

>>824
オブジェクトの中にデータと処理が含まれていて
複数のオブジェクトのデータがそれぞれ微妙に違っているからといって
その微妙に異なるデータに特化した処理をわざわざ新しく用意しません

データと処理を全く分けていない状態と
分けた上でその二者をオブジェクトの中に抱えるのとでは
データや処理の再利用性が違います。
処理と一体化されたデータはその処理にしか使えないため
汎用性の無いデータですし、
逆にデータと一体化された処理はそのデータでしか使えないため
汎用性の無い処理となります。
まず分けて、そのあと組み合わせればそのデータや処理は他でも使えます。

class Person//変な例ですが
{
char*name;
double height;
public:
double get_height()const...
...
};
Person a("taro",180);
Person b("jiro",170);
Person c("saburo",165);

a,b,cのオブジェクトはオブジェクトの中にデータと処理を抱えます。
しかしデータと処理(メンバー変数とメソッド)が分かれているため
各オブジェクトの値が変わっていても処理は共通化できます。

826 ：デフォルトの名無しさん：03/11/10 19:21

頼みごとです。
GoF以外にももっとデザインパターンについて知りたいのです。

もっとデザインパターン、アーキテクチャパターンのサイトを教えてください。

827 ：デフォルトの名無しさん：03/11/10 20:15

資格試験でデザパタ必須なのってなんかありますか？

828 ：デフォルトの名無しさん：03/11/10 21:12

UML のシルバー以上は確か要ったのでは・・・。

829 ：デフォルトの名無しさん：03/11/10 22:20

亀レスすみません。

>>821
>switch/case と関数テーブルの違いだけになってない？

確かに、Factory Methodパターンの話とは別の問題かも。

>>823
プロトタイプコードありがとうございます。まだ完全にわかってませんが、
コードの意味を考えてみます。

言い訳ですけど、

デザインパターンってGoFって孫子、呉氏の兵法書みたいです。

実戦を踏んでいる人には｢あっ、これはあのこと言ってるんだ！｣
と理解できるだろうけど、実戦を踏んでない人間にはピンと来ないのです。

830 ：デフォルトの名無しさん：03/11/11 00:25

>>826
本買え、海外のサイトもググれ

831 ：デフォルトの名無しさん：03/11/11 03:05

デザインパターンはどれくらい普及しているのか？

マ板をみるとデザインパターンの話をしても
プライドが傷ついたかのようにデザインパターンを嫌い、「遅い」などといってばかりなレスが目立ち、
普及して無いかのように見える。

日本ではオブジェクト指向を否定する香具師が多いくらいだから
デザインパターンの普及率はかなり低い？

そこで、デザインパターンを普及させるにはどうすればいいだろう。

もしかすると、多くの人は、既存のプロジェクトにデザインパターンが使えないと思い込んでいるかもしれない。
とりあえずかれらにAdapterパターンを説明すべき？

832 ：デフォルトの名無しさん：03/11/11 10:27

つうか、java に関して言えば、標準APIにそもそも
デザパタが多用されてるし、
EJB なんてデザインパターンの塊みたいなもんだし、
オブジェクト指向の言語はいずれにしろそういう形になっていくでしょう。

で、個別業務アプリだけ作ってる末端のプログラマーは、
わけも分からず、APIやフレームワークの仕様にあわせて作ってると。
それでも、APIやフレームワークの設計がよければ、システム全体としては、
デザパタ活用してることになる。

833 ：デフォルトの名無しさん：03/11/11 12:21

>>831
oo否定派デザパタ否定派はそれで設計するのに
時間がかかる人なんだよな。

慣れるには意欲がないとだめでしょ。諦めたり理解しようとしない人に
推し進めても効果ないと思うな

普及させるにはやっぱり個々の意識改革から変えていかないとねー

# 使いこなせてない人間が自分のスキル棚に上げて
# ぐだぐだ言うのはどうにかならんかね

834 ：デフォルトの名無しさん：03/11/11 21:52

デザインパターンをデザパタなんていう奴でデザインパターンを理解できている奴はいない

835 ：デフォルトの名無しさん：03/11/11 21:57

834はインパタ派

836 ：デフォルトの名無しさん：03/11/11 23:11

デザインパターンってのは勉強したらプログラムが早くなるってものではなくて、
こう来たら、こうするってのが脊髄反射的に作れるようになったら早く作れる物だと思うんだけどね。
習うより馴れろの典型だと思うんだけど。
自分はGoF以外のパターンは直感あるのみ、このパターンは良いものだって感じたらソレだってメモメモしてます。

#最近そこそこデザパタが使えるようになって思う事は
#勉強勉強って言っている奴にデザインパターンがまともに使える奴は居ない。
#どういう訳だか、設計設計って言っている奴にもデザインパターンがまともに使える奴は居ない。(藁

837 ：デフォルトの名無しさん：03/11/11 23:34

世に、生兵法は大疵のモトって言うしね。

838 ：デフォルトの名無しさん：03/11/12 00:09

結局ガリガリコーディングして、いろんな苦労をしないと、
ありがたさは肌身でわからんのよ。

839 ：デフォルトの名無しさん：03/11/12 00:52

C言語を使ってかなり苦労したのでデザインパターンを
その苦労を最小限におさえるために
多くのプログラマに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

デザインパターンを使うことがプログラマの習慣、常識になってほしい。

なんとか、デザインパターン文化を押し広げられたら・・・。

840 ：デフォルトの名無しさん：03/11/12 01:00

>>839
デザパタってそんなモンじゃねぇだろうとか思ったりもする
構造化プログラミングだって、ある種のパターンらしき物はあるし、
苦労したというなら、貴方の能力不足がたまたまOOのデザパタで解決しただけだよ
ついでに言うと、そんな事やったら嫌われるよ

841 ：デフォルトの名無しさん：03/11/12 01:08

C言語とデザインパターンって比べられるものなのか？

842 ：デフォルトの名無しさん：03/11/12 01:13

>>839
C 言語の不便さはあるけど、その不便さとデザインパターンの便利さというのは
かなり方向性が違うと思う。

C のイヤナ点は STL とか Java とか後発のスクリプト言語がうまく解決してくれていることだと思うし。

「C で苦労したからデザインパターンで、、、」といわれると「？？？」と思ってしまう。

843 ：デフォルトの名無しさん：03/11/12 01:31

>>841
英語と俳句を比べるようなものだな。

844 ：デフォルトの名無しさん：03/11/12 05:35

いっぺんウィジェットのセットを書いてみれば
GoFのパターンくらいすぐ頭に叩き込める

845 ：デフォルトの名無しさん：03/11/12 07:21

>>844
うん、うん、そう。

思うに、GOFでもなんでも、読んでみて、「こんなやり方があるのか」
じゃなくて、
「このやり方は、こう整理すれば ooの特性を生かして、スマートに実現できるのか」
「このやり方はこうういう名前で呼べばいいのか」
というのが、本当にわかったってことのような気がする。

真面目な話、C言語でやってたことを oo で実現するにはどうすればいいか、
という意味で参考になったことが多い。
で、C言語でやってたときは、「懲りすぎだ」、「意味がわからん」といわれてた事を、
「これはこれこれのパターンで・・・」といえるようになっただけでも、
かなりの進歩。
これは、C言語そのものの仕様の問題ではなくて、時期の問題
（デザインパターンが世にでてなく、Cが全盛だった）、
今なら、デザインパターンを C言語に適用して書くということもできなくはない
（まあ、今やるなら少なくとも C++ だけど。）。
そういう意味なら、
>>839
はわかる。

846 ：デフォルトの名無しさん：03/11/14 08:47

デザインパターンを齧り始めた物ですが、的外れかもしれないけど
アルゴリズムとデザインパターンの関係ってどんな感じ？

847 ：デフォルトの名無しさん：03/11/14 09:54

>>846
まずは
Google「アルゴリズム　デザインパターン　違い」
で調べてみてはいかがか。

848 ：デフォルトの名無しさん：03/11/14 14:09

TemplateMethodではスーパークラスがサブクラスの挙動をコントロールしますよね？
BuilderではDirectorクラスがBuilderクラスの挙動をコントロールしますが、
Builderクラスでも同じように実現することは出来ないんですか？
どうして他のクラスにコントロールさせるんでしょうか？

849 ：デフォルトの名無しさん：03/11/14 19:46

>>846
たとえば、 C言語の　qsort() 関数ありますよね。

で、qsort で並び替えに使われてる「アルゴリズム」が「クイックソート」。

ここで、qsort()関数の仕様を単純に、並び替えをしたい配列を渡す形式例えば、

void qsort( int *data )

とかにしてしまうと、ソートできるデータ形式や、ソートキー、ソートキーの評価基準などが、
一種類しかえらべなくなってしまう。
あるいは、

void qsortInt( int *data )
void qsortString( char **data )

のように、データ種別ごとに（アルゴリズムは同じなのに）別の関数にしなければならなくなる。

しかし、実際の qsort() の実装はこれをうまく扱えるようにしている。
こういった実装上の「うまいやり方」がパターンなんではないかと。

850 ：デフォルトの名無しさん：03/11/14 20:47

>>846
アルゴリズムはある種の問題に対する解法の事です。
で、沢山アルゴリズムを作ると、幾つかのアルゴリズムがよく似た構造をしている事がないかい？
その良く似た構造だけを取り出してきて、整理したものがデザインパターンって奴。
アルゴリズムに限らずプログラム中何度も出てくる構造を抜き出したものです。

>>848
とりあえず何も考えずに、実装しやすそうなパターンの方でプログラムすればいいです。
問題がでたとき、もういっぺん別のパターンの方が良くなかったか考え直してみればいいんです。
何回か書いていると第六感がビビビッと来るので、それが答え。
理屈を考えたらダメだね、デザパタは。

851 ：848：03/11/14 23:31

>>850
＞理屈を考えたらダメだね
なるほど。とりあえずやれ、と。
とりあえず色々やってみます。ありがとうございます。

852 ：デフォルトの名無しさん：03/11/15 04:32

>>850
> 理屈を考えたらダメだね、デザパタは。

この一文は同意できないな。
いいたいことはわかるが。
誤解をうむ恐れが多すぎる。
パターンに名前をつけて、理屈で考えれるようにしたのがデザインパターンのメリットなんだから。

853 ：デフォルトの名無しさん：03/11/15 12:31

>>848 だってやりたいことが違うし。

GoFを読んでないのか、読んでてそういう疑問が湧いたのか、それによって
答え方が違ってくるから、その辺返答ｷﾎﾞﾝﾇ

854 ：デフォルトの名無しさん：03/11/15 19:24

JavaってＣマガの連載記事を眺めている程度しか
知らないのだけど、リスナーってオブサーバーのこと
でしょうか？
見ている人って能動的なイメージだけど聞き耳を立てて
いる人って受動的なイメージだ…
あえて言葉をかえたのでしょうか

855 ：デフォルトの名無しさん：03/11/15 19:26

>>854
オブザーバーとはちょっと違う気がする。

856 ：fofofo：03/11/15 21:46

#include <stdio.h>

void main()
{
int i;

printf("前方が危険な場合は車線をはみ出してもよい ○の場合は５\n");
scanf("%d\n",&i);

if(i<=5){

printf("正解\n");
}else{

printf("間違い\n");

｝

｝

857 ：fofofo：03/11/15 21:48

#include <stdio.h>

void main()
{
int i;

printf("前方が危険な場合は車線をはみ出してもよい ○の場合は５\n");
scanf("%d\n",&i);

if(i<=5){

printf("正解\n");
}else{

printf("間違い\n");

｝

｝
上のコードの間違いが分かりません（＾＾；）識別子ｐの前に；を付けろとのエラーが出たんですが意味がさっぱりわからないです

858 ：デフォルトの名無しさん：03/11/15 23:02

>>856-857
スレ違い。
C言語なら俺に聞け! Part 67
http://pc2.2ch.net/test/read.cgi/tech/1068464309/

859 ：デフォルトの名無しさん：03/11/16 03:27

>>854
おんなじ。

860 ：デフォルトの名無しさん：03/11/16 03:52

>>848
おっしゃるとおり、生成手順が毎回同じ場合はTemplateMethod（生成を行う場合はFactoryMethodとかAbstractFactoryとか呼びますが）を利用した場合とBuilderを適用した場合は当然Builderのパターンのほうが冗長になります。
ただしBuilderが解決する問題は、生成手順や生成対象のオブジェクトが状況によって毎回違うかもしれない場合です。
組立手順を表すクラスと、組立を行うクラスを分離することにより動的にそれらを切り替えることができたり、再利用性を高めることができるようになります。

861 ：デフォルトの名無しさん：03/11/19 21:15

直接デザインパターンとは関係ないけど…
GoF本ではよく、パターンの適用例に異なるプラットフォーム間の再利用性を挙げてるけど
複数のプラットフォームを経験してからじゃないと再利用できるコードは書けなんじゃないかと
思うのですが、そこんとこどうでしょうか？
「メッセージループって他のプラットフォームにもあんのか？」ってよく思いますし。
//ちなみに漏れはWindows環境しか知らない痛いプログラマですが、何か？

862 ：デフォルトの名無しさん：03/11/19 23:38

> 「メッセージループって他のプラットフォームにもあんのか？」ってよく思いますし。
じゃあ、調べなさい

863 ：デフォルトの名無しさん：03/11/20 14:20

複数のプラットフォームを経験してからじゃないと再利用できるコードは書けないし、
他人の書いた汚いコードを保守してみないと、保守性の高いコードは書けない。

しかしそれとデザインパターンに何か関係がある？

864 ：デフォルトの名無しさん：03/11/22 14:33

クラスが巨大になってきたので分割を考えています。
巨大になった理由はいろいろあるのですが、
とにかくいろいろ都合があって大きくなってしまいました。
分割にはいろいろな切り口があると思うのですが、
今回はステートパターンを作ってステートごとにクラスわけすることにしました。

そこで疑問。状態遷移のきっかけとなるメッセージには、
その状態に関連したコードが少なからず入ってしまい、少し気持ちが悪くなります。
たとえば、印刷中状態というステートがある場合、
印刷を開始するメッセージは、印刷状態オブジェクトではなく、アイドル状態オブジェクトが受けます。
つまり印刷開始メッセージで渡される各種印刷パラメーターとかの初期設定は、
印刷とは関係の無いアイドル状態オブジェクトが処理しなければなりません。
このような場合、みなさんはどうしてますか？

865 ：デフォルトの名無しさん：03/11/22 14:41

>>864
ステートがメッセージを受け取るの？
何か間違っている気がする。

866 ：デフォルトの名無しさん：03/11/22 16:15

>>864
> つまり印刷開始メッセージで渡される各種印刷パラメーターとかの初期設定は、
> 印刷とは関係の無いアイドル状態オブジェクトが処理しなければなりません。
状態遷移と、メッセージの処理を分離した方が良いと思う。

メッセージを受け取った段階で、

　入力：　現在の状態、メッセージ
　出力：　次の状態

という関数なりテーブルなりを引いて状態遷移のみ行う．メッセージの処理は即座に行わず、
とりあえずキューに貯めておく。状態遷移が終わった後でキューからメッセージを取り出して、
具体的な処理を行う。（ステートパターン＋コマンドパターン）

あと印刷状態を細分して，「印刷開始状態（ここで印刷関係のパラメタ設定）」「印刷中状態」
「印刷終了状態」ぐらいに分割すれば？　ステートパターンを使う場合，一つのステート中で
さらに複数ステートをネストして持っても OK だから、ステート分割の自由度は高いぞ．

867 ：デフォルトの名無しさん：03/11/22 16:50

>>864
> とにかくいろいろ都合があって大きくなってしまいました

設計能力がたりなくて、と正直にかきなさい。

868 ：デフォルトの名無しさん：03/11/22 18:10

突っ込むなら、実のあることもかきなさい

869 ：デフォルトの名無しさん：03/11/22 18:52

>>867
最初はこじんまりしたクラスだったのが、あとからどんどん機能(メソッド)を追加していったとかって
体験したことない?

870 ：デフォルトの名無しさん：03/11/22 19:01

>>869
巨大になることはない。

871 ：デフォルトの名無しさん：03/11/22 23:22

>>866
うまく行きそうな気がしましたけど厳しいです。

　　Ａ　Ｂ
Ｘ　１　２
Ｙ　３　４

ＡとＢが状態、ＸとＹがメッセージです。
Ａ状態でＹメッセージを受けたとき、３を処理してＢに遷移します。
Ｂ状態でＹメッセージを受けたとき、４を処理してＡに遷移します。

先に前処理で状態を遷移させると、Ａ状態のときにＢへ遷移してから４を処理してしまいます。

>>870

個人で作れる範囲のものだとそうかもしれないけど、
大人数で大規模なものを作るといろいろ難しいのです。
ハードウェアやライブラリの制約、過去の資産、スタッフのスキルなどなど…。

872 ：デフォルトの名無しさん：03/11/22 23:26

設計どうのこうのはここで議論することじゃないとおもうけど

で、Mediatorパターンじゃだめかね？

873 ：デフォルトの名無しさん：03/11/23 01:55

>>871
こんな感じのは？（言語はてきとー）

class Context {
　　State state;
//･･･
　　request(msg) {
　　　　newState = state->handle(msg);
　　　　canTrans = newState->preTransition(msg);
　　　　if (canTrans) state = newState;
　　}
}
至ってありふれた解というか、GoFをちょっと変形しただけ。

で、印刷の例だと初期処理はPrintingState::preTransition(msg)で
実装するみたいな。

＞大人数で大規模なものを作るといろいろ難しいのです。
＞ハードウェアやライブラリの制約、過去の資産、スタッフのスキルなどなど…。

分かる。でも分割できる事になって良かったじゃん。

874 ：デフォルトの名無しさん：03/11/24 10:13

出来上がったものを分析したらでてきたパターン（模様）であって
最初から狙ったデザイン（設計）ではないと思う。

875 ：デフォルトの名無しさん：03/11/24 17:13

>>866
＞状態遷移と、メッセージの処理を分離した方が良いと思う。

それはもはやステートパターンじゃないのでは？

876 ：デフォルトの名無しさん：03/11/25 02:15

結城本2冊でGoFの23個とマルチスレッド編12個が詳解されてるけど
これら以外のパターンを学ぶのに良い本とかWebページないかな？

877 ：デフォルトの名無しさん：03/11/25 12:16

アナリシスパターン
J2EEパターン

878 ：デフォルトの名無しさん：03/11/26 12:08

>>876
とりあえずPOSA本

879 ：デフォルトの名無しさん：03/12/08 15:07

GoFのパターンみたいにさ、○○パターンなんて
へんな名前つけて終わり、なんてのじゃなくて、
もっと抽象データ型の関係を、数学から引っ張ってきた
概念で記述したりするような理論とかってないの？
GoFって名前だけ有名で現場じゃ全然浸透してないじゃん。
分った後の人が簡単だと思い込んでるだけで、
実際にはあいまいで分り難いものだからだと思うね。

880 ：デフォルトの名無しさん：03/12/08 15:45

> もっと抽象データ型の関係を、数学から引っ張ってきた
> 概念で記述したりするような理論とかってないの？
"Algebra of Programming"。
…あなたが期待するようなものでは絶対ないけどね。

881 ：デフォルトの名無しさん：03/12/08 17:23

>>880 サンクス子

882 ：デフォルトの名無しさん：03/12/08 22:55

>>879
数学っぽい背景があるヤツだと Generics とか。集合論わかってると話が早い。

> GoFって名前だけ有名で現場じゃ全然浸透してないじゃん。
不幸な現場にいるな……。

883 ：デフォルトの名無しさん：03/12/10 01:04

>>882
＞> GoFって名前だけ有名で現場じゃ全然浸透してないじゃん。
＞不幸な現場にいるな……。

要するに類は友を呼ぶって事なのだろうね。

884 ：デフォルトの名無しさん：03/12/10 05:46

朱に交われば

885 ：82：03/12/11 00:17

shared_ptr と Flyweight は関連あるんでしょうか？
｢共有｣で連想してしまうんですが。

886 ：デフォルトの名無しさん：03/12/11 00:50

>>882
> 数学っぽい背景があるヤツだと Generics とか。集合論わかってると話が早い。
集合論っつーか、モデル理論だね。

887 ：デフォルトの名無しさん：03/12/13 21:22

大昔の2chのム板にShelahオタクみたいな人いたなあ

888 ：デフォルトの名無しさん：03/12/14 22:52

ガンマ９５

889 ：デフォルトの名無しさん：03/12/19 06:28

恋愛のデザインパターンを教えて下さい！

890 ：デフォルトの名無しさん：03/12/19 12:09

決まったﾊﾟﾀﾝは無い。

891 ：デフォルトの名無しさん：03/12/19 12:25

売掛買掛のビジネスアプリの世界でこそ、デザインパターンって威力を
発揮すると思うのですが、そゆー本が皆無で困ってます。

ビル建設（マンション）の例えで言えば、個々の部屋の動線を考慮した、サニタリー
ルームとリビングの関係、天井高さ、床材、なんかが売掛買掛の世界なら、

今世の中に有るテザインパターンの本は、鉄骨の組み方、ボルト穴の配置、
ラーメン構造、基礎の配置って感じです。

892 ：デフォルトの名無しさん：03/12/19 14:41

＞shared_ptr と Flyweight は関連あるんでしょうか？
どっちかつうとshared_ptrはProxyパターンでつ

893 ：デフォルトの名無しさん：03/12/19 18:35

>>891
アナリシスパターンがいいよ

894 ：デフォルトの名無しさん：03/12/20 00:14

>>891
＞今世の中に有るテザインパターンの本は、鉄骨の組み方、ボルト穴の配置、
＞ラーメン構造、基礎の配置って感じです。

それは、もともとそういう位置づけなんだよ。
アナパタになら財務とか会計とか取引とか載ってるよ。

895 ：82：03/12/20 00:21

>>892

ありがとうございます。今、GoFのProxyを読んでます。
smart pointerがありました(auto_ptrのことではないですよね？)。

More Effective C++では配列を例にとってで説明されていたので
｢こういうときに使うもの｣と狭い意味に考えていました。

Proxyっていろんな局面で使われているんですね。そのときが来るまで
後回しにしておく｢遅延評価｣に通じるような機能も持たせることができ
るし。。。｢なりすまして、Side Effectをもたらす｣という意味では共通
しているんでしょうけど、どうでしょうか？

もう一つ、質問させて下さい。More Effective C++で述べられている
｢参照回数計測｣とFlyweightの間には関連があるんでしょうか？
(C++スレに逝け！と言われそうなのは承知してます)

896 ：デフォルトの名無しさん：03/12/20 00:38

>>893-894
そっかぁってアナリシスパターンかぁって斜め読みしてみたけど、
アナパタって毛唐の文化が強すぎて.｡o○

毛唐と和の心はちょっち違うじゃん？
出てる本もパターンカタログってより、カタログの作り方だし。

純日本建築のアナパタが欲しいのに、2*4のアナパタではなぁって思わん？
だれか書いてくれ、日本向けアナパタカタログ集。

897 ：82：03/12/20 00:44

｢なりすまして、Side Effectをもたらす｣という解釈が正しいなら
auto_pointerも一種のProxyかも。。。

898 ：デフォルトの名無しさん：03/12/20 00:46

>>897
そもそも、auto_ptr はスマートポインタの一種だ。

899 ：デフォルトの名無しさん：03/12/20 02:20

>>896
アジアで協同してモデリングしていこうっつーのもあるよ。
http://www.umtp-japan.org/

900 ：デフォルトの名無しさん：03/12/24 15:12

９００

901 ：デフォルトの名無しさん：04/02/01 08:38

うーん。特にOOについて勉強せずにC++でいろいろ組んでいたけど、
自分が知らず知らずのうちに考えていたことのほとんどがGoFの本とやらに
書いてあるみたいやね・・・今日、今から買ってきて読もうっと・・・

902 ：デフォルトの名無しさん：04/02/11 21:19

ちゃんと体系化して覚えないと長続きしないっぺ。
おらもデザインパターンやるっぺ。

903 ：デフォルトの名無しさん：04/02/11 23:49

勉強したけど、周りがついてこないんだっぺ。
一人でやっても嫌がられるだけなんで封印したっぺ

904 ：デフォルトの名無しさん：04/02/12 01:40

シングルトンとグローバルインスタンスはどう違うの？

905 ：デフォルトの名無しさん：04/02/24 09:24

>>904
たとえば、全アプリケーション中に、
Application というクラスのグローバルインスタンスがひとつだけあるようにしたいと。
だけど、普通に書くと、Application のインスタンスは複数作ることが出来るわけ。
Singleton を使うと、インスタンスの複数生成を抑制することが出来る。
これが、グローバルインスタンスとの最大の違い。

906 ：デフォルトの名無しさん：04/03/01 17:16

良ｽﾚage

907 ：デフォルトの名無しさん：04/03/02 02:09

IoC。

908 ：デフォルトの名無しさん：04/03/05 01:26

何でGoFって言うの？

909 ：デフォルトの名無しさん：04/03/05 01:48

Gang of Fourって言うのが面倒だから。

910 ：デフォルトの名無しさん：04/03/05 01:56

ごふっ（吐血

911 ：デフォルトの名無しさん：04/03/05 03:00

俺がGang of Fiveの五人目

912 ：デフォルトの名無しさん：04/03/05 05:12

俺はMao Ze-dong

913 ：デフォルトの名無しさん：04/03/05 07:42

最近関数オブジェクトに目覚めて、
Compositeパターンをテンプレートクラスとして実装しようとしてるんだけど、
テンプレートにしちゃうとメンバ関数を仮想関数にできませんでした。
ツリーを探索するFind()とか作りたいんだけどいい方法ないしょうか？

こんな感じ↓（本来のCompositeのメンバ(addとか）は省いてます。）
template <class T> class Component {
T _d;
public:
Component(const T &d) :_d(d){}
virtual template <class Pr> Component *Find(Pr pr){} // ←これがNG
};

template <class T, class Pr> class FindOp {
Pr _pr;
public:
FindOp(Pr pr):_pr(pr){}
void operator()(T *p) const { p->Find(_pr); }
};

914 ：デフォルトの名無しさん：04/03/05 07:43

template <class T> class Composite : public Component<T> {
list<Component *> _child;
public:
Composite(const T &d) :Component(d) {}
template <class Pr> Component *Find(Pr pr){ // ←これはOK
if(pr(this)) return this;
Itr it = find_if(_child.begin(), _child.end(), FindOp<Component,pr>(pr));
if(it == _child.end()) return 0;
return (*it);
}
};

template <class T> class Leaf : public Component<T> {
public:
Leaf(const T &d) :Component(d) {}
template <class Pr> Component *Find(Pr pr){ return pr(this); }
};

915 ：デフォルトの名無しさん：04/03/05 17:03

ゴフの部屋

綾波が生まれた所

916 ：デフォルトの名無しさん：04/03/06 22:35

>>905
そんなことせんでもグローバルかどうかなんてアフォでも分かる。
ひとつのテクニックとしては分かるけど、パターンに入れること自体アフォ。
∴GoFはアフォ。

917 ：デフォルトの名無しさん：04/03/06 22:40

｜そんなことせんでもグローバルかどうかなんてアフォでも分かる。
アフォはそうでない人の想像を越えることをしでかす。

918 ：デフォルトの名無しさん：04/03/07 04:48

俺namespaceかstatic classでいいや。

919 ：デフォルトの名無しさん：04/03/07 09:41

>>916
> パターンに入れること自体アフォ。
よくあるパターン批判にしか聞こえない

920 ：デフォルトの名無しさん：04/03/09 00:20

パターンって半分常識で、残りが冗長と使えねってのしかないね。
常識的なパターンに名前がついていることでたまに意思疎通がしやすくなる程度。
それぐらいの価値。

921 ：デフォルトの名無しさん：04/03/09 00:49

こういうこという奴ほど、ひとりよがりのコーディングをする傾向にある。

922 ：デフォルトの名無しさん：04/03/09 00:51

いや、べつに>>920がそうだって言ってるわけじゃないからね。

923 ：デフォルトの名無しさん：04/03/10 00:41

なんだこの実用性ゼロのMazeGameサンプルは

924 ：デフォルトの名無しさん：04/03/10 02:35

サンプルなんてそんなもんじゃろ。
一応こんなのものある。

Design Pattern for Computer Games
http://www.mine-control.com/zack/patterns/gamepatterns.html

925 ：デフォルトの名無しさん：04/03/10 22:31

おまえら哺乳類ネタについてはどうですか

926 ：デフォルトの名無しさん：04/03/10 22:36

MammalとかCarとか意味がない。
ウインドウシステムを例に挙げるほうが分かりやすいんじゃないかな。

927 ：デフォルトの名無しさん：04/03/10 23:59

>>920
>常識的なパターンに名前がついていることでたまに意思疎通がしやすくなる程度。
>それぐらいの価値。

当たり前だ。もともとパターンってその為にあるんだろ？

928 ：デフォルトの名無しさん：04/03/11 03:04

ドメイン分析の出来ない926がいるスレはここですか？

929 ：デフォルトの名無しさん：04/03/12 00:54

>>927
まあ、バレーボールのAクイックとかBクイックとかと似たようなもんだ。

ってのはどこで見たんだっけ。

930 ：デフォルトの名無しさん：04/03/13 21:32

結城氏のﾃﾞｻﾞﾊﾟﾀ本、評判良いらしくて、
これまで一度も読んだ事なかったんだけど、
今週、勉強会で使いました。

結果：確かに２３パターン並べているんだけど、
GoF本中途半端に要約してJavaのソース付けただけ、
って感じで、非常にガッカリしますた。

931 ：930：04/03/13 21:33

漏れが足りないと思ったのは、例えば以下の部分：

・動機付け
　これは GoF本にも言える事だけど、
　確かに他人のソースや自分のプログラミングで
　発生するパターンなんだけど、
　動機付けが妙に不自然、説明が不充分なパターンが、
　いくつか存在する。例えば Singleton, Factory Method。
　GoF本つったって、Dr.Gamma (某マンガ思い出したｗ)が
　学位論文として書いたのが元ネタだから、苦し紛れな説明でもしょうがないのかな？
　その苦し紛れな動機付けを、後発の本がそのまま載せてしまうというのは、
　正直、結城氏の見識を疑う。

・Java技術の現状への橋渡し
　例えば、Mediatorのサンプル。
　GUIコンポーネントをサブクラス化し、
　イベント伝達機構を不自然な形で使用 (コンポーネントをリスナーにする)
　してまで、Mediatorの例、作るのは、いかがなものか、と。
　素直に、現在のJavaGUIプログラミングは、
　ObserverパターンとMediatorパターンのミックスだと、
　説明した方が、役に立つ

・関連パターンの説明
　これも、単なるGoF本のコピーで、掘り下げなんて皆無。

932 ：デフォルトの名無しさん：04/03/13 21:33

>>926 と >>928 の関係が分からないおいらに、
ドメイン分析とMammal,Carの関係を教えて。

933 ：930：04/03/13 21:34

結城本が評判いい、とは聞いていたが、なんで評判がいいのか、全く理解できない。
勉強会でこの本使ったおかげで、毎日下準備に苦労させられた。
この本読んで、パターン理解した気になってる人が居たら、怖い。
パターンなんて、新人が暗記して覚えればいいもんじゃないんだぞ、
学生時代からプログラミング本気でやってる人間が、2～3年したら見えてくるもんなんだぞ、と。

質問：ﾃﾞｻﾞﾊﾟﾀ結城本て、本当にいい本だと思いますか？
　　　　Yesな方は、その理由を教えてくだちい。　　　

934 ：デフォルトの名無しさん：04/03/13 21:42

GoF本なんて、Xwindowのwidget例に上げたり、Smalltalkのコードあったり、
オブジェクト指向プログラミングの古文書引きながら理解するもんであって、
概念コピー＆パターン文書のパターンを無視してる結城本はナンセンス。

935 ：デフォルトの名無しさん：04/03/13 21:44

>>4
レスつける資格なし・・・。

936 ：デフォルトの名無しさん：04/03/13 21:48

結城氏、最近は暗号化の本出してるらしいけどｗ
専門家の目に耐えられる内容なのかなｗ
今日、本屋で見かけたけど、怖くて手にとらなかったｗ

彼は結局、ナニする人なの？
要約本執筆のできるプログラマ？

937 ：デフォルトの名無しさん：04/03/14 00:59

どっちにせよ一冊読むだけで理解するのは無理なんだし、
取っ掛かりとして「優しい」本からはじめられるのは良いことだと思うよ。
GoF 本しかなかったらデザパタ知る気になる人がどれだけいたかね？

938 ：デフォルトの名無しさん：04/03/14 01:23

俺はC++もSmalltalkも分からずにGoF本を読んだ。
その分、言語にこだわらないでパターンの抽象を学べたよ。

何度読んでも美味しい本だ。
「GoFのデザインパターン」を学ぶなら、GoF本1冊で充分。

939 ：デフォルトの名無しさん：04/03/14 01:26

君のような優秀な人はアメリカに行ってください。

940 ：930：04/03/14 10:14

>>938
GoF本は、説明が読みにくい部分や、定義が曖昧な部分含めて、
するめみたく、読むば読むほど美味しいのする、良書だね。

その読みにくさや、曖昧さを排除して、素人にわかりやすくした結果、
ｼﾞｬﾝｸ・ﾌｰﾄﾞが出来ますた、という感じ>>ﾃﾞｻﾞﾊﾟﾀ要約本

ｼﾞｬｳﾞｧﾜｰﾙﾄﾞ連載記事は、生の感覚で書いてあるから、なかなか好印象なんだけど。

941 ：デフォルトの名無しさん：04/03/14 12:01

するめとジャンクフードか、言い得て妙だな。
DQNPGを使わなきゃ成り立たないこの世の中で、需要は大きいからな。
まあ、ジャンクを悪いと言うつもりはない。

942 ：デフォルトの名無しさん：04/03/14 12:15

>>936
スレ違いだが一応。とりあえず件の暗号本は買ってあったんで。積ん読だけど。
で、そもそも
>専門家の目に耐えられる内容なのかなｗ
という発想がまず違うんじゃないかと思う。求めるものが違うというか。
本気で専門にやる気はなくて「へぇ、こういうもんなのか～」と理解した気になりたい人向けだと思う。
↓参考： Amazon の書評、レビュー
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797322977/ref=sr_aps_b_/249-2654937-2098752

狙ってｼﾞｬﾝｸ・ﾌｰﾄﾞを作ってるなら意味のあることだと思う。
教科書と啓蒙書、対象は違うけど両方必要でしょ？

943 ：デフォルトの名無しさん：04/03/14 12:34

>>942
単に、「俺はジャンクフードは要らない」、っているだけ。
ジャンクフードしか食えない人に、スルメ食えとは言えない。

944 ：デフォルトの名無しさん：04/03/14 13:00

>>938
禿同。
GoFをちょっと勘違いして要約してまとめましたって感じで、
いろんな意味を含めて、それなりに参考にはなるけど、
デザパタを身につけたかったら、GoFの翻訳本で十分だと思うな。
Javaな人ならまだちょっとは意味あるけど、C++な人なら絶対、GoFの方がいいぞ。
コンパイルが通るソースなんていらないし。

あと、結城本に欠落しているのは実践だと思う。
著者自身がその経験がないのでどうしようもないかな。
中規模のフレームワークを実践しながら構築していく本とかが欲しいな。
パターンハッチングの２章をかなり膨らましたようなやつが読みたい。

945 ：デフォルトの名無しさん：04/03/14 17:28

>>942
ふつー、暗号技術大全と、あとPKIの実例載った本買うよな。
中途半端な知識の人が、中途半端な理解で書いた啓蒙書ほど苦痛な物は無いし。

946 ：デフォルトの名無しさん：04/03/15 08:58

>>931
Singleton と Factory Methodの組って、明らかに、
・クラス自体もオブジェクトであるような言語 (Smalltalk等)の機能を
・クラスはオブジェクトではないような言語(C++,Java)で
実現するためのパターンだよな～。

そこらへんの説明なしに、SingletonやFactory Methodを説明するってのは、
暗にMetaObjectとかリフレクションの概念を要求することになって、理解が困難になる。

さりとて、GoF要約本みたく、背景説明も掘り下げも全部省いちまうと、
一貫した説明や説得力が殺がれちまって、なんでそのパターンが登録されているのか判らん、
て状況になる。

結局、長年にわたり蓄積されたノウハウの説明って、そのノウハウが成立した当時のコンテキストを引きずっているから、
説明難しいのかな

947 ：デフォルトの名無しさん：04/03/15 12:24

なんかよくわかんないけど、
パターンてそんなに難しく考えなくちゃいけないの?
有機本で十分とおもう漏れは、どの辺が馬鹿?
クラス図とサンプルソースがあれば十分じゃね?

948 ：デフォルトの名無しさん：04/03/15 12:59

動機づけが明確でないノウハウなんて、迷信みたいなもんで、邪魔なだけだろ。
そーゆー、一見邪魔な知識を、役に立てられるように掘り下げずに、
ただ受動的に受け入れる姿勢が、ナンセンス。
プログラミングって、インタラクティブなものなんだから、
実利主義じゃ無くちゃーあ、ねぇ？やってられんでしょ

949 ：デフォルトの名無しさん：04/03/15 18:03

そんなん、サンプルコードがあればわかるんじゃない?
受動的とか実利主義とか、いってる意味がよくわかんない。

950 ：デフォルトの名無しさん：04/03/15 19:23

ただ一種類だけのコード見て、それが十分一般的なアイデアであるかどうか、
理解させるのは難しいと思うよ。
そして、実利主義つうのは、そのパターンは使い回すに値する程洗練されているかどうか、
前提条件などに見落としがあって、拡張使用とした時に障害とはならないか？という価値判断のこと。
どっちにしても、ソースコード読みまくる訓練して無い人が、感覚的に意味を理解するのは難しい。
＃だから、自分と同じ文化にある、洗練されたソースコードを読みまくれ！！！

951 ：デフォルトの名無しさん：04/03/15 19:27

デザパタの説明読んであああれのことかと思い当たるコードを
読んだor書いたことがなければデザパタを理解することは難しい。

952 ：デフォルトの名無しさん：04/03/15 19:43

結局のところ、デサパタは個々のパターン自体を学ぶ為のものではなく、
各々のパターンに公共で通用する名前をつけて、プログラマ同士の
円滑なコミュニケーションを図る為のものだろ。

それがいつの間にか、個々のパターン自体を知らない初心者の為の教科書として
使われるようになってしまったというだけの話。

広辞苑を読むだけで、言葉の達人になれる訳がない。様々な文章を読み、
その言葉が使用される文脈を肌で理解する作業を怠っていながら、
聞きかじりの知識で使い慣れない難しい言葉をこれ見よがしに使ったところで、
本当にその言葉の意味を知った人から嘲われる(←なぜかへんかんできない)だけだ。

953 ：デフォルトの名無しさん：04/03/15 22:09

広辞苑のメタファは不適切かと。それは、言語の規格書に似てる。
色々な言語によるお芝居を分析し、共通のシークエンスを抽出した文化人類学の文献とかに、
デザパタは似てる。（そんな研究があったのかは知らないが。）

そこにあるシークエンスたちは、読者に創造力さえあれば、
単独で感動を与えることすらあるのさ。

954 ：952：04/03/15 22:31

言いたいことは分かるが、漏れと>>953 の間には
「言葉」というものについての思い入れの差があるな。
ちょっと反論。

>共通のシークエンスを抽出した文化人類学の文献とかに、
>デザパタは似てる。

抽出された概念は時を経るごとに巷間に伝わり、ついには
広辞苑に載るようになる。じつは辞書に載っている単語は全て、
そのような歴史の積み重ねによって作られてきたものばかりだ。

そして（ここが重要だが）辞書は決して言葉について「定義」はしない。
もともと出来ないのだ。
出来ることといえば、その言葉のイメージを連想させる読者の経験を
思い起こさせる言葉を列記することだけだ。

955 ：デフォルトの名無しさん：04/03/15 23:29

メタ文化人類学の話はさておいて。
パターン一種類しか使わないって、あんまない。
・MediatorとObserverでGUIのアーキテクチャ、とか、
・MethodFactoryとSingletonでMetaObjectの代り、とか、
・TemplateMethodとStrategyでルールの山を整理、とか、
合わせ技で使うのが普通でしょ。(最後の例は、Ruleエンジン使いたいと思ってるけど)

そーゆー、組合わさってナンボのパターンを、一個一個切り離して、
組み合わせの妙を探索したり、
パターン間の相互作用を分析しようとしたのが、
GoF本の面白い所。但し、「関連するパターン」の掘り下げが足りないような気がする。

＃そろそろアナパタ読み進めないと、ヤバいな・・・。

956 ：955：04/03/16 00:12

>>952
それは違うよ。
他の人のソース読みこなし、自分のソースを洗練する訓練して無い人は、
やっぱ頭で判ってるつもりでも、とんでもないソース書いちゃうもんだよ。
経験して覚えろ。失敗から学べ。最初から複雑なパターンを使おうとせず、
シンプルなコードをリファクタリングで洗練する練習をすべきだ。

あと、「デザパタが簡単過ぎる」などと底が浅そうな発言してる暇あったら、
もっといろいろなパターンを勉強されてはいかが？

957 ：955：04/03/16 00:22

>>951
そ、そんな感じ。
自分で発見したパターンは、なかなか忘れないもんだけど、
人から聞いて覚えたパターンてのは、なかなか血肉にならないもんだ。

958 ：デフォルトの名無しさん：04/03/16 00:36

>>955
>それは違うよ。
？？？

まず、>>952 が何を言わんとしているのか
（というより >>955 による解釈だな）、
そして何処がどう違うのかを要約してくれないか？

一体 >>952 の何処から「デザパタが簡単過ぎる」
という珍説が導出されたのか知りたいものだ。

959 ：デフォルトの名無しさん：04/03/16 01:00

>>955
>>956
どういうソースを読みまくるのが良いのでしょうか？
実例を出してもらえると参考になりまつ。

960 ：930：04/03/16 01:17

話の本筋が見えていないおかしな人(>>９５8)はｽﾙｰしとくとして。

>>959
SqueakのSmalltalkコード、
J2SEやらJ2EEのプロダクション・コード、
OO関係ないけど、*BSDやオプソ・サーバ類のコード、
ってあたりは、デフォルトでしょ。
あと、VC++ベースやMacOS Xのフリーウェア、言語処理系、Linux, GNU
なんてのにも目を通すと、
視点や趣味が違うと、ソースがかくも変わるのか、なんて視点が広がるよね

961 ：デフォルトの名無しさん：04/03/16 01:21

いや、まあ間違っちゃいないが、
GoFの本とOOパターン修得の話をしていた気がするのだが。。。

962 ：デフォルトの名無しさん：04/03/16 01:23

961
え、何か？
まるっきりスタンダードな、パターン学ぶ方法の話だけど。

963 ：デフォルトの名無しさん：04/03/16 01:25

>>961みたいな発言する方って、ナニ様なんでしょう・・・♥
きっと、Dr.Gammaかなｗ
じゃ、ET++ にも目を通せｗ

964 ：デフォルトの名無しさん：04/03/16 01:26

実例、っつってんだから、
あなたが読んで感銘を受けたコードを教えてあげれば？

965 ：930：04/03/16 01:29

きみ、失敬だな。
君自身の体験を語ってやれば良いでしょ。

俺の場合、DigitalkのSmalltalk/Vコードと、Minixコードと、DOSベースのマルチタスクカーネル、
あと 1990年以前にリリースされたほとんど全てのオプソ・言語処理系、が原点かな。
言語処理系のソースは、結構いろいろなパターンが使われていて、おもしろい

966 ：930：04/03/16 01:30

*BSDとか、OO＆制約ベースの toolkitとか、Lisp言語処理系に嵌ってた時期もあったな。

967 ：930：04/03/16 01:33

失敬なきみは、ナニのソースに感銘を受けたの？

968 ：デフォルトの名無しさん：04/03/16 01:34

あら、日本語が読めないのね。
ごめんな。

969 ：930：04/03/16 01:35

また、頭の調子が悪い人にﾏｼﾞﾚｽしちまったｗ

970 ：930：04/03/16 01:37

しっかし、夜の一時に、俺の帰宅待ち構えていたように絡んでくるあんた、暇＆悲惨だな。
そんなに暇なら、Squeakの全ソース (Smalltalkコード部分)でも読んで、パターン抽出でもしてみたらｗ

971 ：デフォルトの名無しさん：04/03/16 01:45

で、そういう長い経験がない人が、会社入って PG してくれというときに、
どうやって勉強すればよいのでしょうか？

972 ：デフォルトの名無しさん：04/03/16 01:48

ぷ～でもしながら、そ～す読めばぁ？

973 ：デフォルトの名無しさん：04/03/16 03:57

>>971
経験がなければ理論先行で頭に詰め込んでけばいいよ。
で、実際似たようなパターンに遭遇した・設計した場合にこんなもんかと
復習しながらデザパタの知識とのすりあわせをしていく。
で、さりげなく会社でデザパタ用語を撒き餌しながら同志を募っていくと。

ともかく言語の文法やその言語によるOOの手法ほど即効性はないから
最初は知識として持っておけばいいと思うよ。
実践におけるパターン認識能力は間違いなく高まるからさ。

ただお勉強の順番としては
文法、OO、UML、(中略)、、、、デザパタ
って気がするけどね。

974 ：デフォルトの名無しさん：04/03/16 22:40

デザパタ本は一回読んだだけでは無意味で
コーディングをしつつ何度も読まないと身につかないでしょ。
実践と理論を行き来することで体感するしかないと思いますよ。

975 ：デフォルトの名無しさん：04/03/16 22:48

いや、一回読めばすぐ身に付くよ
「あったあったそういう事」というような基本的なのばかりだから

976 ：デフォルトの名無しさん：04/03/16 23:54

＞975
それはもう既に実践経験を積んでる、ということでしょ？
実践経験がないと読んでも理解は半分で終わります。

977 ：デフォルトの名無しさん：04/03/17 00:40

C++関係で良いソースないですかね？
JavaやSmalltalkには定番があるんだけど、C++にはあんまり見当たらないし、
上でも例が上がってないね。
CppUnitぐらいしか読んでない。

978 ：デフォルトの名無しさん：04/03/17 02:58

>976
じゃあソース書いて実践経験をつければいいのに

979 ：デフォルトの名無しさん：04/03/17 03:22

>>978
もとからそう言ってるやん。
読んで書いて書いて読んで。習うより慣れろ、と。
普通すぎる。。。

980 ：デフォルトの名無しさん：04/03/17 19:58

　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）　＜　次スレまだ～？
　　　　　　　＼＿／⊂　⊂＿ )　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／￣￣￣￣￣￣／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　愛媛みかん　 |／

981 ：仕様書無しさん：04/06/05 11:13

FactoryMethodがわからない･･･
ConcreteProductごとに対応するConcreteCreatorを作るんだよね。
素直にConcreteProductをnewすればよさそうに思えてならない･･･
このパターンの意味ってなんですか？
どんなメリットがあるのでしょうか？

982 ：デフォルトの名無しさん：04/06/05 12:54

>>981
1対1ではなく、複数の種類の ConcreteProduct を作成する場合には意味がある。
「Productのセット」を切り替えるわけ。
この辺、デザパタの教科書には必ず書いてあるぞ。

983 ：デフォルトの名無しさん：04/06/05 14:27

所詮プログラム
お前らソフト屋はこんな本読んでる暇あったらとっととコーディングしろ。
こんなことに時間と頭使うな。
どうせ使い捨てのカスなんだよ。おめぇら。

984 ：r：04/06/05 15:52

>>983
捨てられるまでは使われるからな。

985 ：デフォルトの名無しさん：04/06/05 22:29

>>981
使い道は２つ。
一つは、Ｂａｓｅクラスに*static*なFactoryMethodを定義して、その中で
必要なConcreteProductを生成するという方法。
拡張性がなくてカコ悪いが、サブクラスが固定的な場合は有効。
もう一つは、すでにあるインスタンスから、新しいインスタンスを生成するような、
Prototype的な使い方。Prototypeは、属性を引き継ぐが、FactoryMethodは、
属性を引き継がないくらいの違い。仮想コンストラクタと呼ばれる所以。

986 ：デフォルトの名無しさん：04/06/06 11:32

>>981
デザインパターンを勉強するときは、パターンごとに１つでいいから具体例を覚えるといい

例えば今、ＷｉｎかＭａｃかで分岐するコードがあったとする

if (state == win) {
/* win の場合なんたらかんたら。。*/
} else if (state == mac) {
/*mac の場合なんたらかんたら。。*/}

毎回こんなコードを書くよりなら、２つをサブクラスにしたほうがスマート

// ----------< 生成 >--------------
OSClass os;
if (state == win) { os = new win()
} else if (state == mac) { os = new mac()
}
// -------< 生成終わり >--------

os.operation();

この、生成部分もクラスに持たせれば、工場パターンの出来上がり。

OSClass os = OSClass.create( state );
// OSClassがstateを知っているなら create()だけでいい
os.operation();

987 ：デフォルトの名無しさん：04/06/07 15:47

Commandパターンについてなんですが
Invokerの意味がわかりません。
大概のサンプルソースは

CliantがCommandを生成して
Invokerに渡してInvokerが実行

という感じみたいですが
CliantがCommandを生成してる時点でそのままCliantが呼んでも
あんま変わらないような気がするんですが・・・

988 ：デフォルトの名無しさん：04/06/07 16:21

デザインパターンの骸骨たちって既出？

989 ：デフォルトの名無しさん：04/06/07 16:39

>>987
クライアントがInvoker使うのなら、そうだろうな。。とだけ、言っておこう

990 ：デフォルトの名無しさん：04/06/07 16:54

>>981 >>987
必要性がないならシンプルな方法で組んだほうがよい
なんでもかんでもデザパタを適用すればいいってものではない
修正の影響範囲を最小限に抑えるという原則に従っていけば
そこに必要性があればデザパタの各クラスの役割も見えてくる
面倒なだけだと思えるのなら必要性がないということ

自分の書いたコードを仕様から修正・拡張しながらリファクタリングしていけば
勉強になるんじゃないかな
サンプルだけで覚えても使える勉強にはならんよ

991 ：デフォルトの名無しさん：04/06/07 17:05

>>988
>デザインパターンの骸骨たちって既出？
あそこはわかりやすいから、漏れもよく見るよ
で、６で既出だな。

992 ：デフォルトの名無しさん：04/06/07 20:39

>>991
ども

993 ：デフォルトの名無しさん：04/06/07 21:16

次ぎすれどこ？

994 ：デフォルトの名無しさん：04/06/08 23:24

>987
Invokerは、実行キューだと思えばいい。
例えば、サーバーシステムを考えてみる。
サーバーでグラフを出力するような重い処理をしているときに、なにも
考えずに、グラフ出力用の同期関数を呼ぶと、グラフ出力処理をしている
間、他のクライアントはなにもできなくなってしまう。（ブロックされる）
そこで、グラフ処理をスレッド化して、要求をキューに蓄積すれば他の
クライアントの要求をいったん受けて、あとで処理するようなことができる。
COMMANDは、ＧＯＦ本で紹介されているようにマクロのようなバッチ的な
使い方もできるし、高度なフレームワークを構築することもできる幅の広い
パターンなので、もう少し経験を積んでからチャレンジしたほうがよいだろう。

995 ：デフォルトの名無しさん：04/06/09 10:05

>>980

996 ：デフォルトの名無しさん：04/06/09 10:49

次スレ
http://pc5.2ch.net/test/read.cgi/tech/1065535118/l50

997 ：デフォルトの名無しさん：04/06/10 09:06

997

998 ：ようかんマン ◆CDzPHypGTA ：04/06/10 18:27

998

999 ：デフォルトの名無しさん：04/06/10 18:28

999GET!!

1000 ：デフォルトの名無しさん：04/06/10 18:29

多分無理っぽいけど1000ゲット

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。