Laden...

Klasse weit unten in der Hierarchie, wie Properties zugänglich machen

Letzter Beitrag vor 2 Jahren 6 Posts 560 Views
Klasse weit unten in der Hierarchie, wie Properties zugänglich machen

Hallo,

ich habe folgende Frage:

In meinem Projek gibt es einige Klassen, die sich weit unten in der Hierarchie befinden, also weit innerhalb des Models. Diese berechnen z.B Filterdaten und müssen über die UI einstellbar sein (Filterfrquenz) . So gibt es z.B. eine Klasse, die die Versuchsdaten berechenet, darin befindet sich dann die Filterklasse usw. Nun Frage ich mich, ob ich die Properties bis nach oben durchreiche und so zugänglich mache oder ob ich besser eine Setup-Dependency injiziere, die ich dann an anderer Stelle im ViewModel ändern kann? Wie wäre da der saubere Weg?

Danke und Grüße, Alex

Final no hay nada más

Könntest Du nicht den Filter als "Wrapper" (Adapter) um Deine Modell-Klasse herum bauen?
Adapter (Entwurfsmuster)

Somit könnte der Filter die relevanten Modell-Properties einfach durchreichen (mit entsprechender Filterung) und zugleich seine "eigene" Properties (zum Einstellen der Filter-Parameter) ergänzen.

Ungefähr so:


new Filter(new Model());


Ansonsten wäre noch ein "Strategy" Pattern denkbar, so dass Du direkt auf das Filter-Objekt zugreifen kannst ohne dessen Properties durchreichen zu müssen:
Strategie_(Entwurfsmuster)


filter = new Filter();
model = new Model();
model.setFilter(filter);

Hallo Weressated,

ich muss gestehen, dass ich deine Antwort nicht ganz verstehe. Vielleicht habe ich zuwenig Informationen über mein Problem geliefefert. Ich versuche mal, es zu konkretisieren.
In meiner Anwendung geht es darum, dass aus einer Hardware ein Satz Messdaten kommt und der dann verarbeitet werden soll. Das Filtern ist nur eine Schritt davon, der innerhalb der Verarbeitung passiert. So werden die Daten gefiltert, dann mit Referenzwerten verglichen, noch andere Parameter berechnet und viele dieser Dinge müssen einstellbar sein. Es gib also mehrere Klassen, die einstellbare Parameter haben und das möchte ich möglichst sauber umsetzten.

Final no hay nada más

Also die Idee wäre, dass man die Filter-Klasse so baut, dass sie im Konstruktor das konkrete Modell übergeben bekommt, aus dem sich das Filter dann "intern" seine Eingabe-Daten holt.

Nach "außen" hin stell die Filter-Klasse die gefilterten Properties/Daten bereit, plus zusätzlich Poperties um die Filter-Parameter einstellen zu können.

Entscheidend ist, dass die Model-Klasse somit nichts über die konkrete Filter-Klasse wissen muss. Insbesondere muss das Modell keine Filter-Parameter durchreichen. Filter können leicht ausgetauscht werden, ohne Modell anzupassen.

(Die Filter-Parameter könnten ja auch bei jeder konkreten Filter-Implementierung andere sein!)


Alternativ kannst Du dem Modell über eine SetFilter() Methode das konkrete Filter zuweisen. Das Modell verwendet dann "intern" den jeweiligen Filter, um die Daten zu filtern.

Es müsste dafür eine geeignete Filter-Schnittstelle (z.B. IFilter) geben, die von allen konkreten Filtern implementiert wird.

Entscheidend ist wiederum, dass die Model-Klasse nichts über die konkrete Filter-Klasse oder deren Parameter wissen muss. Die Modell-Klasse muss nur das Filter-Interface kennen/nutzen.

Das Model weiß auch so nichts über den Filter, kennt nur das Interface. Messdatenerzeugung, Filter usw. habe ich als Interfaces und Contructor Injection injiziert. Meine Frage ist eher, wie verheirate ich das mit dem Viewmodel.

Final no hay nada más

Das Model weiß auch so nichts über den Filter, kennt nur das Interface. Messdatenerzeugung, Filter usw. habe ich als Interfaces und Contructor Injection injiziert. Meine Frage ist eher, wie verheirate ich das mit dem Viewmodel.

Als ich würde sagen, entweder sind aus Sicht des Views dann das "Messdaten-Model" und das "Filter" zwei separate Models, die jeweils ihre eigenen Properties haben.

Das "Messdaten-Model" liefert Daten (die evlt. gefiltert wurden, was das View an der Stelle aber nicht zu wissen braucht) und "Filter" liefert Filter-Parameter.

...oder, wenn es unbedingt eine Model-Klasse sein soll, man schaltet da nochmal eine Façade-Klasse als "allumfassendes" Model bzw. Abstraktionsschicht davor, welches die Unterscheidung zwischen "Messdaten-Model" und "Filter" vor dem View versteckt.

Siehe:
Fassade (Entwurfsmuster)