Ein besseres Design? Gleiches Objekt, unterschiedliche mögliche Zustände

Question

Ich habe eine sehr einfache Anwendung, die aus einer ASP.net-Front-End-Site besteht, wobei ein WCF Windows-Dienst die schwere Logik zur Back-End-Logik durchführt.

Der Benutzer hat eine einfache Seite, auf der er einige Parameter auswählt und eine "Senden" -Taste drückt. Die Seite ruft den WCF -Dienst auf und übergibt ihn die Parameter. Der Dienst hat eine Instanz einer "Job" -Klasse instanziiert, die die Parameter an den Konstruktor sendet, und dann eine "Run ()" -Methode aufgerufen Start usw. stellt eine Anfrage an einen Anbieter von Drittanbietern, nimmt die Daten, stellt sie in die Datenbank, macht eine andere Geschäftslogik und markiert dann den Job als abgeschlossen.

Der Benutzer hat dann eine zweite einfache Seite, auf der er jetzt nach seinem Job suchen kann (ein durchsuchbares Kombinationsfeld sortiert nach Datum, das mehrere Felder anzeigt, die sich auf diesen Job beziehen) Felder aus der Auftragstabelle, z. B. mit der Zeit, der Zeit, dem Status usw., angezeigt als Etiketten in einem Panel) und die tatsächlichen Daten, die wir aus dem Anbieter der dritten Partei gezogen haben (als Raster unterhalb des Panels).

Jetzt zu meiner Frage - also habe ich eine Jobklasse, die alle oben erwähnten Felder zusammen mit seiner öffentlichen Run () -Methode und Konstrukteuren hat. Es hat ein paar einfache private Funktionen und mehrere private Mitglieder, die Schnittstellen zu Klassen wie IParser, IvendorConnection, IdataAccess sind - die Klassen, die alle oben beschriebenen tatsächlichen Arbeit Tatsächliche Arbeit, so ziemlich nur Delegierte arbeiten an seine zusammengesetzten Objekte (sorgt unter anderem für gute Testbarkeit).

Jetzt hat diese Jobklasse 3 verschiedene mögliche Verwendungen / Zustände. Die Hauptnutzung liegt im Dienst im Dienst, um die Funktion run () zu nutzen, um buchstäblich einen Job zu betreiben. Es hat auch zwei andere Verwendungszwecke - als Modell für das oben beschriebene Panel und als Modell für die oben beschriebene Kombinationsbox, die ich oben beschrieben hat, fungiert. Die Jobklasse verfügt über 3 öffentliche Konstruktoren, die jeweils für einen der 3 Staaten eingerichtet sind. In allen Fällen kümmert sich jeder unterschiedliche „Staat“ nur um bestimmte Mitglieder, die die anderen 2 Staaten nicht interessieren - in einigen Fällen werden einige der Mitglieder in allen drei Staaten verwendet. Der "Kombinationsbox -Status" ist der einfachste - in diesem Fall möchte ich nur 3 Readonly -Felder. Im 'Panel State' kümmere mich ich um 6 lesende Felder. Im "Arbeitsstatus" erstelle ich im Grunde genommen diese Feldwerte im Laufe des Jobs - und sie sollten alle privat sein.

Ich suche nur eine sauberere Möglichkeit, dies zu tun. Wenn ich eine Jobklasse im Bundesstaat A instanziiere, ich, ich kennt Dieser Zugriff auf Mitglied X funktioniert nicht oder die Aufruffunktion Y wird fehlschlagen. Es ist jedoch immer noch kompilierbarer Code.

Ich bin sicher, dass andere zuvor mit diesem Problem konfrontiert sind. Ich dachte darüber nach, eine Basis -Jobklasse als Mustinherit/Abstract zu haben und dann 3 abgeleitete Klassen für jeden Zustand zu haben. Setzen Sie die gemeinsam genutzten Mitglieder in die Basis und die staatsspezifischen Abgeleiteten und verwenden Sie gegebenenfalls die abgeleiteten Klassen in meinem Code. Dies scheint für meine Zwecke einfach genug zu sein und löst mein Problem. Vielleicht könnte ich auch eine Art Jobfaktor haben ... Ich denke, ich suche nur, wie andere Leute dies gelöst haben Hobbyistische Spielentwicklungstage - aber das war anders, denn Instanzen dieser Klassen könnten die Zustände ändern (z. B. eine "Feind" -Klasse könnte seinen Zustand von 'Attack_Mode' zu 'Warten' verändern lassen) in meinem Fall gibt es keine sich ändernden Zustände - Einmal geschaffen, muss ein Job in seinem Bundesstaat bleiben und niemals versuchen, sich in einem anderen zu verhalten. Verfolgung des Staates und Ausnahmen zu werfen, wenn eine Methode/ein Mitglied verwendet wird, während nicht in einem bestimmten Zustand spröde und zu viel Arbeit erscheint. Gibt es Vorschläge, die darauf basieren, wie Sie dieses Problem zuvor gelöst haben? Und ist das, was ich versuche, Overkill zu machen? Wenn der Job immer mehr andere Staaten bekommen würde, würde ich nicht denken - aber vielleicht, wenn er so viele verschiedene Staaten bekommen würde, dann muss ich darüber nachdenken, ihn sowieso in verschiedene Klassen aufzuteilen ... nur nach Ihren 2 Cent zu suchen.

Answer 1

Ihre Idee, einen einzelnen Basisklassenjob mit 3 abgeleiteten Klassen zu erstellen, klingt genau so, wie ich es auch tun würde. Das Erstellen eines JABFactory kann dieses Design weiter helfen. Es könnte eine schlechte Praxis sein, ein Objekt zu erstellen, bei dem Teile des Objekts nicht verwendet oder illegal sind, um unter bestimmten Umständen verwendet zu werden. Das Erstellen der abgeleiteten Klassen mit nur den notwendigen Teilen ist eindeutig das bessere Design. Es ist nicht übertrieben.