何かをコーディングする前に、先のことを考えすぎているのか、考えすぎているのか、いつも疑問に思っていました。これは、説明する必要がある将来の要件変更の可能性がわからない場合に特に当てはまります。クラスをどの程度柔軟または抽象化する必要があるかわかりません。簡単な例を挙げます。
あなたはコンピューターに対してブラックジャックをプレイするプログラムを書きたいと思っており、実験が好きなタイプです。デッキのコードを書き始めましたが、ブラックジャックには 1 つ、2 つ、4 つ、または任意の数のデッキがあることに気付きました。あなたはそれを説明しますが、デッキが変更され、10 の値のカードがなくなる可能性があることに気付きます。次に、任意の数のスーツまたはランクを許可するために、デッキが完全に用途が広い必要があると判断します。次に、デッキのルールを、標準のスート数に一意のランクを掛けて、デッキ内のカードの総数に等しくなるように変更できるようにすることを決定します。
私の質問はこれです。クラスがどの程度柔軟であるべきかについてのガイドラインはありますか?
柔軟性は、アプリケーション/システムを保守可能にするための要件です。通常、SOLID 設計原則、TDD、およびステートレス ビジネス ロジックに従う設計の方が維持しやすいことがわかります。
SOLID 原則の中でも、[S]RP がアプリケーションを保守可能にするルールであることがわかりました。[S]RP に続いて、システムはより小さな部分に分解され、交換可能なクラスになります。Deck、DeckRule、HitActionなどに分割できるとします。
Deckまたはと簡単に交換できるため、インターフェイスまたは継承が役立ちNoTenDeckますSpadeOnlyDeck。DeckRuleまた、をHardToWinDeckRuleまたはに入れ替えることができますImpossibleWinDeckRule。decoratorなどの設計パターンを使用するcompositeことも、システムを柔軟にするのに役立ちます。Test Unit を忘れないでください。コードのリファクタリングに役立ちます。
またBreaking Change、現在のアーキテクチャやインターフェイスを別の設計に置き換える必要がある場合なども必要になる場合があります。必要な場合もありますが、ほとんどの場合必要ありません。
stackoverflow answer for DI vs Singleton でいくつかの議論を見つけることができ、 state または stateless についてはほとんどありません。
柔軟性に関する全体的な考え
問題の説明から、 「ゲームルールのすべての新しい側面を同じクラスにスローし続ける」ように、クラスを柔軟にする必要はないと思います。責任が多すぎるクラスは壊れやすく、保守が難しく、変更が困難です。皮肉なことに、クラスを柔軟であるかのように扱うと、最終的には厳格になります。すべての卵を 1 つのバスケットに入れないでください。セパレート・コンサーンとは、セパレート・クラスを意味します。クラスではなく、全体的な設計は柔軟であるべきです。
ブラックジャックの問題について
カード ゲーム、特に複雑で進化しているゲームは、一般的に最も独特な動物であるため、デザイン スキルを向上させるために実験を開始する標準的な例としてはおそらく適切ではありません。
真のモジュール性が必要な場合は、ゲームのさまざまな段階でプラグインをフックできるプラグイン可能なルール エンジンが必要になるでしょう。これにより、関連するリソースにアクセスして、スコアから一連のイベントまでを変更し、他のルールに変更することもできます。 .
これに対する私の見解は
"I ain't gonna need this rule/type of hook into the game""I ain't gonna need a rules engine"または、
ゲーム固有の設計ガイドラインについては、 https://gamedev.stackexchange.com/も参照してください。