StateパターンでContextクラスを継承するときの設計について

Question

前提・実現したいこと

現在デザインパターンの勉強としてStateパターンを使ってゲームを作っています。
StateパターンのContextをCharacterとし、Stateという抽象クラス（インターフェイス）を作って。そこからidle,runや,jump,sliding,Climb...といった感じに派生して作っています。そしてCharacterクラスでStateを持って、、、といったおそらく普通のStateパターンを組んでいます。

しかし、今回はContextであるCharacterクラスを継承してPlayer、enemyクラスを作ることにしました。Player、enemyも同じステータスが必要です。
現在悩んでいることはPayerにしか必要ないが、stateに渡してその中で変更したい変数をどうするかというのに悩んでいます。

該当のソースコード

//stateの抽象クラス
#include "Character.h"

class Character;
class State
{
public:
	virtual ~State() {};
	virtual State* handleInput(Character& chara,int input) = 0;//inputを受け取って次のステータスを返す
	virtual void update(Character& chara) = 0;//更新処理
	virtual void enter(Character& chara) = 0;//ステータス変更時に一回だけ呼ばれる
};

//Characterの抽象クラス player,enemyクラスに継承
class Character
{
protected:
/*
*座標や回転など基本的な情報
*/
	State nowState;

/*!!playerにしかいらない変数!!*/
int height

public:
	virtual ~Character() {};
	virtual void Initialize() = 0;//初期化
	virtual void handleInput();//state->handleInputから帰ってきたステータスをnowStateに格納
	virtual void update();//nowState->update
	void render();

試したこと

現在はCharacterクラスの中に入れましたが、明らかに間違いだと思います。
そもそもstateパターンを使うべきではないのか、別々に作る必要があるのか、知らないだけで回避方法があるのか自分では判断がつかないため質問させてもらいました。

補足情報（FW/ツールのバージョンなど）

今回はplayerが座標をカメラに渡すためのゲッターがあり、座標のy軸＋変数heightでカメラの座標を決めます。
heightはsliding時に小さくなって、ほかのステータスに行くときに戻る、といった感じです。

他にもplayerにしか必要のない変数はありますが今回は省略しています。

もしよろしければ回答のほどよろしくお願いします。

Answer 1

(1)

playerにしか必要のない変数

に関して，「Stateがどうの」という関係ない話を抜きにして考えてみる．

• Characterクラスを継承してPlayer、enemyクラスを作る
• playerにしか必要のない変数がある

この条件で，「playerにしか必要のない変数」をCharacterに持たせるんですか？っていう．
Playerに必要なものはとりあえずPlayerに持たせればどうか．

(2)

あとは，「Stateがどうの」の話を解決する．
「CharacterのState」という話の括りで扱える話なのか？という．
「PlayerのState」「enemyのState」という話にすることも考えられると思うが，それではダメなのか．

Comments

[yukisyuki]

と言うことは、例えば全く同じ内容ならtemplateなどを使って書いてplayer用とenemy用で別なものは別に書くみたいな感じですかね？

[fana]

事情がよくわからんけど，
PlayerはPlayerの，enemyはenemyの，それぞれ何か固有の事情等々があるのろうから，
それぞれ個別に自由に実装すればいいわけで．

対して，今の形は「Character を継承すると，Stateパターンがもれなく付いてきます」という "縛り" を設けることによって不自由しているように見える．
不自由になるなら Stateパターン とか要らないのでは．

Player の内部実装の具体的な手段として Stateパターン を使うのだとして，
そのことを無関係な enemy にまで強要しなくてもよいのでは？

enemyもまた実装手段に Stateパターン を用いるかもしれないけれども，それはたまたまであって，「共通の事柄」として括り出すようなことではないのでは．
（Playerとenemyは「どちらも Character である」という関係であって，「どちらも Character であり，且つ，その内部実装は Characterに実装されている State パターンによってどうのこうの」という関係にまでする必要が無いのではないかと．）

[fana]

Playerやenemyにどれだけの数の状態があるのか知らないけれども，
"Stateパターン" を持ちこむことで，｛実装難易度，可読性，保守性，etc｝にどれだけ良いことがあるのかを考えた方が良いかもしれない．
（e.g. 「Stateを切り替える方法はどうするのか？」とか無意味に考えることだけが増えてしまって利の方が少ない，とかならやめる）

・状態数はたかだか数パターンであって
・必要な状態の種類は既にほぼ出揃っており（今後どんどん未知の状態が増えていくようことはない）
・状態による分岐があると言ってもまぁ単純な処理分岐でしかなくて
・現状態を参照する分岐が現れるのは，せいぜい Update(), Render() の２か所である

みたいな話であれば，「それもう switch とかで書いても良くね？」というのも有りなのではないかな，とか．

（まぁ，「現在デザインパターンの勉強として…」という話なので，パターンを使うことがまず前提としてあるのかもしれないけれども，使ってみるなら別の場所，例えば「ゲーム全体の状態」とかに使うとか…）

[yukisyuki]

実際シーンの遷移にもこのパターンを使っていて、うまく行ったかなと思ったので今度はキャラクターで挑戦してみた次第です。

今回はplayerもenemyも使うstate、stateの実装の中身の大部分が同じで、一部のstateのほんの一部だけ違うという状況でした。
stateも割と数がありますし、追加する予定もあります。

自分の中であまり同じ内容を複数回書くのはよくないのかなと言う考えでしたのでこの実装になってしまいました。

今の話ですと、今は同じだったとしても今後の調整でそれぞれ別の実装になる可能性もあるのでそれぞれを完全に分離すべきということでいいですかね？

たしかに使うことを目標にしすぎて手段が目的になってしまっている感じは指摘されて気づきました、、、

[fana]

どういう形が良いかは実情次第でしょうけど……

今現在の様子が，「共通にしようとしているがために→問題が出ている」のだと思うので，その共通化自体が実情に合ってないんじゃないかな？と．
とりあえず一旦分離してみて「やっぱコレ，こうすれば纏められるじゃん！」とかなったら再度まとめてやるのでも良いのではないでしょうか．

[yukisyuki]

なるほど、ありがとうございます。
一度設計を見直してみます。

丁寧な回答ありがとうございます。

[fana]

同様に（もしも不明瞭なのであれば，ですが），
"Stateパターン" を用いずに実装した場合にはどんな（どれだけ凄惨な）状態になるのだろうか？　というのも一度やってみても良いかもしれません．