design-patterns - 状態パターンとENUM

Question

時々、オブジェクトの状態をサポートする必要があります。私が理解しているように、2つのアプローチがあります。

1. ENUM（シンプル）
2. STATEパターン（OC原則）

そのような目的のためにStateパターンを使用する必要があることは明らかです（私にはわかりません）。

しかし、私がしばしば直面する他のコードを読むと、状態パターンだけでなく列挙型に直面します。状態パターンには力がありますか？

Answer 1

通常、ENUMアプローチには、状態と遷移のある種のテーブル（配列）が含まれます。デザインパターンはオブジェクトでも同じことを実現します。

ENUMを使用したテーブルアプローチを参照しない場合、ソリューションには大きなif / else ifブロックを含める必要がありますが、これは非常に管理しにくいものです。以下のセクションを参照すると、この特定のソリューションが劣っていることは明らかだと思います。

これが私がそれぞれの長所と短所としてリストするものです

ENUMテーブル

長所：

• テーブルが1つの場所で定義されているため、すべての状態と遷移を簡単に確認できます

短所：

• 状態と遷移はよりハードコーディングされており、拡張するにはより多くのコード変更が必要です

デザインパターン

長所：

• 新しいオブジェクトを追加することで、新しい状態での拡張が容易になります。（オープン/クローズ原則）
• 基本クラスはシグナルを抽象関数として定義する必要があるため、すべてのシグナルが状態によって処理されることを保証するのが簡単です。
• 状態から派生することにより、特定の状態の動作を拡張するのが簡単になります。状態パターンは、特定の状態の動作を1つのオブジェクトに配置する必要があります。

短所：

• それらはいくつかの異なるクラスに分散しているため、コードを見てすべての状態とそれらの関係を確認することはより困難です。
• 管理できない数のオブジェクトを作成してしまう可能性があります。ただし、これを、対応するENUMソリューションで必要な対応するif/elseブロックと比較してください。

Answer 2

なぜStateパターンを使用するのですか？条件付きロジックの重複を削除し、条件付きコードをポリモーフィズムに置き換えます。

条件付きロジックの重複はいつありますか？状態に依存する多くのアクションがある場合、したがって、すべてのアクションで条件付きロジックを複製する必要があります。あなたが多くの州を持っているとき、それは非常に迷惑になります。また、コードの重複は、新しい状態を追加するときに、重複したコードのすべてのコピーを更新する必要があることを意味します。

したがって、条件付きロジックを複製していない場合は、状態のクラスが多数ある新しいクラス階層を作成するのではなく、列挙型ベースの状態を使用します。条件付きロジックの複製を好むこともあります。たとえば、状態が多いが、状態に依存するアクションが少ない場合です。この場合、10個の新しいクラスを作成するのではなく、2つのスイッチブロックを使用することをお勧めします。