Wie wird eine generische Aktionsklasse entworfen, während saubere Programmierpraktiken beibehalten werden?

Die Aufgabe besteht darin, einen Teil meiner Java-Webanwendung zu erstellen, der es mir ermöglicht, auf einfache Weise kleine Codes in einer zusammengesetzten Weise auszuführen. Die Aufgabe besteht darin, dem Benutzer zu ermöglichen, "Aktionen" in beliebiger Reihenfolge zu erstellen. Worum ich mich bemühe, ist die Weitergabe von Parametern an meine Aktionen.

Alles beginnt mit der Aktionsschnittstelle:

Wenn die Aktion gelöst ist, wird der Code ausgeführt. Der Code kann alles sein: Aufruf einer Methode in Java, Ausführung von Javascript ...

Hier ist der "Kontext" das Problem für mich. Jede Aktion wird in einem bestimmten Kontext ausgeführt. Der Benutzer, der die Aktion erstellt, kann angeben, welches Objekt aus dem Konzept abgerufen werden soll, z. B. der Benutzer, der die aktuelle Aktion auflöst, oder andere Objekte, die in der spezifischen Schnittstelle der Aktion angegeben sind.

Beispiel, schauen wir uns diese Aktion an:

Es ist ein einfacher Wrapper, der eine Aktion in Javascript mit Nashorn aufruft. Die Parameter können alles sein: Objekte mit bestimmten IDs im DB, int / String / boolesche Werte, die vom Benutzer konfiguriert wurden ...

Der Code einer Aktion kann folgendermaßen aussehen:

So kann die Aktion Laufzeitparameter (z. B .: Benutzer, der die Aktion ausführt ...) und statische Parameter (die beim Laden der Aktion erstellt werden - z. B. aus einer Konfigurationsdatei) und alles aus dem Konzept abrufen. Außerdem kann der Benutzer z. B. Verweise auf das Objekt in den Parametern angeben, die zur Laufzeit injiziert werden.

Aktionen können auch verschachtelt / dekoriert werden, um die vollständige Komposition zu erreichen. Zum Beispiel:

Damit können Aktionen leicht erstellt werden:

Wenn Sie all das wissen, was ist am besten geeignet, um die Kontextklasse zu entwerfen? Sollte es in mehrere Elemente aufgeteilt werden? Der Kampf besteht darin, alles, was zur Laufzeit benötigt wird, in die Klasse zu injizieren und sicher zu stellen, dass keine Konflikte mit möglichen eingepackten Aktionen auftreten.

Die grundlegende Implementierung von Context ist verantwortlich für:

• ruft zur Laufzeit ein beliebiges Objekt aus der Datenbank ab
• Bereitstellung von statischen Parametern für die Aktionsentwickler, die eine Transaktion halten und
geben
• es Zugang zu dem Benutzer, der Laufzeit und statisches Konzept verschmelzt, und dies sogar in einem Wrapper (zB: wenn eine Elternaktion eine Kindaktion aufruft, Der Benutzer, der die Aktion ausführt, muss noch bekannt sein, damit der Kontext es sein sollte Zusammenführen statischer untergeordneter Parameter und Laufzeitparameter wie z Benutzer)

Ich fühle, dass es zu viel macht. Das Design wird von den Concept-Klassen beeinflusst, die viele Verantwortlichkeiten besitzen und fragmentiert sein sollten (momentan ist jeder Teil der Anwendung mit dem Konzept verbunden). Aber wie ? Hier ist, was ich versuche, saubere Codierung zu erreichen:

• die Aktionsschnittstelle sollte einfach gehalten werden (1 Methode max, mit a vernünftige Anzahl von Parametern)
• keine Verwendung von statischen Mechanismen
• maximale Unveränderbarkeit

In einer objektorientierten Art und methodenorientiert, wie löst man dieses spezifische Designproblem?

edit: entfernt öffentlichen Deklarator in Methode in der Schnittstelle

edit 2: Ich hatte viele interessante Lösungen, aber diejenige, die mir mehr Sinn machte, war diejenige, in der jede Aktion mit einer bestimmten Art von Kontext parametrisiert wird. Ich habe die Dinge als solche neu organisiert:

• Aktionsschnittstelle hat immer noch nur eine Methode, um die Aktion mit dem Kontext
aufzulösen
• Statische Parameter der Aktionen, seien sie DB oder andere, werden geladen, wenn die Aktion erstellt wird (Benutzersitzung)
• Der Kontext ist nur eine Fassade für verschiedene Operationen (Transaktion ...) + spezialisierte Operationen, wie der Benutzer der Aktion