Erst mal vielen Dank für deine Anregung.
Das ich als Trigger die Setter verwenden kann, das hatte ich auch schon vorgesehen.
Mir ging es ehr darum, wie ich die Menge an verschiedenen Kriterien komfortabel in eine Klasse packen könnte, so dass und/oder-Bedingungen unter diesen Kriterien auch noch möglich sind. (Vielleicht habe ich mich da im Ursprungsbeitrag etwas unglücklich ausgedrückt).
Meine Einzige Idee zur Zeit wäre, das ganze in eine String ala
SQL-Syntax zu packen, und diesen bei Verwendung wieder zu parsen.
Das Userinterface würde ich ähnlich aufbauen, wie man das von
Access kennt (Combobox zur Elementauswahl, Combobox zur Eigenschaftaufwahl, Combobox für Vergleichsoperator und Edit für die Bedingung).
Wenn jetzt alles Und-Verknüpfungen oder Oder-Verknüpfungen wären, dann wär's ja nicht so schwierig. Aber ich will ja, dass man die Möglichkeit hat das nach Belieben zu mischen. Und da kommen dann Klammern in Spiel, was die Sache für mich so kompliziert macht.
Und da auch nicht nur die Eigenschaften eines Elements untereinander als Kriterien verwendet werden, sondern alle Eigenschaften aller Elemente in einer Anfrage vorhanden sein können, kann ich zwar den Setter als Trigger verwenden, aber nicht innerhalbe des Elements gleiche die ganze Abfrage durchführen.
Deswegen will ich die Abfrage in separaten Klassen halten, und sie Setter der Elemente lösen einen Event aus, der seinerseits dann die Abfragen benachrichtigt, die ihrerseits dann bei Erfüllung wieder einen Event auslösen.
Mir geht es also um ein solches Klassendesign.