Objekte verschiedener Kindklassen vergleichen

Ich hab schon wieder was wichtiges vergessen zu schreiben:

Folgendes Vorgehen halte ich für ganz wichtig, egal ob du FGV oder OOP machst:

• 1. Festlegen: Was sieht der Anwender? Was muss/will/kann der Anwender tun während der Dateneingabe? Brauche ich hier in besonderes Datenmanagement?
• 2. Festlegen: Wie sieht mein Datensatz aus, den ich für die Applikation brauche? Der Datensatz liegt bei mir immer in einem Cluster. Vorteil: ein Wire (in Zahl: 1).
• 3. Wie sieht das Datenmanagement aus zwischen Punkt 1 und Punkt 2: Der Cluster, der in der Applikation verwendet wird, muss in keinster Weise mit dem identisch sein, den der Anwender sieht (das meine ich mit Trennung des FP von den Daten). Mehrmals hatte ich bereits den Fall, dass der Anwender eine Tabelle ("2D-Arr of String") und einige Einzelwerte gesehen und bearbeitet hat, in der Applikation ist es aber besser zu arbeiten mit einem Cluster, der Einzelwerte, Cluster und ArrOfCluster enthält. Einen "Konverter" zu machen zwischen diesen beiden "Systemen" ist überhaupt kein Problem.
  

Diese Betrachtungen sind unabhängig von der Programmiersprache (also auch unabhängig davon ob du in LV OOP oder FGV machst).

"Applikation" ist in deinem Falle das Settingsmodul.

In deinem Falle, nämlich ein vom Datensatz abstrahiertes Settingsmodul, muss der Punkt 3 gewissenhaft bedacht werden - unabhängig ob OOP oder FGV. Natürlich muss du hier auch Vorausschau betreiben (was du ja gemacht hast): Was ist, wenn ich das SettingsModul erweitern muss? Wird das gehen? Wie schwierig wird das sein?

In deinem Falle muss auch genau geklärt werden, was denn Punkt 2 genau ist: der original Datensatz diverser Module? Oder dieser originale Datensatz zusammen mit einem Beschreibungsdatensatz (dass das dann praktisch zwei Datensätze sind, ist irrelevant). Den Beschreibungsdatensatz muss das diverse Modul liefern - nur das weiß nämlich, wie seine eigenen Daten beschrieben werden müssen. Allerdings wird die Struktur des Beschreibungsdatensatzes vom Settingsmodul bestimmt.


Diese Überlegungen müssen vor dem Start der Programmierung geschehen, um die unnützen Zeiten während der Programmierung zu minimieren. Im Normalfall sind diese Überlegungen innerhalb einer Zigarettenlänge (oder Kaffeepause, wer dieser Droge frönt) erledigt. Nicht aber bei einem abstrahierten Modul.