多所で利用される変数の持ち方

[ちう]

こんばんわ。ちうと申します。
今回は、「多所で利用される変数の持ち方」について質問したいと思います。

/*画像*/


まずは画像をご覧ください。
これは、横スクロールアクションゲームに必要な、クラスを図式化したものです。
とはいえ、厳密なクラス図ではなく、あくまで全体でこんなまとまりをしているのだなというものを理解するための物なので
本来の記法などとは間違っていたりすると思います。

次に、簡単にゲームの流れについて説明します。
クラス名の横に赤い色をした番号が割り振られていると思いますが、
①はじめから、つづきからを選択すると9番のStoryGameクラスが実行されます
②StoryGameクラス内では16番のマップセレクトクラスが実行され、そこでステージを選択するとステージ番号をどこかしらのクラスに保存しておきます（ここが分からないので、あいまいに書いておきます。
③ステージが選択されたので、マップセレクトクラスを解放し、23番のPlayMainクラスを生成します。このクラスでは、
　実際にステージ上でキャラクターを動かして遊ぶ部分に当たります。
④PlayMainクラスが委譲するクラスでは「ステージ番号」が必要になる箇所が多数あります。
　例えば、
・28番のClearクラスでは、〇（番号が入る）ステージクリア！といった表示をしたい
・41番のMapでは、〇〇のステージ情報をロードする必要がある。
・そのほか、そのステージごとに必要な情報をロードする必要がある。

そこで、質問に戻りますが、このステージ番号(int型)の変数はどのように保持すればいいのでしょうか。
少なくともステージを選択した時点で、StoryGameクラスにいったん保持しなければならないと思います。
なぜなら、StoryGameではStateパターンを用いているため、MapSelectからPlayMainクラスに遷移する際に
必ずMapSelectクラスが解放されるからです。

私が考えた限りでは、２つあります。
(i)
PlayMainがStoryGameのポインタを変数(parent)として保持すれば、parent -> getStageID();
といった書き方で書くことが出来ます。
しかし、その方法で行くと、41番のMapクラスがステージ番号を知るには
getStage() -> getPlayMain() -> parent -> getStageID();といった非常に長ったらしいことになってしまいます。
それならまだいいのですが、自分のクラスを委譲しているクラスへアクセスしてしまうため、constでない他の
メソッドにもアクセスできてしまうのが、いわゆるカプセル化の概念を壊してしまうのが気になるところです。

(ⅱ)
それぞれのクラス内でステージ番号を変数として保持してしまう。
StoryGameクラス内でPlayMainクラスのインスタンスを生成する際に引数として渡してあげます。
更に、PlayMain内で、Stageクラスを生成する際には、PlaymMain::stageIDを引数としてコンストラクタに渡す。
といったように、逐一渡してあげる方法です。
欠点としては、同じ情報が複数のクラスに散らばっている。仮にPlayMain内でステージ番号が変更されると
考えると、それに対応するすべがない。

どちらもあまりいい方法ではありません。

この問題に対する回答をよろしくお願いします。

[h2so5]

場合にもよりますが、基本的には (ii) の方法が良いと思います。
いつ更新されるかわからないような情報を分散させると確かにわかりにくくなりますが、
ステージ番号はステージ構築時に確定しているので、ステージを構成しているオブジェクトが個別に持っていても問題は少ないです。

欠点としては、同じ情報が複数のクラスに散らばっている。仮にPlayMain内でステージ番号が変更されると
考えると、それに対応するすべがない。

ステージ番号が変わる場合は、ステージIDに依存しているオブジェクトをすべて再構築すればよいです。

[追記]
それと、例えばMapクラスでは構築時にステージの情報が必要なだけで、ステージ番号を保持している必要性はないですよね。

[ちう]

h2so5さん、回答ありがとうございます。

確かに（ⅱ）の方法が、自分のクラス内に情報をおいておけるため、
後々楽が出来ますし、変更されないという保証を付けておけば、
そこまで困るものでもなさそうです。

あと、追記に書いてくださった、「もし、途中でStageIDが変わったら」というのは、私の悪い癖で、【オブジェクト指向として書くからにはとにかく再利用性を】ということに固執しすぎて必要以上に万能性や柔軟性を考えてしまうのです。
特にゲームプログラミングにおいては再利用性ばかり考えていると
泥沼にはまりかねないので、ほどほどにしておいた方が良さそうです。