Design-Pattern gesucht: Daten vergleichen
-
Hallo :)!
Folgendes Szenario:
Ich möchte Daten vergleichen und hab dafür zwei Mengen an Daten, die gleich aufgebaut sind, sagen wir Daten A und Daten B.Jetzt gibt es verschiedene (wissenschaftliche) Möglichkeiten, diese Daten zu vergleichen bzw. auszuwerten. Alle Möglichkeiten haben ein paar Gemeinsamkeiten und dann natürlich ihre eigenen spezifischen Punkte.
Beispiel:
- Alle auswertemöglichkeiten bieten die Option, fehlende Einträge in A und in B zu erkennen (Wie auch immer).
- Auswerteverfahren X bietet zusätzlich die Möglichkeit, Parameter Y zu ermitteln, der eine tolle Aussage über den Zusammenhang zwischen A und B beschreibt.
- Auswerteverfahren Z kann das nicht, bietet aber die Möglichkeit, Parameter Q zu ermitteln, der eine andere tolle Aussage über den Zusammenhang zwischen A und B beschreibt.
Die Auswerteverfahren haben also Gemeinsamkeiten und Ihre spezifischen Unterschiede.
Jetzt überlege ich die ganze Zeit, wie man das schön umsetzen kann bzw. ob es da ein Design Pattern gibt. So das man z.B. ein Interface Comparator hat, wovon die einzelnen Verfahren erben, so dass man einfach das Vergleichsverfahren wechseln kann, ohne das sich viel ändert.
Hat da jemand einen Vorschlag für mich
-
Klingt, das wenn das Strategy-Pattern was wäre.
-
Oder das Schablone Pattern (nur ein Teil eines Algorithmus ist variabel).
-
bergvagabund schrieb:
Oder das Schablone Pattern (nur ein Teil eines Algorithmus ist variabel).
Momentan wäre das Schablone Pattern noch das Pattern, was am ehesten in Frage kommt. Lustigerweise ist die Realisierung des Patterns auch genau der Punkt, wo ich stehen geblieben war - ich wusste nur nicht das es so heißt.
Ich zitiere mal:
Einschubmethoden, die ein Defaultverhalten anbieten, das von Unterklassen bei Bedarf erweitert werden kann. Eine Einschubmethode macht oftmals per Default gar nichts
Diese Einschubmethoden würden in eine abstrakte Basisklasse (oder eben Interface integriert werden). Ich finde es aber noch unschön, dass dann die Basisklasse bspw. die Methode getResultParamQ() besitzt, die für 3 Algorithmen irgendeinen ungültigen Wert zurückliefert und nur von einem Algorithmus implementiert wird.
Ich dachte, dass das insgesamt noch viel schöner geht
-
E_SUM schrieb:
Ich finde es aber noch unschön, dass dann die Basisklasse bspw. die Methode getResultParamQ() besitzt, die für 3 Algorithmen irgendeinen ungültigen Wert zurückliefert und nur von einem Algorithmus implementiert wird.
Dann sind es eben zwei verschiedene Dinge. Dann sollten die Vergleiche der Auswertemöglichkeiten, wenn die Vergleiche denn verschieden sind, über Strategien gefahren werden und die zusätzliche Funktionalität extra implementiert werden.
Man könnte sich hier neben Strategie und Template method sich zusätzlich noch ein Inversion of control/dependency injection vorstellen:
* Ein Objekt A hält beide Daten
* ein controller erkennt was verwendet werden muß und übergibt A den benötigten Vergleicher und evtl Zusatzbewerter
* A präsentiert diesen Strategien seine Daten
* A oder die Strategieobjekte besitzen danach die Ergebnisse