OOP Decorater Pattern für Varifikationsverhalten

[turmaline]

Hallo Leute,

ich würde gerne mit Euch Decorator Pattern diskutieren.

Es geht dabei um Verifikationsverhalten von Formularen, das in Java-Backend ausgelagert ist. Das heißt der Benutzer füllt ein Formular aus und klickt speichern oder senden. Senden beinhaltet speichern und exportieren als XML-Dokument. Nun es hört sich alles soweit einfach an, kompliziert wird es deshalb weil es verschiede Prozessschritte existieren zu denen die Formulare ausgefüllt werden können. Zu jedem Prozessschritt gibt es eine in der Datenbank abgelegte Konfiguration. Diese Konfiguration besteht aus den Namen der Felder, Flags (mandatory, visible, editable) und anderen Attributen die hauptsächlich für die GUI interessant sind.

Das Verifikationverhalten basiert auf dieser Konfiguration, nämlich es wird die Konfiguration für einen bestimmten Prozessschritt zu dem das ausgefühlte Formular ausgefüllt wurde gelesen, es wird über die Felder in der Konfiguration iteriert und geprüft ob alle mandatory editable Felder ausgefüllt wurden.

Somit ist der Verifikator eine Komponente, die das zu verifizierende Objekt samt der Feldkonfiguration entgegennimmt und die Konfiguration überprüft.

Nun kann es vorkommen, dass für bestimmte Prozessschritte Sonderbhandlungen in den Verifikationsprozess eingebaut werden müssen. Ich habe vor und habe das schon angefangen zu implementieren für diesen Zweck den Decorator Pattern einzusetzen.

Beispiel für so eine Sonderbehandlung wäre: für einen bestimmten Prozessschritt muss eins der Kontaktfelder ausgefüllt werden, WENN der Ansprechpartner ausgefüllt wurde. Es gibt noch einige Sonderbehandlungen in der Art.

Meine Idee besteht dabei in der Implementierung einer Decorator-Klasse die dann den Verifikationsmethod der Standartkomponente aufruft + eine Sonderbehandlung für jede Sonderbehandlung. Die entsprechende Decorator-Klasse wird dann in einer Mapping-Klasse für den jeweiligen Prozessschritt registriert.

Was sagt Ihr zu meiner Idee? Was gäbe es hier für Alternativen? Was wenn für 5 aus 100 Prozessschritten eine Sonderbehandlung existiert? Wie würdet Ihr das problem lösen?

Würde mich freue wenn Ihr mit mir darüber diskutieren würdet.

Gruß,
madlena

 

[turmaline]

würde sich da vielleicht das Composite Pattern besser eignen? Da man eben verschieden Verifikations-Verhalten zusammenstecken könnte??

 

[nillehammer]

Was wenn für 5 aus 100 Prozessschritten

In dem Satz steckt das entscheidende Wort drinnen: "Prozess". Dein Anwendungsfall ist (warum auch immer) mit einfacher Validierung mit bspw. Bean-Validation nicht zu lösen, sondern ist ein wie auch immer gearteter komplexer Prozess, der Schritt für Schritt abgearbeitet werden muss. Dafür bietet sich eher Chain of Command an.

 

[turmaline]

hm eigentlich nicht. Es geht eben nicht um die Abwicklung des Prozesses an sich in diesem Fall, sondern um die Verifaktaion von mandatory (oder wie auch immer die Bedingung lautet) Felder...

 

[nillehammer]

Ah ok, aber dann würde ich das Bean-Validation API vorschlagen. Das ist Standard und wird von vielen GUI- und Persistenzframeworks direkt unterstützt. Damit baust Du Dir aus ganz Feingranularen Validatoren die Validierung so zusammen, wie Du möchtest. Die Validatoren kannst Du natürlich auch mit der Konfiguration aus Deiner Datenbank initialisieren. Das wäre dann irgendwie gar kein Pattern (außer es gibt einen Namen für "möglichst feingranular"). Doku gibt's hier: Hibernate Validator

 

[bygones]

von der Beschreibung her wuerde ich auch eher einen Ansatz ala Dekorator nehmen. Die Frage ist natuerlich inwieweit sich die 100 Schritte unterscheiden bzw die Sonderbehandlungen. Am Ende 100 + X versch. Verifikationen zu haben ist natuerlich recht komplex.

da diese aber in einer DB abgelegt sind gehen ich mal davon aus, dass es eine zentrale Stelle fuer diese gibt und das verhalten generisch ueber die konfiguration geladen wird.

Sind die Sonderbehandlungen auch in der Konfiguration spezifiziert ?

 

[turmaline]

ja das Verhalten wird generisch geladen, es gibt eine Konfig-Tabelle in der zu jedem Prozessschritt Konfiguration für alle Felder abgelegt ist.
nein, die Sonderbehandlungen sind nicht in der Konfiguation abgelegt. Bei Sonderbehandlungen geht es vor allem um die Kreuzüberprüfungen, beispielsweise es MUSS entweder das Feld "Firma" oder die Zwei Felder "Name" und "Nachname" gefüllt sein.

Im MOment fällt mir nichts Besseres als Dekorator-Einsatz ein...

 

[turmaline]

oder noch ein anderes Beispiel der Sonderbehandlung:

wenn das Feld "SoUndSo" auf den Wert "SoUndSo" gesetzt, sollte sich der Wert eines anderen bestimmten Feldes im Bereich "so und so" befinden...

 

[turmaline]

ach so ja, die Hauptfrage von diesem Thread war eigentlich, wie mal so einen Dekorator implementiert, der einen Teil des Verhaltens rausnimmt?? Also nehmen wir an es gibt eine Sonderbehandlung die für fast alle prozessschritte gilt. Diese ist deshalb eine Sonderbehandlung, weil das Verhalten basiert nicht auf der Konfiguration, sondern auf Querabhngigkeit der Felder..

 

[bygones]

mhm ist ein komplexeres Thema, was wahrscheinlich schwierig ist ohne Code und ohne kompletten Kontext, daher einfach mal hergeraten.

Naiv gesehen wuerde ich sagen es sollte eine Struktur geben, die deine Prozessschritte wiederspiegelt, sagen wir mal "Process" Daneben gibt es eine Struktur die Verifizierung uebernimmt - nennen wir es "ProcessVerification".

Eine Processverification weiss wann fuer sie gesehen ein Process gueltig ist.

Ein Process haelt eine Reihe von ProcessVerifications. Ein Teil dieser wird von der Konfiguration geladen und erstellt und dem Process hinzugefuegt. Die Sonderbehandlungen sind ebenso ProcessVerifications und werden dann manuell (? bisher kommt nicht heraus wann bzw wie entschieden wird, wann eine Sonderbehandlung von noeten ist) ebenso dem Process hinzugefuegt.

Hierbei kann natuerlich eine Konfiguration eine ProcessVerification sein oder mehrere (je nach dem wie generell die Konfigurationen sind).

Benoetigen mehrere Processe die selbe Sonderbehandlung bekommen sie einfach alle die selbe ProcessVerification hinzugefuegt.

Die Verfizierung des Processes selber ist dann die Validierung aller ProcessVerficiations. Geht eine schief ists die Verifikation gescheitert.

Also nicht ganz Dekorator, aber wie gesagt, naiv gesehen recht flexibel.

hilft das ?

 

[turmaline]

Die Verfizierung des Processes selber ist dann die Validierung aller ProcessVerficiations. Geht eine schief ists die Verifikation gescheitert.

Also nicht ganz Dekorator, aber wie gesagt, naiv gesehen recht flexibel.

hilft das ?

Dein Verständins vom Ganzen ist in der Tat nicht ganz korrekt, aber daran bin ich ja selber schuld
Jedenfalls, es gibt keine Prozesse, es gibt nur Nachrichten, eine Nachricht ist einem bestimmten Prozessschritt zugeordnet. Der größte Teil der Implementierung ist generisch, die Prozesse an sich werden durch einen Zustandsautomaten gesteuert, der definiert welche Nachricht und an wen nach einem bestimmten Prozessschrit gesendet werden soll. Nun das hier ist eine grobe Beschreibung, das Ganze ist um einiges komplizierte und nicht wirklich relevant für den Thread.

Hier geht es um die Verifizierung von der Nachricht. Dieser Teil ist auch generisch und wird von einer unabhängigän Komponente Verifier ausgeführt. Der verifier springt beim Speichern (Erstellen), Importieren (Eingang der Nachricht), Exportieren (Verschicken der Nachricht) ein und bekommt eine Nachricht als Eingangsparameter. Die Nachricht enthält dabei alle für die Verifikation nötige Informationen. Den Verifier kann man beliebig überschreiben und erweitern, je nach dem was genau er prüfen muss.

Und jetzt zu Deiner Idee, verschiedene Verifikationen hinzuzufügen. Die ist keineswegs naiv und ich finde sie gar nicht so schlecht. Wenn man wieder die Entwurfsmuster betrachtet, wäre das so was ähnliches wie Kompositum. Ich werde diesen Ansatz prüfen und schreibe noch einmal zu welchem Schluss ich gekommen bin.

Gruß,
madlena

 

[turmaline]

mhm ist ein komplexeres Thema, was wahrscheinlich schwierig ist ohne
Hierbei kann natuerlich eine Konfiguration eine ProcessVerification sein oder mehrere (je nach dem wie generell die Konfigurationen sind).

Benoetigen mehrere Processe die selbe Sonderbehandlung bekommen sie einfach alle die selbe ProcessVerification hinzugefuegt.

Die Verfizierung des Processes selber ist dann die Validierung aller ProcessVerficiations. Geht eine schief ists die Verifikation gescheitert.
hilft das ?

Nun Deine Idee war wirklich gut und zur Situation besser passend als Dekorator.
Es gibt also eine Kompositum-Klasse der die Varifikatoren hinzugefügt werden.

 public boolean verify()
    {
        boolean verify = true;
        for(WimValueObjectVerifier v : verifiers)
        {
            verify &= v.verify();
        }
        return verify;
    }

Nun habe ich ein Problem: die Kinder-Verifikatoren haben dieselbe Attribute wie die Kompositum-Klasse das sie ja von derselben Klasse abgeleitet sind. Allerdigs wollte ich nicht jedem Verifikator dieselben Objekte anhängen und wollte dass sie zentral verwendet werden. Allerdings kenn ich dafür keine generische Lösung: die Kinder-Verifikatoren können ja unabhängig vom Kompositum sowie als Teil des Kompositums verwendet werden. Die Kinder wissen ja nichts von der Kompositum-Klassen, sie sind ja nur ein Teil davon.. Hast Du dafür einen Vorschlg, wie man das lösen könnte?

        AbstractVerifierComposite verifier = new SaveCompositeVerifier(wrapper, info);
        verifier.addVerifier(new SaveVerifier());
        verifier.addVerifier(contactOptVerifier);
        return verifier;

 

[FArt]

Ich würde kein Pattern sondern eine Regelengine vorschlagen, z.B. Drools - JBoss Community. Damit lassen sich sowohl Plausibilisierungen als auch Workflows abbilden.

 

[turmaline]

Ich würde kein Pattern sondern eine Regelengine vorschlagen, z.B. Drools - JBoss Community. Damit lassen sich sowohl Plausibilisierungen als auch Workflows abbilden.

Die Regelengine darf ich hier nich benutzen, es ist die Entscheidung von meinem Projektleiter und unterliegt nicht der Diskussion (er mag dafür seine Gründe haben, denn es gab angeblich eine Regenengine für das Ganze.. nun nicht mehr)