〔隔離〕デザインパターンは本当に必要か？〔スレ〕

〔隔離〕デザインパタ ..

97:デフォルトの名無しさん
05/06/22 17:01:06
>>96 それはない

98:デフォルトの名無しさん
05/06/22 17:05:01
>>96
それはバグだろ

99:デフォルトの名無しさん
05/06/22 17:11:27
いくつかのスレッドが同時に初回staticのインスタンスを呼ぶ場合、
ゴミデータになるらしい。あとSMP環境だともっとややこしい事になるそうな。

100:デフォルトの名無しさん
05/06/22 17:13:04
>>99
それってC++の話？

101:デフォルトの名無しさん
05/06/22 17:14:20
そうC++、Javaは知らん。

102:デフォルトの名無しさん
05/06/22 17:16:55
スレッドの排他制御もわからんのか・・・

103:デフォルトの名無しさん
05/06/22 17:19:22
Javaでそれが起こったらJVMのバグとしかいいようがないな。

104:デフォルトの名無しさん
05/06/22 18:22:05
シングルトンがガベコレ対象になる恐れがうんぬんって
記事を見た記憶がありんす。

105:デフォルトの名無しさん
05/06/22 18:46:44
>>99
GoF では環境に依存しないよう、あえて実装してないが
MT safe にするためには当然、排他制御しなきゃならん。
んなこたあパターンに限った話じゃない。

106:デフォルトの名無しさん
05/06/22 18:47:31
>>97-98
きっと何処かで初期化されてるオブジェクトを、2度目の
生成するリスクをさけるにしては、リスクの方が大きい
と思うんだね。

デザインパターンてな考えかたは、認めるし、効果あると
思うけど、GoFにカタログ作らせるのは、不味いと思うよ。
全体にトリッキーなんだよ、奴らのカタログは。

107:デフォルトの名無しさん
05/06/22 18:52:01
出たトリッキーｗ
どのへんがトリッキーなのか具体的に解説きぼんぬ

108:デフォルトの名無しさん
05/06/22 18:59:33
>>107
隔離スレなんだから、反証責任はデザパタのカタログを信じてる馬鹿の
方に有る.

109:デフォルトの名無しさん
05/06/22 19:00:24
トリッキー、トリッキー、GoF時代のthreadは、トリッキー、トリッキー、GoF時代のOOPアプリはね、
教えてあげないよっ、じゃん♪

110:デフォルトの名無しさん
05/06/22 19:21:52
>>108（笑）

111:デフォルトの名無しさん
05/06/22 19:33:04
>>105は >>96のいう危ないインスタンスの例をあげただけだが、
ModernC++Designにある安全で速いダブルロックチェックドなシングルトンさえも
いまは安全でなく、ReadMemoryBarrier()とWriteMemoryBarrier()を
つかってない時勢にそぐわないものになってるというおはなし。

112:デフォルトの名無しさん
05/06/22 19:36:18
その手の(ハードウェア・)アーキテクチャ依存な話は、
アレつかって切り離すというのが、ここ２～３年の潮流

113:デフォルトの名無しさん
05/06/22 19:58:56
どこがトリッキーなのか言わずにトリッキーだと言って信用されるとでも思ってるんだろうかｗ

114:デフォルトの名無しさん
05/06/22 20:06:07
トリッキーという発言自体がトリッキー

115:デフォルトの名無しさん
05/06/22 20:14:54
>>114
寧ろ発言者の存在自体がトリッキー

116:デフォルトの名無しさん
05/06/22 20:38:45
このスレの存在がトリッキー

117:デフォルトの名無しさん
05/06/22 20:59:45 BE:140478454-
お前らトリッキーって言いたいだけちゃうかと。

118:デフォルトの名無しさん
05/06/22 21:05:00
そうだ

119:デフォルトの名無しさん
05/06/22 21:11:00
お前らがトリッキーとか言ってる間に俺は既にトレッキー。
まぁ、お前らはゆっくりトロッキー辺りを目指せってことだな。

120:デフォルトの名無しさん
05/06/22 21:11:08
じゃあエキセントリック

121:デフォルトの名無しさん
05/06/22 21:28:48
結局アンチに正確な反証挙げられる奴はいなかったわけか

122:デフォルトの名無しさん
05/06/22 21:37:08
>>121
>>25の方法って普通のオブジェクト指向でしょ
デザパタ使ってる人ってこれのどの課程でデザパタを使うの？

123:デフォルトの名無しさん
05/06/22 21:39:05
一応これも貼っとこう
>>25への反論

1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
　　オブジェクト指向では不完全な表現しか得られない事象の例：
　　　多重継承、
　　　　時間的な状態変化、
　　　　etc.

　　一般的に、不充分な表現しか得られない事象の例：
　　　　非常に複雑な対象物/概念
　　　　計算不可能な対象物/概念、
　　　　記述不可能な対象物/概念
　　　　etc.

　　もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
　　大半の科学者は仕事をする必要がなくなる。
　　(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)

2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
　　対象物をそのまま記述するのではなく、
　　特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
　　要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。

　　抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
　　それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。

3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
　　の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
　　モデリング/設計/プログラミングの中心的な作業であり、
　　そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。

124:デフォルトの名無しさん
05/06/22 21:47:36
>>122
「対象物の構造を～」ってことを　25　は言っているけど、その切り出し方は無数にある
(例えばオセロで審判を導入するとかしないとか。審判を導入すると双方の不正を一元監視できたり)

んで、その切り出し方の一例としてデザパタを応用するというふうに俺は使っている
(デザパタは直接使用せず、応用として。改変なしでは絶対に組み込めないし、組み込みたくない)

125:デフォルトの名無しさん
05/06/22 21:48:36
>>123
それはネタでしょ。

126:124
05/06/22 21:49:18
ちなみに、改変しても組み込めそうになかったら、その時点であきらめてますのであしからず

127:デフォルトの名無しさん
05/06/22 21:49:43
こんな下の方でチマチマやらずに、
上の方でどうぞ

128:デフォルトの名無しさん
05/06/22 21:50:32
>>125の存在が冗談

129:デフォルトの名無しさん
05/06/22 21:50:38
>>124
具体的にどうやって使うの？
パターンに当てはめる方法でいいの？

130:124
05/06/22 21:55:55
>>129
当てはめはしない

俺が考えた構造と、デザパタで提示されている構造が一致したら　「お？このまま行っても平気か？」　って思ってる
ついでに、提示された構造を参考に、幾らか修正を入れる

要は、どんな下らない物でも良いから、自分の考えを支持してくれる物があれば良いんだな俺の場合

131:デフォルトの名無しさん
05/06/22 21:59:02 BE:379290896-
>>130
デザインパターンの本来の目的からは外れてる気がするが（ﾟεﾟ）ｷﾆｼﾅｲ

132:デフォルトの名無しさん
05/06/22 22:08:06
>>124
何処に石を置けるのか知らなければ、審判はジャッジできない。
何処に石を置けるのか知らなければ、CPプレーヤーは戦略を立てられない。
石を置くとボードがどう変化するのかを知らなければ、審判はジャッジできない。
石を置くとボードがどう変化するのかを知らなければ、CPプレーヤーは戦略を立てられない。
さて、どうしましょう？と、>>124に話を振るのは筋違いだな。

さて、どうしましょう？
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向と主張してた貴方！
上記の主張を前提に、クラス設計してみてちょいよ。

133:124
05/06/22 22:18:31
>>132
いや、だから、対象物の切り出し方は無数にあるって例を出しただけで……
(審判は思いつき。妥当かどうかは考えてない。ちなみに、俺は大抵ボードが制約を持つように組んでる)

答えは無数にある。どれも正解かもしれないし、どれも不正解かもしれない。

134:デフォルトの名無しさん
05/06/22 22:18:42
>>130
どうせ修正するなら、当てはめたほうが早いのではないでしょうか？

135:124
05/06/22 22:22:23
>>134
正直速くない。部分的に一致させる事もあるけど、
サンプルで提示されている構造の使用価値はサンプルで提示されている程度のレベルでしかないと思っているし

ガチガチに当てはめると融通が利かない。妥協が必要

136:デフォルトの名無しさん
05/06/22 22:24:58
デザインパターンは

「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていたあれですね。あの方法で組めばいいんですね」

というまどろっこしい会話を

「それsingletonね」
「はい」

というシンプルな会話にするためにあるのよ

137:デフォルトの名無しさん
05/06/22 22:28:07
>>136
「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」　
「あぁ、以前のシステムでも使っていた　Singleton　ですね。あの方法で組めばいいんですね」　

138:デフォルトの名無しさん
05/06/22 22:41:43
>>136
１人のときは、全く役に立たないのでしょうか？

139:デフォルトの名無しさん
05/06/22 22:57:29
>>136-137
かつて２ちゃんの粘着くんの議論を終結させるために、
そーゆー一見もっともそうな説明をした事がある。

で、同じ話を何回書き込んだら気が済むの？

140:デフォルトの名無しさん
05/06/22 23:00:09
アンチが何か具体的な事を書くまでマターリ待とう。
オブジェクト指向だの設計だのって、結局は具体的な事が言えない
から逃げる為の口上に使ってるだけじゃん。

141:デフォルトの名無しさん
05/06/22 23:09:37
>>140
この人のあいかわらずソースを求める姿勢はどうにかならないものだろうかｗ

142:デフォルトの名無しさん
05/06/22 23:09:55
ウンコだかウンチだか知らないが、
煽り好きの>>140みたいなのは、リアルには付き合いたくない。

143:デフォルトの名無しさん
05/06/22 23:12:27
>>141もウンコ

144:デフォルトの名無しさん
05/06/22 23:13:58
この人がどの人か知らないが、俺はソースなんて求めてない。
具体的な何かでいい。とりあえず、上で出てるクラス設計なんてどう？
てか、言い訳多すぎ。

145:デフォルトの名無しさん
05/06/22 23:33:13
クラス図出せよ。

146:デフォルトの名無しさん
05/06/22 23:36:38
>>132
　俺はこの件に関して傍観者だが、
　>>132の問題設定が問題の体を為していないのと、
　せっかく>>123に挙げた矛盾点を取り込んでいないあたりに、
　そこはかとなく素人臭さを感じた

147:デフォルトの名無しさん
05/06/22 23:38:51
>>146
　俺もこの件に関して傍観者だが、
　具体性がないところにいつものアンチ臭さを感じた

148:デフォルトの名無しさん
05/06/22 23:55:48
>>144-145は、問題設定を明確にした上で、課題を出した方がいい。
　このままだとアンチの自作自演と疑われて縞馬
　

149:デフォルトの名無しさん
05/06/23 00:01:13
では、僭越ながらｵﾚ様が課題をだしますよ。

Ｑ１．オセロを構成するのに必要なクラスを列挙せよ。
Ｑ２．Ｑ１で列挙した各クラスの役割について簡素に説明せよ。
Ｑ３．Ｑ１で列挙した各クラス間の関係(接続)について簡素に説明せよ。

150:デフォルトの名無しさん
05/06/23 00:04:29
>>136-137
>>111が例示してくれたように、デザインパターンのGoFカタログは
致命的なんだよ。
「SINGLETONパターンで、」と会話が成立してる*つもり*になって
いて、片方は、スレッーフなカスタマイズSINGLETONを話し、
片方は、GoFベースのSINGLETONで話てたらOUTなんだから。

GoFのカタログを、バイブルのように使うのは、危険なんだよ。
使い方としては、アルゴリズム集みたいなイメージで使うべき
なんだよ。

151:いつものアンチ
05/06/23 00:06:37
>>146
>>123は何がいいたいのかわからない。

>1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
の理由が
>オブジェクト指向では不完全な表現しか得られない事象の例：
> ～略～
>　　(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
なんだろうけど。
これは一体何がいいたいのかわからない。
とりあえず、手当たり次第レスつけると。
>オブジェクト指向では不完全な表現しか得られない事象の例
って書いてあるけど。
なんでここで「多重継承」なの？（このへんでもう相手にしなくていいかなーって思った）
多重継承を表現するって聞いた事ないんだけど。説明キボン。
んで次に書いてあるのが「時間的な状態変化」だけど。
なにこれ？意味がわからない。何がいいたいの？説明キボン。
で
>一般的に、不充分な表現しか得られない事象の例：
って書いてあるけど。
>非常に複雑な対象物/概念
どこまで複雑なのかは知らんけど根気よくやればできるんじゃない？
これはオブジェクト指向に限って表現できないものなのかなー。
>計算不可能な対象物/概念、
>記述不可能な対象物/概念
って書いてあるけど意味不明説明キボン。
ここでは１だけをとりあげたけど２と３なんて宇宙人の文でも読んでるのかと思った。ので意味不明。レス不能。

152:デフォルトの名無しさん
05/06/23 00:08:16
>>150
共有メモリアクセスの排他制御が必要だっつう
ハードウェア・アーキテクチャ依存の御託はもう判ってるから、
さっさと>>149に応えたらどうかね

153:デフォルトの名無しさん
05/06/23 00:09:15
>>151
キミの頭が未開拓なのはよく判ったから、
さっさと>>149に応えたらどうかね

154:デフォルトの名無しさん
05/06/23 00:12:35
>>153
やだよ。
だってそいつなんだかんだいってソースコードくれくれいってるのみえみえじゃん。
関わるとソース出さないとわめきたてるからレスつけない方がいいよ。
オブジェクト指向での設計からソースまでもってけないだけだろそいつは。
単純にクンフーが足りないｗ

155:デフォルトの名無しさん
05/06/23 00:13:39
クラス図出せ

156:デフォルトの名無しさん
05/06/23 00:16:37
ソースなんかいらないから、言語依存しないクラス図を出せよ。

157:デフォルトの名無しさん
05/06/23 00:31:25
また逃げたｗ

158:デフォルトの名無しさん
05/06/23 00:37:08
>>157
自作自演はバレてるから、さっさと>>149のクラス図出せ

159:デフォルトの名無しさん
05/06/23 00:38:42
あと、シーケンス図もな。

160:デフォルトの名無しさん
05/06/23 00:40:41
>>159
自作自演はバレてるから、さっさと>>149のクラス図出せ

161:デフォルトの名無しさん
05/06/23 01:02:42
だからクレクレ厨を相手にしちゃ駄目だって。
何、あげたって結局理解できるわけないんだから。

162:アンチじゃない人
05/06/23 01:04:00
ってか正直、>>123は俺でもわかりません。
1番を読み終えた時点で睡魔に襲われますた。

163:デフォルトの名無しさん
05/06/23 01:30:50
>>161-162
バレバレの自演はいいから早く出せよ

164:デフォルトの名無しさん
05/06/23 01:40:37
>>163
なんのために？

165:デフォルトの名無しさん
05/06/23 02:00:08
誤ったデザパタ推進派が、荒らしに来てる。
いやだ、いやだ。

166:デフォルトの名無しさん
05/06/23 02:04:36
いやあさすが隔離スレらしい展開だな(w

荒らしも糞も無いだろ
隔離スレにマトモな議論期待するなって

167:デフォルトの名無しさん
05/06/23 08:36:26
アンチの特徴：具体例を求めるとキレる
「デザパタってトリッキーだよな」
「どのへんが？」
「ﾑｷｰ！！！あ；ｄｌふぃうえあ；ｋじゃ；」

「オブジェクト指向がわかってればデザパタなんか設計に使わない」
「じゃあ○○をデザパタ使わずにどう設計する？」
「ぎえいぎえが；おい」

168:デフォルトの名無しさん
05/06/23 10:11:02
>>164-165
本当に言い訳がましいなｗ

169:デフォルトの名無しさん
05/06/23 12:32:12
お前ら空っぽの引き出しを何時まで弄ってるつもりだ？
もう完全スルーでいいだろ？

それはそれとして、このスレを何か有効に使う手はないものか？

170:デフォルトの名無しさん
05/06/23 13:13:42
っていうかここはもともとカラッポの引き出しを弄るスレですから

171:162(通りすがり)
05/06/23 14:24:13
>>163
自作自演じゃねーし。
>>123はごめん。素で意味不明。もっと文章力を付けてください。
で。オセロのクラス図？ごめｗｗｗｗダリｗｗｗｗｗ

172:デフォルトの名無しさん
05/06/23 16:08:16
デザインパターンを貶しておきながら具体的な話からとことん逃げ続けるアンチでありました

173:デフォルトの名無しさん
05/06/23 19:19:58
>>169
【デザパタ嵌り道】こんな失敗しますたスレヽ(`Д´)ﾉｳﾜｧｧﾝ【失敗談】
というのはどうか？

174:デフォルトの名無しさん
05/06/23 21:05:03
まぁ大体理解できてないか適用するパターンを間違えた例がでて終わりだろ

175:16
05/06/23 21:50:37
相変わらずちょっと空けるとずいぶん流れてるなー。このスレ。
あらかじめ断わっとくと、間違ってもソースコードはいらないから。

じゃあインベーダーの話をしよう。

>>25
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
>この基本は絶対に変わらない。
>プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
>無かったら真っ先に担当者を問い詰めることができる。
>これがオブジェクト指向の単純な利点だ。

でさ、まず自機、敵、弾のオブジェクト（クラス）を作るじゃん。

１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？

でさ、１と２って同じ処理だよね。やってることは。
どういう風に設計・実装するのか知りたいわけですよ。俺は。

俺がやるならどうやってもデザインパターンを使わずには作れないから。
っていうより、俺の能力じゃあ、どう書いても、誰かがこれはデザインパターンでいうなんとかパターンっていうものですよ。って言うだろう。俺がそのパターン名を知らなかったとしてもさ。

176:デフォルトの名無しさん
05/06/23 21:55:29
抽象クラス「キャラ」から「自機」と「敵」を継承させて
HitTest()は「キャラ」に実装するのが普通でしょう。

そのレベルではデザパタは別に関係ないし、例として適切じゃない気がするが。

177:デフォルトの名無しさん
05/06/23 22:10:50
つうかなんでいつも例がゲームなんだよ
中学生かよ

178:デフォルトの名無しさん
05/06/23 22:12:38
懐かしの「オブジェクト指向は戦場では必要無し」スレの
香りのするスレはここですか？

179:デフォルトの名無しさん
05/06/23 22:13:56
しかもまた「オセロ」でも書いて説明しるって言ってるし。
オマイたちは本当に進歩しませんね。

180:デフォルトの名無しさん
05/06/23 22:29:20
>>176
で、弾もあるよね。自分も敵も弾もそれぞれ座標（現在地）持ってるよね。
自分オブジェクトは１個かもしれないけど敵とか弾はたくさんオブジェクトがあるよね。
やっぱりループで回すよね。
ここまででデザパタは１つも出てこないのか？

>>177
じゃあ代わりに適切な例を上げて。

181:デフォルトの名無しさん
05/06/23 22:32:32
ゲームならオブジェクト指向でほぼOKでしょ。
俺が知りたいのはJ2EEアプリをJ2EEパターンを使わないで
アンチの主張する「オブジェクト指向設計」のみでどうやるのかに興味がある。
どんなに素晴らしいモノなのか、教えてもらいたいものだよ。
本当にできるならねｗ

182:デフォルトの名無しさん
05/06/23 22:41:18
>>180
「弾」も「キャラ」から派生させれば問題なかろ。

もう少し条件つけんとCompositeだのFlyweightだのは出てこんぞ。

183:デフォルトの名無しさん
05/06/23 22:43:44
そういえば彼はJ2EEの話に対して１回「出来る」ってレス返しただけであとは完全スルーだったな

184:デフォルトの名無しさん
05/06/23 22:48:02
仕事した事ないんだろ

185:デフォルトの名無しさん
05/06/23 22:50:33
J2EEアプリであるための条件って何なんだ？
helloworld.jsp
だけでいいんなら、別にパターンいらないぞ

186:デフォルトの名無しさん
05/06/23 23:14:01
>>181
前提が間違ってる。
崇高なオブジェクト指向を信奉する彼は邪悪なJ2EEなんて使わない。
彼なら最初にAPサーバを書くところから始めるに違いないｗ

187:デフォルトの名無しさん
05/06/23 23:41:58
>>186
だよな。「Servlet」というフレームワークや実装パターンのカタマリみたいな
プラットフォームは拒否るだろうからね。

188:デフォルトの名無しさん
05/06/24 00:25:49
今のところ肯定派の圧勝か。。

189:デフォルトの名無しさん
05/06/24 00:39:14
アンチは理想論ばかり振りかざして具体例をまったく出せていないからね。

190:いつものアンチ
05/06/24 01:03:27
奇跡だ！
まともな質問が！

>>175
>１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>
>でさ、１と２って同じ処理だよね。やってることは。
>どういう風に設計・実装するのか知りたいわけですよ。俺は。
これはオブジェクト指向で設計をしていれば、
オブジェクトの抽出のときに自機と敵が存在するフィールド（シーンのがいい？）のようなものができると思うから
そこに処理をかけばいいと思うよ。（なければフィールドクラスを作る。）
そのフィールドでの出来事だしね。

191:デフォルトの名無しさん
05/06/24 02:03:47
>>190
その"フィールド"をメディエイターとしてするのかな？

あと、敵キャラの動きとかはストラテジーパターンで表現できそうだ。

あと「スコアカウンタ」から「敵オブジェクト」を
オブザーバーパターンを使って監視しておけば
得点の加算ができそうだね。

192:デフォルトの名無しさん
05/06/24 04:04:33
お前らシングルトンも知らないのｗ
死ねば？

193:デフォルトの名無しさん
05/06/24 07:07:21
>>191
>あと「スコアカウンタ」から「敵オブジェクト」を
>オブザーバーパターンを使って監視しておけば
>得点の加算ができそうだね。
ん？これは何をやってるの？
もし、クラスのインスタンスの数を数えてシステムに反映させているなら
設計が悪いと思う。

194:デフォルトの名無しさん
05/06/24 10:28:59
>>191
アンチの人にパターン名で解説しても話が通じんだろ。

>>193
「スコアカウンタ」のインスタンスが一つあって、
敵オブジェクト一つ一つにその「スコアカウンタ」のインスタンスを持たせておいて、
敵オブジェクト自身が死んだときに「スコアカウンタ」に点数を報告するって方法では？
設計悪いかな？漏れはまあいいんじゃないかなと思うけど。

195:デフォルトの名無しさん
05/06/24 10:46:38
課題のインベーダー程度ならともかく
複数人同時プレーやもうすこし複雑なスコアシステムや設定によるスコアシステム自体の切り替えなどを考えると
シングルトンのスコアシステムに必要そうな情報全てを付加したスコア発生メッセージを通知するのがベター
嫌な設計だが

196:デフォルトの名無しさん
05/06/24 10:49:06
細かいところは分からないけど、全体的にMVCっぽくなりそうな...

197:194
05/06/24 11:30:53
>>195
複雑なスコアシステムだったとしても、
オブザーバに報告する内容をすこし増やせばいいんでない？
シングルトンだと、設定によるスコアシステム自体の切り替えはきつそうな希ガス。

198:デフォルトの名無しさん
05/06/24 21:25:27
>>194
>敵オブジェクト自身が死んだときに
ゲームだとこの死んだときってのが微妙でね。
オブジェクト自身が本当に消滅したときなのか、
敵が死体で転がってる状態なのか、ってのは微妙でしょ。

だから、ゲームの仕様でインスタンスだのオブジェクトだのが出てくる人間の
プログラムはちょっと気を付けてみることにしてるｗ

もし、部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
俺の環境だと即組み直しｗ
まあ、将来の為。

あ、これはデザパタとかオブジェクト指向とか関係無いから。

199:デフォルトの名無しさん
05/06/24 22:33:12
> 部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
意味不明。

200:デフォルトの名無しさん
05/06/24 22:58:38
>>199
そのままの意味だけど？
これ以上詳しくはできない。

201:デフォルトの名無しさん
05/06/24 23:05:28
単に死体になってるだけ＝ただの状態変化
実際にゲームから消滅した＝オブジェクトの消滅

として設計され、管理されているなら
> インスタンスの消滅を見てゲームを動かし
ていても問題ないのでは？

202:デフォルトの名無しさん
05/06/24 23:06:02
SE にとって重要な能力の一つは自分の考えを簡潔かつ適切に他人に伝えるだと思う

203:デフォルトの名無しさん
05/06/24 23:07:08
>>202
違うな。
どんな人間にも平気で嘘がつける度胸だ。

204:デフォルトの名無しさん
05/06/24 23:08:52
>>201
それが駄目なことについて延々と語るつもりは無いな。
いいと思うなら自由にやってくれ。

205:デフォルトの名無しさん
05/06/24 23:09:46
平気で嘘がつける = 適切に

206:デフォルトの名無しさん
05/06/24 23:10:32
SEなんて日本だけの腐れ職業のことなんざどうでもいいよ

207:デフォルトの名無しさん
05/06/24 23:11:14
またゲームかよおまえら
ゲームつくるのにデザパタはたいしていらんぞ

208:デフォルトの名無しさん
05/06/24 23:12:22 BE:393339078-
平気で嘘をつけない奴のほうが稀な気が。

209:デフォルトの名無しさん
05/06/24 23:13:26
そうだな日本は偽装派遣天国だしな

まあ面接でちゃんと問い詰めればすぐバレるけどな
問い詰めちゃいかんらしい

210:デフォルトの名無しさん
05/06/24 23:14:51
>>201
ポインタ使いまわしてて、消滅したはずのオブジェクトが復活する（したように見える）バグがでるに一票。
危険な道は避ける。
これがわからない人間にゲームプログラマは難しい。

211:デフォルトの名無しさん
05/06/24 23:17:34
>>210
それはメモリ管理が出来ていないと言っているに等しいと思うんだが....

212:デフォルトの名無しさん
05/06/24 23:22:40
>>211
メモリの管理はできてるでしょ。
メモリは破壊していないし、はみ出してもいない。
ただ、ポインタを使いまわしてしまっただけの話さ。
まあ、敵クラスを作った人間以外の人間が敵クラスを使うときは要注意といったところだね。
鉄則としてヌル判定をするポインタの使い回しは死んでもしないとか、
就業規則に書いておけば自分の責任にならなくて済むと思うよ。

213:デフォルトの名無しさん
05/06/24 23:24:05
>>194
ん～、結局同じな気がする。
一瞬、変更に対して強いかな？とも思ったんだけど、「必要そうな情報」に幅がないし
幅を出すと結局変更が両者に及ぶから変わらない。
キャラクタ→スコアシステム#update→キャラクタ#getScore
これ以外の流れというのがちょっと見えてこない。

>>197
元発言者の意図とかみ合ってるかは不明なんだけど・・・・・・
シングルトンをファクトリに生成させるパターンなら切り替えは可。
ScoreSystem scoreSystem = new ScoreSystemFactory(設定)
もう常套句すぎてアレなんだけど、こんな感じ。

214:デフォルトの名無しさん
05/06/24 23:35:04 BE:568936499-
Factoryをnewするのか？(･∀･)ﾆﾔﾆﾔ

隔離スレがパターンの話題で盛り上がって
本スレがスレッドストップとはこれいかに。（ﾟεﾟ）ｷﾆｼﾅｲけどな。

215:デフォルトの名無しさん
05/06/24 23:35:56
>>212
それは、ダングリングポインタを参照してしまったということだから、
広義ではメモリ管理が出来ていないに等しいと思う。
本来、誰かが使っているならそのポインタは削除してはいけない。

ま、それを完全に保証することはしばしば非常に困難であったり
不可能であったりするのは事実だが

216:デフォルトの名無しさん
05/06/24 23:38:44
メモリ管理できてねぇだけじゃん
インスタンスの生成、消滅の責任とタイミングをキチンとしないからそうなる

217:デフォルトの名無しさん
05/06/24 23:40:13
>>214
あっ！orz
うるせ～、超省略表記なんだよヽ(`Д´)ﾉｳﾜｧｧﾝ

218:デフォルトの名無しさん
05/06/24 23:40:14
>>216
でも、この場合は誰の責任になるの？
敵クラス？敵管理クラス？メモリ管理クラス？

219:デフォルトの名無しさん
05/06/24 23:42:05
>>215
でしょ。ポインタ頼みのステータス管理なんてやらないにこしたことないんだよ。

220:デフォルトの名無しさん
05/06/24 23:42:38 BE:505721489-
ところで複雑なスコアシステムってどんなのがあるの？
あんまりいろんな種類のゲーム知らないから単純なポイントの加算しか思い浮かばない。

221:デフォルトの名無しさん
05/06/24 23:45:10
>>219
いや、それはいいすぎ....
まあ、参照関係が複雑な有向巡回グラフみたいになると手におえなくなりがちなのは
確かだが、常にそうだというわけではないし、参照カウンタで済む場合は
それを使うという手もある。

222:デフォルトの名無しさん
05/06/24 23:45:12

ゲームの場合例えば敵キャラが消滅したら即deleteするのはありえない
ゲームタスクのループ内で自機が参照してるかも知れないし
他の敵も参照してるかもしれない
敵キャラに消滅フラグなりなんなり持たせて
ゲームタスクのループとは別フェイズで実際にdeleteなりメモリプールに戻すなりする

ってデザパタ関係ないな

223:デフォルトの名無しさん
05/06/24 23:45:31
ボーリングは少しメンドイ。
マージャンとかかな。

224:222
05/06/24 23:45:54
>>220

225:223
05/06/24 23:46:46
222すまん、ﾚｽつくの速すぎて慌てた。
>>220

226:デフォルトの名無しさん
05/06/24 23:49:47
>>221
でも本音ではしっかりステータス管理してもらったほうがいいでしょ。
よくないよ。議論に勝つ為のレスなんてつけるもんじゃない。

227:デフォルトの名無しさん
05/06/24 23:52:12
>>226
なぜだッ！！
なぜ貴様に俺の心が読み取れるんだッ！！！

228:デフォルトの名無しさん
05/06/24 23:52:25
>>223
マージャンとインベーダーの間で再利用するの？
されは流石に無理ないか？

229:デフォルトの名無しさん
05/06/24 23:55:43 BE:442506097-
>>223
あぁ、なるほど。

敵の消滅とかの話が出てたから、
シューティングっぽいゲームばかりを想像していたヨ。

>>228
マージャンだと点数の計算方法が複数ある…気がしたような気がしないような。
なので切り替えられると便利かもしれない。

230:デフォルトの名無しさん
05/06/24 23:56:50 BE:168574346-
さすがに異種ゲームの点数計算クラスを共有しようとは誰も考えないと思うので。

231:デフォルトの名無しさん
05/06/25 00:16:23
>>214
相変わらず僻みっぽい馬鹿だな。
とりあえず
ｽﾚﾘﾝｸ(tech板:14-15番)
のリンク先くらい読んでから煽れクズ

232:デフォルトの名無しさん
05/06/25 00:20:00
結局、>>198からの議論は、「オブジェクトを（ゲーム上）消したことに
すべきタイミングと、実際に消していいタイミングは必ずしも一致しない」
（通常後者のほうが遅い）

ということに尽きるのかな。
一言で言えるんだから、一言で言えばいいのに。

233:デフォルトの名無しさん
05/06/25 00:21:35
まぁ、>>213がド素人なのは誰の目にも明らかだがなｗ
Singletonの生成にはコンストラクターを使わない。つまり、getInstance()とかで生成する。
Factoryの目的は、どのサブクラスのインスタンスを生成するか、という点を抽象する事にある。

234:デフォルトの名無しさん
05/06/25 00:24:05
class Singleton {
　　static object m_Foo;
　　static object m_Bar;

　　static object getFoo() { return m_Foo; }
　　static object getBar() { return m_Bar; }
}

ではなぜまずいのでしょうか
getInstance()とかいちいちウザいです

235:デフォルトの名無しさん
05/06/25 00:30:39
スルー。

236:214
05/06/25 00:34:49 BE:210717465-
>>231
相変わらず汁が先走ってるな。
とりあえず >>213-214 >>217 の流れを見て
自分の過ちと傲慢さを理解して恥じろ。

237:デフォルトの名無しさん
05/06/25 00:36:54 BE:126431429-
>>232
注意点は一言で言えるが実装は一言で言えないぜ。

238:デフォルトの名無しさん
05/06/25 00:39:54
>>237
流石に実装まで示せとは誰も言ってないじゃまいか。

239:デフォルトの名無しさん
05/06/25 00:41:23
>>238
もう、日本は終わったんだよｗ

240:237
05/06/25 00:44:23 BE:505721298-
>>238
>>198-～の実装の議論は少し有意義に見えたが。

241:234
05/06/25 00:49:32
華麗にスルーされちゃってぼくちん少し寂しいの
てへ

242:デフォルトの名無しさん
05/06/25 00:53:55
>>241
俺はアンチなんだけど
それって実体はいつできるんだ？
呼び出す前からできちまってる気がしねぇ？

243:234
05/06/25 00:56:37
コンストラクタはstaticにすればいいんじゃまいか

つか、それだけの問題で
まいかい
Singleton timpo = Singleton.getInstance();
bokkiage = timpo.invoke();
とかやるのはいやです。

244:デフォルトの名無しさん
05/06/25 00:57:06
目的は「インスタンスを1つに固定する」だからいいじゃん

245:デフォルトの名無しさん
05/06/25 00:57:15

　華麗なる素人スレ

246:デフォルトの名無しさん
05/06/25 00:58:12
>>243
bokkiage = (Singleton.getInstance()).invoke();

247:デフォルトの名無しさん
05/06/25 00:59:32
>>234
仮想コンストラクタで検索。

一般に、クライアントコードが簡素になる点と
融通が効く点が利点して上げられてる。

248:デフォルトの名無しさん
05/06/25 01:00:36
>>243
それじゃおめ、
そうやって組んだしんぐるトンは通る可能性のあるものに関しては実行時にすべて生成されてしまうわけだな？
つ逝ってよし

249:234
05/06/25 01:02:39
>>247
継承を考えてなんとなく柔軟性を持たせたいというのは分かりますが
実際には、継承なんかしないクラスこそシングルトンの候補であることが
非常に多い気がします。
その場合には、闇雲にシングルトンにせずとも構わないんでしょうかね。

「クライアントコードが簡素に成る」については全く納得がいきません。
メンバがstaticであれば
(Singleton.getInstance()).invoke();
ではなく
Singleton.invoke();
と書けるでしょう。

250:デフォルトの名無しさん
05/06/25 01:04:50
まあ、いつみてもデザパタは役に立たないよね。

251:デフォルトの名無しさん
05/06/25 01:06:04
なんでSingletonの話題しか振れないの？
重箱の隅しか突付けない哀れな煽りだ

252:234
05/06/25 01:07:00
ぼく、あおりじゃないのに(; ;)

253:デフォルトの名無しさん
05/06/25 01:07:14
======================================================================
　　　　　　　　　　このスレは厨房を隔離するための隔離スレです。。。
======================================================================

254:デフォルトの名無しさん
05/06/25 01:07:54
>>234　→ >>243 → ぬるぽ

255:デフォルトの名無しさん
05/06/25 01:16:10
>>252
お前はネタｗ

256:デフォルトの名無しさん
05/06/25 01:20:06
>>249
インベーダーの例に戻って言うと、当初のスコアシステムに
ハイスコアの記録機能を追加した新スコアシステムを作る
場合、継承するのが妥当なんじゃない？

257:234
05/06/25 01:21:39
>>256
その場合、旧スコアシステムと新スコアシステムが共存しないのであれば
継承する必要は無いと考えますが。

258:234
05/06/25 01:22:03
>>255
ぼくでおなにーとかはしないでください
こわいので

259:デフォルトの名無しさん
05/06/25 01:24:55 BE:245837257-
単なる関数郡として使うだけならstaticでいいと思う。

260:234
05/06/25 01:26:34
>>259
それは、いわゆるUtilityクラスのような、状態の存在しないものですね。
それについて異存のあるひとはいないとおもいます。

ぼくがいっているのは、状態が存在するが、システムでユニークなクラス
のことです。とゆうか、Singletonというのは、そのようなものでしょ？

261:234
05/06/25 01:27:07
> システムでユニークなクラス
ちょっとはしょりすぎた

すみません、酔っているので

262:デフォルトの名無しさん
05/06/25 01:27:20
>>249
Foo foo = Singleton.getFoo();
Bar bar = Singleton.getBar();

Foo foo = Singleton.getInstance("Foo");
Bar bar = Singleton.getInstance("Bar");

後者の方が簡素というか、動的に生成物を変更するのが楽。

263:デフォルトの名無しさん
05/06/25 01:30:31
まぁ文字列渡すよりは、
・コンフィギュレーション選択用の定数か、
・コンフィギュレーションを表すオブジェクト
を渡すべき

264:デフォルトの名無しさん
05/06/25 01:32:54
>>260
それは「グローバル変数」だ。悪。

シングルトンでは「状態のないもの」を表現する。
たとえば、「ストラテジーパターン」で使うストラテジーオブジェクトとか、
「ステートパターン」で使うステートオブジェクトとか。
「ファクトリー」もそうだ。

265:デフォルトの名無しさん
05/06/25 01:34:21
>>257
オブザーバーパターンとのかみ合わせを考えてみて。
public class Enemy {
　addObserver(ScoreSystem ss) {}
}
↑こうなってた場合、継承が必要。

public interface Observer {}
public class Enemy {
　addObserver(Observer observer){}
}
↑こうしとかないオマイが馬鹿と言われれば、だよね～
としか言い様がない気もするが・・・・・・

266:234
05/06/25 01:34:27
>>254
え？
ぼくの認識では、メンバ変数はすべからく「状態」だと思っているのですが
間違いですか？

なんか、ちょっとはつみみな所見です。

267:234
05/06/25 01:36:31
>>265
いやその、共存する必要が無いのであれば、インタフェースを変えずに
スコアシステムの「実装」を変えればいいだけなのではないかと。

なにか勘違いしていますか？ぼくは

268:234
05/06/25 01:37:33
>>262

それはちょっとSingletonといいつつFactory風でもありますね。
そういうニーズがある場合には、確かに意義がある気がします。

あまりそういうケースが多くは無い気はしますが。

269:デフォルトの名無しさん
05/06/25 01:40:49
デザパタ役に立って無いよ。
そろって馬鹿だな。
デザパタとか別にしても。

270:259
05/06/25 01:40:47 BE:379290896-
>>260
いまいちやりたいことが分からないなぁ…。
Singletonが1種類のオブジェクトしか返さなくて、
将来その仕様に変更がないと言い切れるなら
いっそ状態もstatic管理でいいと思う。要するにSingleton不要。

デザパタは仕様変更に柔軟に対応するための手段だと思うから。

271:デフォルトの名無しさん
05/06/25 01:42:57
>>264
このスレ読んでると、どんどん悪い癖、迷信に染まっていく傾向があるな。
状態はグローバル変数だから駄目？
それはあんたの信念であって、広く認められているSingletonの定義より狭いやん。
例えばアプリケーションの設定を Singletonに置くとして、
設定を変更する事は充分ありえる。つまり、Singletonに状態を持たせる事は充分有り得る。

GoF日本語版 p138
◎結果
Singletonパターンの効果を次にあげる。

1.インスタンスへのアクセスを制御する。(詳細略：唯一のインスタンスなのでアクセスチェックが簡単)
2.名前空間を減らす。Singletonパターンはグローバル変数の改良である。唯一のインスタンスを格納するグローバル変数 (注: C++, Smalltalk)を宣言する必要はなくなる。
3.オペレーションや内部表現を詳細化できる。(詳細略：Singleton のサブクラス化に関する話)
4.インスタンスの数を変えることができる。(詳細略：インスタンス数を２つ以上に変更する事も容易)
5.クラスオペレーションよりも柔軟である。(詳細略)

272:デフォルトの名無しさん
05/06/25 01:43:38
>>270
Visitorが状態を持たないとき、
それでもオマイさんは
Visitorをnewしますか？

273:234
05/06/25 01:43:59
>>270
いやその、「仕様変更」に対するデフォルトの対応が「継承」である、
というほうがぼくにとっては不自然なのですが。

たとえばオブジェクトのシリアライズ方式がv1とv2で変わっていて
両者に対応しなければならない、とかいうケースであれば、継承を
使うのは理解できます。

しかし、そもそも「唯一」であったものに、「継承」を適用するケース
って、そんなに多いのかな、と。普通、継承は、複数のものの差異を
選択的に無視したい場合に用いますよね。単純化のしすぎですが。

274:デフォルトの名無しさん
05/06/25 01:45:29

　　つまりさ、このスレの白熱議論っつうのは、
　　すべからく >>264みたいな素人の迷信暴言が発端なわけ。

　　くだらねぇんだよおまぃらの議論は

275:デフォルトの名無しさん
05/06/25 01:45:47
>>271
GoF本にはそんなこと書いてなかったけど
一体いつ定義されたの？

276:234
05/06/25 01:45:57
ぼくのほうが知

277:デフォルトの名無しさん
05/06/25 01:46:13
>>274
面白い議論ｷﾎﾞﾝ

278:デフォルトの名無しさん
05/06/25 01:46:26
>>275
　恥を知れクズが

279:234
05/06/25 01:46:38
とぎれた
ぼくのほうが素人だもん

とか書こうとしたのに

280:デフォルトの名無しさん
05/06/25 01:48:33
>>278
かかってこいよ厨房ｗ

281:デフォルトの名無しさん
05/06/25 01:48:39
>>266=>>234
おまぃは誤爆してる上、
>>234の定義で>>243するとNullPointerExceptionがおきるつう認識もない・・・
・・・Singleton書いた事あるぅ？(>>262を参照汁)

282:デフォルトの名無しさん
05/06/25 01:49:13
>>267
差分プログラミングと開放/閉鎖原則で検索。

283:デフォルトの名無しさん
05/06/25 01:49:47
>>280は底知れない白痴厨房。GoF本手元に置かずにそんな煽りやってるとは抱腹絶倒だな。

284:234
05/06/25 01:50:29
>>281
あ、>>234の例はただの非常に単純化した例ですので。

いいたいことは、メンバを全てstaticで実装し、初期化はstaticコンストラクタ
で行うようなクラスをSingletonの変わりにして何かまずいのか？
ということに過ぎません。

285:デフォルトの名無しさん
05/06/25 01:51:10
>>271の該当ページを読んでみたらぁ？

286:234
05/06/25 01:52:42
>>282
メイヤー先生ですか。
私としては、もう使いもしないv1のコードが残っているのは違和感を感じますがね。

それに、元のデザインが非常によくできていて、適切なフックなどが容易されていない
限り、継承してメソッドをオーバーライドするより元のメソッドそのものを
書き換えることのほうが容易であることも多い気がします。

287:234
05/06/25 01:53:59
実際、バージョンアップの際に常に継承で対応するという開発手法は
どれぐらい一般的なんでしょうか？

もとのクラスを書き換えるのは、邪悪？
open/close原則を厳密に適用すれば、そういうことになってしまいますね。

288:デフォルトの名無しさん
05/06/25 01:54:51
で？
好きにすりゃえーやん。
漏れは藻舞を説得するつもりはねぇ～し

289:259
05/06/25 01:55:54 BE:189645293-
>>234はSingletonにこだわらないほうがいいと思われ。
もうこれは個人個人の開発スタイルなので。

それでも共同開発時はSingletonをお勧めしたい。

290:デフォルトの名無しさん
05/06/25 02:00:01
>>287
アンチの俺から言わせると、
一般的なわけねーだろ。
あきらかに継承の使い方を間違ってる上に悪用としかいいようがない。
アホだアホ。マジで救いようがねー。

291:デフォルトの名無しさん
05/06/25 02:03:49
哀れなもんだ
煽れる時に煽るだけで、
中身は空っぽだもんな、おまえ

292:デフォルトの名無しさん
05/06/25 02:04:28
>>268
仮想コンストラクタはファクトリとシングルトンの合わせ技だから

ニーズは普通にあると思うよ。
オセロの例に戻ると、プレーヤーを動的に変更したいというのは自然でしょ？

293:234
05/06/25 02:04:40
ぼくは、あおりじゃないんだもん(; ;)

294:デフォルトの名無しさん
05/06/25 02:05:42
>>291
オマエモナーｗ

295:デフォルトの名無しさん
05/06/25 02:06:35
>>284
1つのクラスが複数のstaticメンバ変数を管理するのはいくない。

次ページ