Best Practice Unschlüssig ob Vererbung oder Interface

[Bela B.]

Nabend zusammen,

ich bin schon seit einer Weile daran, ein von mir geschriebenes Programm noch einmal neu aufzurollen.
Mein bisheriger Ansatz funktioniert und macht genau das, was im Lastenheft gefordert ist, allerdings bin ich mit der Wartbarkeit des Codes nicht wirklich zufrieden. Die Aufteilung der Zuständigkeiten zwischen GUI und Logik ist noch nicht so ganz da, wo ich sie gerne hätte. Auch die einzelnen Komponenten heißen teilweise zu Ähnlich und sind nicht ganz voneinander Abgegrenzt.

Daher mache ich mir jetzt vorab mehr Gedanken, wie ich das Aufziehen kann.
Für die Trennung von GUI und Rest verwende ich dieses mal mvvmFX, damit habe ich jetzt schon einige kleine Beispielprojekte umgesetzt, damit so eine grobe Ahnung davon habe, wie ich damit arbeite.

Doch vorab macht mir die Aufteilung der eigentlichen Logik probleme.
Hoffe ihr könnt mir hier etwas helfen.
Zweck des Programms: Temperaturprofile auswerten

Die Profile bestehen aus einer Excel-Datei, die Maschinell vom Temperaturlogger erstellt wird. Es gibt eine Datumsspalte, die auf die Sekunde genau den Aufzeichnungszeitpunkt beinhaltet, also z.B. alle 10 Sekunden werden neue Werte aus den Temperaturfühlern ausgelesen.

Die Anzahl der Fühler ist variabel, also 1 bis x. Das sind die Spalten danach.

Diese Daten sollen dann je nach Ofen bestimmte Checks durchlaufen. Vorab bestimmt der Prozessverantwortliche die Checks, die gemacht werden sollen.
Es gibt folgende Checks:

• Temperatur für Zeitraum x im Bereich von y und z
• Temperaturüberschwinger nicht höher als Temperatur x für Zeitspanne y
• Steigung des Temperaturanstiegs nicht größer als x im Zeitraum y
• Abstand zwischen den Temperaturfühlern nicht größer als x Grad

Das Checks können mehrfach definiert sein, so kann z.B. ein Ofen ein Profil fahren, das zwei mal den Plateau erreicht.

Meine Überlegung:

1. Ein Interface, das die eigentlichen Checks beschreibt. Darin dann eine Methode execute, die den eigentlichen Check ausführt und True/False zurückgibt.
2. Abstrakte Klasse, von der die konkreten Checks erben.

Die Checks haben gewisse Dinge gemeinsam, so besitzen sie alle einen Namen, haben je Temperaturfühler einen Merker, wann bei dem jeweiligen Temperaturfühler der Check gegriffen hat (also im Falle von Temperatur für Zeitraum x im Bereich von y und z der erste Messpunkt, der die Temperatur y erreicht hat und ggfs. z überschritten hat).

Was spricht eurer Meinung nach für welche Vorgehensweise? Oder würdet ihr ganz was anderes machen?
Und sorry für den längeren Text, aber ich denke da kommen vllt. noch mehr Fragen von mir, dann ist das ganze schon einmal ganz gut überrissen.

 

[LimDul]

So aus dem Bauch heraus - beides

Grundsätzlich ist ein Interface eine gute Idee. Das mit den entsprechenden Schnittstellen versehen, die es braucht. Die execute Methode z.B. , eine Methode die einen Namen zurückgibt etc.

Davon dann die konkreten Check-Klassen erzeugen. Wenn du dann z.B. bei der 3ten Klasse feststellt, du hast da den gleichen Code wie in den ersten beiden Check-Klassen => Abstrakte Oberklasse draus extrahieren und Logik in die Oberklasse verschieben. So gewinnst du meines Erachtens das beste aus beiden Welten:

- Mit dem Interface (was du überall da verwenden solltest, wo die Checks verwendet werden) stellst du sicher, dass du eine klar definierte API hast und flexibel für Erweiterungen bist. Alles, was du im Interface definierst hast, sind ja Methoden die an anderer Stelle im Programm benötigt werden (Was nicht benötigt wird, wird nicht definiert). Das hält dir z.B. die Flexiblität offen einen "CompositeCheck" zu definieren, der mehrere Checks bündelt. Der hat vielleicht keinen eigenen, gespeicherten Namen sondern einen Namen der sich aus den gebündelten Checks zusammensetzt. Diese Flexibilität hast du nicht bzw. nur eingeschränkt, wenn du nur eine Abstrakte Basisklasse hast. Denn in der abstrakten Klasse hast du Felder und Zustände drin - du machst damit Vorgaben über den internen Zustand, den jeder Check erfüllen müsste. Das schränkt unter Umständen ein.
- Mit der abstrakten Klasse, die zwischen dem Interface und den (meisten/allen) Checks liegt verhinderst du aber dass du Dinge doppelt implementieren musst. Du nutzt diese Klasse aber eben nicht als Vorgabe "Alle Checks müssen diese interne Implementierung und Zustand haben" sondern als "Checks, bei denen diese interne Implementierung und Zustand identisch sind, können diese nutzen." Aus dem Muss wird so ein Soll und lässt dir Raum für Erweiterungen.

 

[Bela B.]

Danke, bin gerade dabei, die Struktur mit Interface und abstrakten Basisklassen für ähnliche Tests umzusetzen.