より良いデザイン？同じオブジェクト、異なる可能な状態

Question

ASP.NETフロントエンドサイトで構成された非常にシンプルなアプリケーションがあり、WCF Windowsサービスが重労働のバックエンドロジックを実行しています。

ユーザーは、いくつかのパラメーターを選択して「送信」ボタンを押す簡単なページを1つ持っています。ページはWCFサービスを呼び出して、パラメーターを渡します。サービスは、「Job」クラスのインスタンスをインスタンス化し、パラメーターをコンストラクターに送信してから、「Run（）」メソッドを呼び出します。このメソッドは、ユーザー名、時間を指定して「job」レコードをデータベースに挿入します。開始など...サードパーティベンダーにリクエストを行い、データを取得してデータベースに格納し、他のビジネスロジックを実行して、ジョブに完了のマークを付けます。

ユーザーは、ジョブを検索できる2番目のシンプルなページ（日付でソートされた検索可能なコンボボックスで、そのジョブに関連する複数のフィールドを表示）を表示し、そのジョブに対応するデータを画面に表示します-（ジョブテーブルのほとんどのフィールド（開始時間、完了時間、ステータスなど、パネルにラベルとして表示）およびサードパーティベンダーから取得した実際のデータ（パネルの下にグリッドとして表示）。

質問に移ります。つまり、上記のすべてのフィールドと、そのパブリックRun（）メソッドとコンストラクターを持つJobクラスがあります。いくつかの単純なプライベート関数と、IParser、IVendorConnection、IDataAccessなどのクラスへのインターフェイスであるいくつかのプライベートメンバーがあります。上記の実際の作業をすべて実行するクラスです。実際のJobクラスとRun（）メソッドはあまり機能しません実際の作業では、ほとんどが複合オブジェクトに作業を委任するだけです（特にテスト容易性が向上します）。

現在、このJobクラスには3つの異なる用途/状態があります。 Run（）関数を使用して文字通りジョブを実行するための主な用途はサービス内です。また、上記のパネルIのモデルとして機能すること、および上記のコンボボックスのモデルとして機能することもあります。ジョブクラスには3つのパブリックコンストラクターがあり、それぞれが3つの状態のいずれかに設定します。すべての場合において、それぞれの異なる「状態」は、他の2つの状態が気にしない特定のメンバーのみを対象とします-場合によっては、3つの状態すべてでメンバーの一部が使用されます。 「コンボボックスの状態」は最も単純です-この場合、3つの読み取り専用フィールドのみが必要です。 「パネル状態」では、6つの読み取り専用フィールドが重要です。「作業」状態では、基本的にジョブの進行に応じてこれらのフィールド値を作成します。これらはすべてプライベートにする必要があります。

これを行うためのよりクリーンな方法を探しています。状態Aでジョブクラスをインスタンス化すると、メンバーXへのアクセスが機能しないこと、または関数Yの呼び出しが失敗することを知っています。ただし、まだコンパイル可能なコードです。

他の人は以前にこの問題に直面したことがあると確信しています。 MustInherit / abstractとしてマークされた基本Jobクラスを持ち、次に各状態に1つずつ、3つの派生クラスを持つことを考えていました。共有メンバーをベースに、状態固有のメンバーを派生に配置し、必要に応じてコードで派生クラスを使用します。これは私の目的にとって十分に単純であるように見え、私の問題を解決します。たぶん、私はある種のJobFactoryを持つこともできます...他の人がどのようにこれを解決したかを探しているだけかもしれません。趣味のゲーム開発日-しかし、それらのクラスのインスタンスが状態を変更する可能性があるため、それは異なりました（たとえば、「敵」クラスの状態を「attack_mode」から「待機」に変更できる）私の場合、状態の変更はありません-作成されたジョブは、その状態を維持し、別のジョブで動作しようとしないでください。メソッド/メンバーが特定の状態にないときに使用された場合に状態を追跡し、例外をスローすることは、脆弱であり、作業が多すぎるようです。以前にこの問題を解決した方法に基づいた提案はありますか？そして、私がやりすぎているのは何ですか？ジョブスタ

Answer 1

3つの派生クラスを持つ単一の基本クラスジョブを作成するというあなたのアイデアは、私がやることとまったく同じように聞こえます。 JabFactoryを作成すると、この設計にさらに役立つ場合があります。特定の状況下でオブジェクトの一部が使用されていない、または違法に使用されているオブジェクトを作成するのは悪い習慣です。したがって、必要な部分のみを使用して派生クラスを作成することは、明らかに優れた設計です。やりすぎではありません。