[過去ﾛｸﾞ] ゲームにおけるデータ構造・クラス設計・パターン2 (627ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
320: 318 2008/08/28(木)00:48 ID:Z+eKsEJG(1/4) AAS
>>319
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか？
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。
328(1): 318 2008/08/28(木)17:59 ID:Z+eKsEJG(2/4) AAS
>>321,322
汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな〜と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたｗ)。
完成させることが第一と思っていてもついつい・・。
>>323,327
stateパターンですよね？
省3
334: 318 2008/08/28(木)21:30 ID:Z+eKsEJG(3/4) AAS
>>329
コードの正しさ、綺麗さの２つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの３つがあると思っています。
今問題にしてるのは、主にこのうち後者２つです。
ただ、読みやすさは人それぞれなのかもしれません。
>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。
338: 318 2008/08/28(木)23:04 ID:Z+eKsEJG(4/4) AAS
>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。
>>336
省2
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.306s*