時々、オブジェクトの状態をサポートする必要があります。私が理解しているように、2つのアプローチがあります。
- ENUM(シンプル)
- STATEパターン(OC原則)
そのような目的のためにStateパターンを使用する必要があることは明らかです(私にはわかりません)。
しかし、私がしばしば直面する他のコードを読むと、状態パターンだけでなく列挙型に直面します。状態パターンには力がありますか?
時々、オブジェクトの状態をサポートする必要があります。私が理解しているように、2つのアプローチがあります。
そのような目的のためにStateパターンを使用する必要があることは明らかです(私にはわかりません)。
しかし、私がしばしば直面する他のコードを読むと、状態パターンだけでなく列挙型に直面します。状態パターンには力がありますか?
通常、ENUMアプローチには、状態と遷移のある種のテーブル(配列)が含まれます。デザインパターンはオブジェクトでも同じことを実現します。
ENUMを使用したテーブルアプローチを参照しない場合、ソリューションには大きなif / else ifブロックを含める必要がありますが、これは非常に管理しにくいものです。以下のセクションを参照すると、この特定のソリューションが劣っていることは明らかだと思います。
これが私がそれぞれの長所と短所としてリストするものです
ENUMテーブル
長所:
短所:
デザインパターン
長所:
短所:
なぜStateパターンを使用するのですか?条件付きロジックの重複を削除し、条件付きコードをポリモーフィズムに置き換えます。
条件付きロジックの重複はいつありますか?状態に依存する多くのアクションがある場合、したがって、すべてのアクションで条件付きロジックを複製する必要があります。あなたが多くの州を持っているとき、それは非常に迷惑になります。また、コードの重複は、新しい状態を追加するときに、重複したコードのすべてのコピーを更新する必要があることを意味します。
したがって、条件付きロジックを複製していない場合は、状態のクラスが多数ある新しいクラス階層を作成するのではなく、列挙型ベースの状態を使用します。条件付きロジックの複製を好むこともあります。たとえば、状態が多いが、状態に依存するアクションが少ない場合です。この場合、10個の新しいクラスを作成するのではなく、2つのスイッチブロックを使用することをお勧めします。