Abstraktionsherausforderung. Wie man sich der Verkapselung für diesen Zweck nähert

Question

Bitte kommentieren Sie keine schlechten Praktiken, die hier verwendet werden. Ich versuche einfach, die Abstraktion dieses Szenarios mit leicht zu beschreibenden Beispielen anzugehen.

Ich versuche, ein System zu modellieren, das es einem Benutzer ermöglicht, eine Entität namens TASK mit bestimmten Konfigurationsparametern einzugeben, und später muss der TASK bestimmte Aktionen für diese Aufgabe ausführen.

Einige Beispiele für Taskdefinitionen könnten sein:
* Erstellen Sie eine Datei {Dateiname} im Verzeichnis {Pfad}.
* Kopieren Sie die Datei {Dateiname} von {Quellverzeichnis} nach {Zielverzeichnis}.
* Öffnen Sie {notepad application}, geben Sie den Text {sample text} ein und speichern Sie die Datei als {filename}.
* Öffnen Sie {sample.docx}, geben Sie den Text {sample text} am Ende des zweiten Absatzes ein.

Jede Aufgabe hat einen beschreibenden Namen und bis zu 5 Parameter. In den obigen Beispielen sind Parameter in geschweiften Klammern {} eingeschlossen. Die Benutzer werden angewiesen, die oben genannten Aufgaben auszuführen, und unser Antrag wird prüfen, ob sie abgeschlossen wurden. Jede Aufgabe muss die folgende Funktion hat:

In einer statischen Welt, würde ich die folgenden Klassen erstellen:

public abstract class TaskBase { public abstract void Perform(param1, ... param5); }
public class TaskFileCopy: TaskBase { public override void Perform(param1, ... param5) {} }

Das Problem ist, Aufgaben können praktisch alles sein und nach dem Programm zusammengestellt und eingesetzt , müssen weitere Aufgaben hinzugefügt werden. Die erste und schlimmste Sache, die mir in den Sinn kommt, ist, von TaskBase weiterzuleiten, Perform zu implementieren, neu zu kompilieren und erneut zu implementieren, während die vorherigen Task-Ergebnisse in Takt gehalten werden.

Zwei Probleme hier: Wenn wir 2.000 Aufgaben erreichen, werden wir höchstens 2.000 abgeleitete Klassen haben und zweitens wird der zugrundeliegende OODB festgefahren sein.

Ich habe einmal an System.AddIn gedacht, bin aber überzeugt, dass dieses Szenario eine bessere Lösung für das OOP-Design bietet.

Answer 1

Ich bezweifle, dass System.AddIn für diese Art von Sache geeignet ist. IMHO System.AddIn ist für mehr statische APIs und nicht für etwas, das schnell erweitert werden soll. Vielleicht können Sie sich stattdessen MEF ansehen, was einfacher ist und auf Erweiterbarkeit und Zusammensetzung basiert.

Wie Sie sagen, Vererbung ist auch nicht der Weg zu gehen, weil 2000 abgeleiteten Klassen wird ein Albtraum sein.

Ich denke, dass Sie nach Entwurfsmustern suchen sollten, die auf der Zusammensetzung statt Vererbung basieren. Es gibt einige von ihnen. Einer von ihnen ist das Composite Muster. Mit diesem Muster könnten Sie einige sehr einfache wiederverwendbare Aufgaben haben, die Sie zu komplizierteren Aufgaben kombinieren können. Sie können Aufgaben haben, die Teilaufgaben enthalten, einschließlich Teilaufgaben und immer wieder.

Auch Sie könnten die dynamischen Sprachen betrachten, die auf dem DLR gehostet werden können. Wie IronPython. Sie könnten ein Skript-Repository erstellen. Jedes Skript eine Aufgabe.

Auch für Inspiration können Sie sich Windows Workflow Foundation und speziell die Aktivitäten ansehen.

Was offensichtlich ist, ist, dass Sie die Wiederverwendung maximieren müssen. Natürlich ist das leichter gesagt als getan.

Mit freundlichen Grüßen und viel Glück.