6

State パターンの典型的な実装から私が収集したのは次のとおりです。

問題:現在の状態に基づいて動作が変化 するオブジェクトOを表します。
解決策:
1.このオブジェクトO内の別のオブジェクトSが状態を表すとします 2. オブジェクトSはOの適切な操作を呼び出し ます 3. オブジェクトSはオブジェクトOの次の状態を決定します

私の懸念は主に#3. 状態遷移表は、基本的にすべての状態に広がっています。これらのソリューションは、非常に迅速に管理するのが面倒になるのを見てきました。これらの状態は、インジケーターではなく、状態マシンに関する情報を保持しすぎています。気になりますが、かなり合理的だと思います (
Moore machine .) 私が見た唯一の問題は、バグ修正/デバッグ中に発生することです: コードのナビゲーション/理解は、すべての状態マッピングをメモリにコミットするまで困難になります。#2

次の実装はより正確でしょうか?
状態を列挙として表し、オブジェクトは列挙が保持する値に基づいてアクションを決定します。これらstate transitionsは、現在の状態から次の状態へのマップであるテーブル (δ、状態遷移関数) にあります。これstate transition tableは、実行されるアクションも保持します ( Mealy machine )

4

1 に答える 1

1

State パターンは Moore マシンしか表現できないとあなたが考える理由がわかりません。

void SleepingState::alarm()
{
    kick_alarm_clock();
    set_state(new GrumpyState());
}

状態 (SleepingState) とイベント (alarm) の両方に基づいて出力 (kick_alarm_clock) を選択したため、Mealy マシンになります。

あなたの代替案は確かに有効で人気があります（他にもあります）。マシン ロジックを実装するにはいくつかのアプローチで十分なので、他の「設計」や個人的な好みを考慮して決定を下します。頻繁に新しい状態を追加すると思われる場合、またはいくつかの状態が継承関係を保証するのに十分類似していると思われる場合は、State パターンを優先する設計上の理由が考えられます。私は美学に基づいて選択する傾向があります。マシンがかなり高密度の場合にのみ State パターンを使用します。つまり、ほとんどの { 状態、イベント } のペアに重要なアクションと遷移があります。マシンがかなりまばらな場合、すべての空のメソッドに当惑します。

于 2011-03-07T19:50:40.910 に答える