- 1 名前：デフォルトの名無しさん mailto:sage [2005/06/21(火) 19:09:56 ]
- そもそもデザインパターン自体どうなのよ？って話はここでやれ。
- 196 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 10:49:06 ]
- 細かいところは分からないけど、全体的にMVCっぽくなりそうな...
- 197 名前：194 mailto:sage [2005/06/24(金) 11:30:53 ]
- >>195
複雑なスコアシステムだったとしても、
オブザーバに報告する内容をすこし増やせばいいんでない？
シングルトンだと、設定によるスコアシステム自体の切り替えはきつそうな希ガス。
- 198 名前：デフォルトの名無しさん [2005/06/24(金) 21:25:27 ]
- >>194
>敵オブジェクト自身が死んだときに
ゲームだとこの死んだときってのが微妙でね。
オブジェクト自身が本当に消滅したときなのか、
敵が死体で転がってる状態なのか、ってのは微妙でしょ。
だから、ゲームの仕様でインスタンスだのオブジェクトだのが出てくる人間の
プログラムはちょっと気を付けてみることにしてるｗ
もし、部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
俺の環境だと即組み直しｗ
まあ、将来の為。
あ、これはデザパタとかオブジェクト指向とか関係無いから。
- 199 名前：デフォルトの名無しさん [2005/06/24(金) 22:33:12 ]
- > 部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
意味不明。
- 200 名前：デフォルトの名無しさん [2005/06/24(金) 22:58:38 ]
- >>199
そのままの意味だけど？
これ以上詳しくはできない。
- 201 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:05:28 ]
- 単に死体になってるだけ＝ただの状態変化
実際にゲームから消滅した＝オブジェクトの消滅
として設計され、管理されているなら
> インスタンスの消滅を見てゲームを動かし
ていても問題ないのでは？
- 202 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:06:02 ]
- SE にとって重要な能力の一つは 自分の考えを簡潔かつ適切に他人に伝える だと思う
- 203 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:07:08 ]
- >>202
違うな。
どんな人間にも平気で嘘がつける度胸だ。
- 204 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:08:52 ]
- >>201
それが駄目なことについて延々と語るつもりは無いな。
いいと思うなら自由にやってくれ。
- 205 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:09:46 ]
- 平気で嘘がつける = 適切に
- 206 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:10:32 ]
- SEなんて日本だけの腐れ職業のことなんざどうでもいいよ
- 207 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:11:14 ]
- またゲームかよおまえら
ゲームつくるのにデザパタはたいしていらんぞ
- 208 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:12:22 BE:393339078- ]
- 平気で嘘をつけない奴のほうが稀な気が。
- 209 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:13:26 ]
- そうだな日本は偽装派遣天国だしな
まあ面接でちゃんと問い詰めればすぐバレるけどな
問い詰めちゃいかんらしい
- 210 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:14:51 ]
- >>201
ポインタ使いまわしてて、消滅したはずのオブジェクトが復活する（したように見える）バグがでるに一票。
危険な道は避ける。
これがわからない人間にゲームプログラマは難しい。
- 211 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:17:34 ]
- >>210
それはメモリ管理が出来ていないと言っているに等しいと思うんだが....
- 212 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:22:40 ]
- >>211
メモリの管理はできてるでしょ。
メモリは破壊していないし、はみ出してもいない。
ただ、ポインタを使いまわしてしまっただけの話さ。
まあ、敵クラスを作った人間以外の人間が敵クラスを使うときは要注意といったところだね。
鉄則としてヌル判定をするポインタの使い回しは死んでもしないとか、
就業規則に書いておけば自分の責任にならなくて済むと思うよ。
- 213 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:24:05 ]
- >>194
ん〜、結局同じな気がする。
一瞬、変更に対して強いかな？とも思ったんだけど、「必要そうな情報」に幅がないし
幅を出すと結局変更が両者に及ぶから変わらない。
キャラクタ→スコアシステム#update→キャラクタ#getScore
これ以外の流れというのがちょっと見えてこない。
>>197
元発言者の意図とかみ合ってるかは不明なんだけど・・・・・・
シングルトンをファクトリに生成させるパターンなら切り替えは可。
ScoreSystem scoreSystem = new ScoreSystemFactory(設定)
もう常套句すぎてアレなんだけど、こんな感じ。
- 214 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:35:04 BE:568936499- ]
- Factoryをnewするのか？(･∀･)ﾆﾔﾆﾔ
隔離スレがパターンの話題で盛り上がって
本スレがスレッドストップとはこれいかに。（ﾟεﾟ）ｷﾆｼﾅｲけどな。
- 215 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:35:56 ]
- >>212
それは、ダングリングポインタを参照してしまったということだから、
広義ではメモリ管理が出来ていないに等しいと思う。
本来、誰かが使っているならそのポインタは削除してはいけない。
ま、それを完全に保証することはしばしば非常に困難であったり
不可能であったりするのは事実だが
- 216 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:38:44 ]
- メモリ管理できてねぇだけじゃん
インスタンスの生成、消滅の責任とタイミングをキチンとしないからそうなる
- 217 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:40:13 ]
- >>214
あっ！orz
うるせ〜、超省略表記なんだよヽ(`Д´)ﾉｳﾜｧｧﾝ
- 218 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:40:14 ]
- >>216
でも、この場合は誰の責任になるの？
敵クラス？敵管理クラス？メモリ管理クラス？
- 219 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:42:05 ]
- >>215
でしょ。ポインタ頼みのステータス管理なんてやらないにこしたことないんだよ。
- 220 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:42:38 BE:505721489- ]
- ところで複雑なスコアシステムってどんなのがあるの？
あんまりいろんな種類のゲーム知らないから単純なポイントの加算しか思い浮かばない。
- 221 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:45:10 ]
- >>219
いや、それはいいすぎ....
まあ、参照関係が複雑な有向巡回グラフみたいになると手におえなくなりがちなのは
確かだが、常にそうだというわけではないし、参照カウンタで済む場合は
それを使うという手もある。
- 222 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:45:12 ]
-
ゲームの場合例えば敵キャラが消滅したら即deleteするのはありえない
ゲームタスクのループ内で自機が参照してるかも知れないし
他の敵も参照してるかもしれない
敵キャラに消滅フラグなりなんなり持たせて
ゲームタスクのループとは別フェイズで実際にdeleteなりメモリプールに戻すなりする
ってデザパタ関係ないな
- 223 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:45:31 ]
- ボーリングは少しメンドイ。
マージャンとかかな。
- 224 名前：222 mailto:sage [2005/06/24(金) 23:45:54 ]
- >>220
- 225 名前：223 mailto:sage [2005/06/24(金) 23:46:46 ]
- 222すまん、ﾚｽつくの速すぎて慌てた。
>>220
- 226 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:49:47 ]
- >>221
でも本音ではしっかりステータス管理してもらったほうがいいでしょ。
よくないよ。議論に勝つ為のレスなんてつけるもんじゃない。
- 227 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:52:12 ]
- >>226
なぜだッ！！
なぜ貴様に俺の心が読み取れるんだッ！！！
- 228 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:52:25 ]
- >>223
マージャンとインベーダーの間で再利用するの？
されは流石に無理ないか？
- 229 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:55:43 BE:442506097- ]
- >>223
あぁ、なるほど。
敵の消滅とかの話が出てたから、
シューティングっぽいゲームばかりを想像していたヨ。
>>228
マージャンだと点数の計算方法が複数ある…気がしたような気がしないような。
なので切り替えられると便利かもしれない。
- 230 名前：デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:56:50 BE:168574346- ]
- さすがに異種ゲームの点数計算クラスを共有しようとは誰も考えないと思うので。
- 231 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:16:23 ]
- >>214
相変わらず僻みっぽい馬鹿だな。
とりあえず
pc8.2ch.net/test/read.cgi/tech/1119158274/14-15
のリンク先くらい読んでから煽れクズ
- 232 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:20:00 ]
- 結局、>>198からの議論は、「オブジェクトを（ゲーム上）消したことに
すべきタイミングと、実際に消していいタイミングは必ずしも一致しない」
（通常後者のほうが遅い）
ということに尽きるのかな。
一言で言えるんだから、一言で言えばいいのに。
- 233 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:21:35 ]
- まぁ、>>213がド素人なのは誰の目にも明らかだがなｗ
Singletonの生成にはコンストラクターを使わない。つまり、getInstance()とかで生成する。
Factoryの目的は、どのサブクラスのインスタンスを生成するか、という点を抽象する事にある。
- 234 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:30:39 ]
- スルー。
- 236 名前：214 mailto:sage [2005/06/25(土) 00:34:49 BE:210717465- ]
- >>231
相変わらず汁が先走ってるな。
とりあえず >>213-214 >>217 の流れを見て
自分の過ちと傲慢さを理解して恥じろ。
- 237 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:36:54 BE:126431429- ]
- >>232
注意点は一言で言えるが実装は一言で言えないぜ。
- 238 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:39:54 ]
- >>237
流石に実装まで示せとは誰も言ってないじゃまいか。
- 239 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:41:23 ]
- >>238
もう、日本は終わったんだよｗ
- 240 名前：237 mailto:sage [2005/06/25(土) 00:44:23 BE:505721298- ]
- >>238
>>198-〜の実装の議論は少し有意義に見えたが。
- 241 名前：234 [2005/06/25(土) 00:49:32 ]
- 華麗にスルーされちゃってぼくちん少し寂しいの
てへ
- 242 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:53:55 ]
- >>241
俺はアンチなんだけど
それって実体はいつできるんだ？
呼び出す前からできちまってる気がしねぇ？
- 243 名前：234 mailto:sage [2005/06/25(土) 00:56:37 ]
- コンストラクタはstaticにすればいいんじゃまいか
つか、それだけの問題で
まいかい
Singleton timpo = Singleton.getInstance();
bokkiage = timpo.invoke();
とかやるのはいやです。
- 244 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:57:06 ]
- 目的は「インスタンスを1つに固定する」だからいいじゃん
- 245 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:57:15 ]
-
華麗なる素人スレ
- 246 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:58:12 ]
- >>243
bokkiage = (Singleton.getInstance()).invoke();
- 247 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:59:32 ]
- >>234
仮想コンストラクタで検索。
一般に、クライアントコードが簡素になる点と
融通が効く点が利点して上げられてる。
- 248 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:00:36 ]
- >>243
それじゃおめ、
そうやって組んだしんぐるトンは通る可能性のあるものに関しては実行時にすべて生成されてしまうわけだな？
つ 逝ってよし
- 249 名前：234 mailto:sage [2005/06/25(土) 01:02:39 ]
- >>247
継承を考えてなんとなく柔軟性を持たせたいというのは分かりますが
実際には、継承なんかしないクラスこそシングルトンの候補であることが
非常に多い気がします。
その場合には、闇雲にシングルトンにせずとも構わないんでしょうかね。
「クライアントコードが簡素に成る」については全く納得がいきません。
メンバがstaticであれば
(Singleton.getInstance()).invoke();
ではなく
Singleton.invoke();
と書けるでしょう。
- 250 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:04:50 ]
- まあ、いつみてもデザパタは役に立たないよね。
- 251 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:06:04 ]
- なんでSingletonの話題しか振れないの？
重箱の隅しか突付けない哀れな煽りだ
- 252 名前：234 mailto:sage [2005/06/25(土) 01:07:00 ]
- ぼく、あおりじゃないのに(; ;)
- 253 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:07:14 ]
- ======================================================================
このスレは厨房を隔離するための隔離スレです。。。
======================================================================
- 254 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:07:54 ]
- >>234 → >>243 → ぬるぽ
- 255 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:16:10 ]
- >>252
お前はネタｗ
- 256 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:20:06 ]
- >>249
インベーダーの例に戻って言うと、当初のスコアシステムに
ハイスコアの記録機能を追加した新スコアシステムを作る
場合、継承するのが妥当なんじゃない？
- 257 名前：234 mailto:sage [2005/06/25(土) 01:21:39 ]
- >>256
その場合、旧スコアシステムと新スコアシステムが共存しないのであれば
継承する必要は無いと考えますが。
- 258 名前：234 mailto:sage [2005/06/25(土) 01:22:03 ]
- >>255
ぼくでおなにーとかはしないでください
こわいので
- 259 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:24:55 BE:245837257- ]
- 単なる関数郡として使うだけならstaticでいいと思う。
- 260 名前：234 mailto:sage [2005/06/25(土) 01:26:34 ]
- >>259
それは、いわゆるUtilityクラスのような、状態の存在しないものですね。
それについて異存のあるひとはいないとおもいます。
ぼくがいっているのは、状態が存在するが、システムでユニークなクラス
のことです。とゆうか、Singletonというのは、そのようなものでしょ？
- 261 名前：234 mailto:sage [2005/06/25(土) 01:27:07 ]
- > システムでユニークなクラス
ちょっとはしょりすぎた
すみません、酔っているので
- 262 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:30:31 ]
- まぁ文字列渡すよりは、
・コンフィギュレーション選択用の定数か、
・コンフィギュレーションを表すオブジェクト
を渡すべき
- 264 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:32:54 ]
- >>260
それは「グローバル変数」だ。悪。
シングルトンでは「状態のないもの」を表現する。
たとえば、「ストラテジーパターン」で使うストラテジーオブジェクトとか、
「ステートパターン」で使うステートオブジェクトとか。
「ファクトリー」もそうだ。
- 265 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:34:21 ]
- >>257
オブザーバーパターンとのかみ合わせを考えてみて。
public class Enemy {
addObserver(ScoreSystem ss) {}
}
↑こうなってた場合、継承が必要。
public interface Observer {}
public class Enemy {
addObserver(Observer observer){}
}
↑こうしとかないオマイが馬鹿と言われれば、だよね〜
としか言い様がない気もするが・・・・・・
- 266 名前：234 mailto:sage [2005/06/25(土) 01:34:27 ]
- >>254
え？
ぼくの認識では、メンバ変数はすべからく「状態」だと思っているのですが
間違いですか？
なんか、ちょっとはつみみな所見です。
- 267 名前：234 mailto:sage [2005/06/25(土) 01:36:31 ]
- >>265
いやその、共存する必要が無いのであれば、インタフェースを変えずに
スコアシステムの「実装」を変えればいいだけなのではないかと。
なにか勘違いしていますか？ぼくは
- 268 名前：234 mailto:sage [2005/06/25(土) 01:37:33 ]
- >>262
それはちょっとSingletonといいつつFactory風でもありますね。
そういうニーズがある場合には、確かに意義がある気がします。
あまりそういうケースが多くは無い気はしますが。
- 269 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:40:49 ]
- デザパタ役に立って無いよ。
そろって馬鹿だな。
デザパタとか別にしても。
- 270 名前：259 mailto:sage [2005/06/25(土) 01:40:47 BE:379290896- ]
- >>260
いまいちやりたいことが分からないなぁ…。
Singletonが1種類のオブジェクトしか返さなくて、
将来その仕様に変更がないと言い切れるなら
いっそ状態もstatic管理でいいと思う。要するにSingleton不要。
デザパタは仕様変更に柔軟に対応するための手段だと思うから。
- 271 名前：デフォルトの名無しさん [2005/06/25(土) 01:42:57 ]
- >>264
このスレ読んでると、どんどん悪い癖、迷信に染まっていく傾向があるな。
状態はグローバル変数だから駄目？
それはあんたの信念であって、広く認められているSingletonの定義より狭いやん。
例えばアプリケーションの設定を Singletonに置くとして、
設定を変更する事は充分ありえる。つまり、Singletonに状態を持たせる事は充分有り得る。
GoF日本語版 p138
◎結果
Singletonパターンの効果を次にあげる。
1.インスタンスへのアクセスを制御する。(詳細略：唯一のインスタンスなのでアクセスチェックが簡単)
2.名前空間を減らす。Singletonパターンはグローバル変数の改良である。唯一のインスタンスを格納するグローバル変数 (注: C++, Smalltalk)を宣言する必要はなくなる。
3.オペレーションや内部表現を詳細化できる。(詳細略：Singleton のサブクラス化に関する話)
4.インスタンスの数を変えることができる。(詳細略：インスタンス数を２つ以上に変更する事も容易)
5.クラスオペレーションよりも柔軟である。(詳細略)
- 272 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:43:38 ]
- >>270
Visitorが状態を持たないとき、
それでもオマイさんは
Visitorをnewしますか？
- 273 名前：234 mailto:sage [2005/06/25(土) 01:43:59 ]
- >>270
いやその、「仕様変更」に対するデフォルトの対応が「継承」である、
というほうがぼくにとっては不自然なのですが。
たとえばオブジェクトのシリアライズ方式がv1とv2で変わっていて
両者に対応しなければならない、とかいうケースであれば、継承を
使うのは理解できます。
しかし、そもそも「唯一」であったものに、「継承」を適用するケース
って、そんなに多いのかな、と。普通、継承は、複数のものの差異を
選択的に無視したい場合に用いますよね。単純化のしすぎですが。
- 274 名前：デフォルトの名無しさん [2005/06/25(土) 01:45:29 ]
-
つまりさ、このスレの白熱議論っつうのは、
すべからく >>264みたいな素人の迷信暴言が発端なわけ。
くだらねぇんだよおまぃらの議論は
- 275 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:45:47 ]
- >>271
GoF本にはそんなこと書いてなかったけど
一体いつ定義されたの？
- 276 名前：234 mailto:sage [2005/06/25(土) 01:45:57 ]
- ぼくのほうが知
- 277 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:46:13 ]
- >>274
面白い議論ｷﾎﾞﾝ
- 278 名前：デフォルトの名無しさん [2005/06/25(土) 01:46:26 ]
- >>275
恥を知れクズが
- 279 名前：234 mailto:sage [2005/06/25(土) 01:46:38 ]
- とぎれた
ぼくのほうが素人だもん
とか書こうとしたのに
- 280 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:48:33 ]
- >>278
かかってこいよ厨房ｗ
- 281 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:48:39 ]
- >>266=>>234
おまぃは誤爆してる上、
>>234の定義で>>243するとNullPointerExceptionがおきるつう認識もない・・・
・・・Singleton書いた事あるぅ？(>>262を参照汁)
- 282 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:49:13 ]
- >>267
差分プログラミングと開放/閉鎖原則で検索。
- 283 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:49:47 ]
- >>280は底知れない白痴厨房。GoF本手元に置かずにそんな煽りやってるとは抱腹絶倒だな。
- 284 名前：234 mailto:sage [2005/06/25(土) 01:50:29 ]
- >>281
あ、>>234の例はただの非常に単純化した例ですので。
いいたいことは、メンバを全てstaticで実装し、初期化はstaticコンストラクタ
で行うようなクラスをSingletonの変わりにして何かまずいのか？
ということに過ぎません。
- 285 名前：デフォルトの名無しさん [2005/06/25(土) 01:51:10 ]
- >>271の該当ページを読んでみたらぁ？
- 286 名前：234 mailto:sage [2005/06/25(土) 01:52:42 ]
- >>282
メイヤー先生ですか。
私としては、もう使いもしないv1のコードが残っているのは違和感を感じますがね。
それに、元のデザインが非常によくできていて、適切なフックなどが容易されていない
限り、継承してメソッドをオーバーライドするより元のメソッドそのものを
書き換えることのほうが容易であることも多い気がします。
- 287 名前：234 mailto:sage [2005/06/25(土) 01:53:59 ]
- 実際、バージョンアップの際に常に継承で対応するという開発手法は
どれぐらい一般的なんでしょうか？
もとのクラスを書き換えるのは、邪悪？
open/close原則を厳密に適用すれば、そういうことになってしまいますね。
- 288 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:54:51 ]
- で？
好きにすりゃえーやん。
漏れは藻舞を説得するつもりはねぇ〜し
- 289 名前：259 mailto:sage [2005/06/25(土) 01:55:54 BE:189645293- ]
- >>234はSingletonにこだわらないほうがいいと思われ。
もうこれは個人個人の開発スタイルなので。
それでも共同開発時はSingletonをお勧めしたい。
- 290 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:00:01 ]
- >>287
アンチの俺から言わせると、
一般的なわけねーだろ。
あきらかに継承の使い方を間違ってる上に悪用としかいいようがない。
アホだアホ。マジで救いようがねー。
- 291 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:03:49 ]
- 哀れなもんだ
煽れる時に煽るだけで、
中身は空っぽだもんな、おまえ
- 292 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:04:28 ]
- >>268
仮想コンストラクタはファクトリとシングルトンの合わせ技だから
ニーズは普通にあると思うよ。
オセロの例に戻ると、プレーヤーを動的に変更したいというのは自然でしょ？
- 293 名前：234 mailto:sage [2005/06/25(土) 02:04:40 ]
- ぼくは、あおりじゃないんだもん(; ;)
- 294 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:05:42 ]
- >>291
オマエモナーｗ
- 295 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:06:35 ]
- >>284
1つのクラスが複数のstaticメンバ変数を管理するのはいくない。
- 296 名前：234 mailto:sage [2005/06/25(土) 02:07:54 ]
- >>292
ニーズは、あるでしょうね。
ぼくは、実はSingletonでなくていいのに
「いまどきSingletonじゃないと、女のコにモテないぞ」
「グローバル変数はダサ！Bjarne stroustrupが何と言おうと絞め殺せ」
「static記憶クラス？そんなん、石器時代の遺物でしょ？」
とかそんな理由でSingletonにされているケースも、結構おおいんじゃないの？
と、そういいたかっただけです。
|
 |
