私はアプリケーションで 28 州の州パターンを使用しています。州は 7 つの主要な州を持つ会員カード用です。実際にその動作に影響を与える会員カードには 4 つのブール属性があるため、それらを州に埋め込むことにしました。それがどのように28州に増えたか。
問題は現在、状態クラスの命名にあり、それは狂っています。私はこのMembership-UnderCreation-Printed-Linked-Premium-Frozenのような名前のクラス状態になってしまいます-----明確にするためにさまざまな属性にハイフンを付けました。
状態クラス名はこんな感じでいいの!? ベストプラクティスのために何をすべきですか？
おそらく、あなたはそれを押しすぎています。あなたの現在のアプローチは維持可能だとは思いません。これがどのように進化するかによっては、さまざまな状態の爆発につながる可能性があります。
この問題にどのように取り組むことができるかについて、いくつかのアイデアがあります。状態パターンを使用して 7 つの主要な状態を実装し、フラグを使用して他の状態を追跡することができるため、各状態内でこれらに基づいて条件文を記述できます。関数内のコードは少し複雑になりますが、それでもより保守しやすいと思います。
私はあなたの状態遷移とすべてについて多くの情報を持っていませんが、別のアイデアは、状態をアクティブにするために満たす必要がある条件のコレクションを渡すことによって、匿名のサブクラスを作成できる単一の状態クラスを持つことです。
次に、状態に名前を付ける必要はありません。それらをコレクションに保持するだけでよく、状態の変更を引き起こす可能性のあるメイン オブジェクトのプロパティが変更されたときに、状態コレクションをループすると、新しい状態が見つかります。オブジェクトのプロパティを状態条件と比較することにより、状態を決定します。
HashMap を使用して状態を保存し、すべての条件からハッシュを作成して一意のキーを取得することもできます。これにより、すべての状態をループして次の状態を見つけるよりも、状態のルックアップが高速になります。