StatePatternを使って簡単に組んでみたつもり。マネージャと状態の親子だけなので、必要最小限かな。ついでにアップロードできるかテストも兼ねます。一部関数化するのが面倒でコピーペーストで済ませた部分あり。今週中にもうちょっと進めたかったなぁ・・・shared_ptrが思っていたよりだいぶ便利。auto_ptrとは桁違いに楽・・・・・　配列と循環参照に注意だったかな。




　　「PCには触れられないが、空いた時間がある」なんて時にも設計を考えて、コーディングできるときには、コードを書くだけ、というのが一番理想的なのかな。大体バグや知らないことで時間食うんだろうけど。


　　今回作ってみた物を参考にして、ゲームの設計を考えてみると、StatePatternとそのマネージャ，窓口,状態たち,で「ある状態の操作」を扱う構造が階層をつくり、木構造のような設計図になった。状態の切り替えはよほど小さくない限りStatePatternで作る・出来るだけ互いのクラスの依存性を下げる、という構造を目標としたからクラス数が膨れ上がった。把握している条件の切り替えに関係するものだけで60近い。大丈夫か・・・？　　似たような構造も少なくないから半分くらいに減らせないかな・・・

　　切り替え制御のManager,外部からの情報窓口Facade，状態親クラスあわせて3個,そして子クラスN個。ひとつの状態の切り替えだけでN+3個のクラスってどうなの・・・　相場が分からない。　　
　　Stateの子クラスをさらに継承して状態ごとの実装のクラス作るということも考えたけど、う～ん。切り替えと切り替えられる状態は相互に依存しないとは思うけど、まとめてしまっても今回くらいなら問題なさそう。ゲームくらい大規模だと分けるべきかな。

　　とりあえずmainだけ。不要なファイルをincludeしたままになっているのは過去の名残・・・　　この部分はすごくすっきりしてよかった。 　　興味があればコードをご覧いただき、ついでに評価していただけるとありがたいです。個人的にReceiveとRenewはまだきれいになると確信しています。今回はちょっと避けました。どうやったら良いのかよく分からないのが切り替え処理と状態からマネージャへの情報伝達。今回前者はフラグ,後者はint型返り値で実装。フラグで管理して良いのか,例外やエラーの状態も用意したほうが良いのか,int型で状態を知るのは直感的じゃない等・・・　　　　　状態子クラス型返すのが直感的？