OOP-Theorie Gleichartige Objekte

[somunium]

Hallo zusammen.

Ich hab kein direktes Problem, eher eine Theoretische Frage mit leicht philosophischem Hintergrund

Es geht um das Handling von mehreren gleichartigen Objekten innerhalb einer Klasse. (Gleichartig bedeutet, dass einige Eigenschaften in der Klasse zwar variabel sind, aber bei allen Instanzen der Klasse identisch sein sollen)
Ein Beispiel aus der Praxis:

Wir wollen Diagramme mit mehreren Datenreihen darstellen.

Also haben wir eine Klasse 'diagram', und als Unterklasse, in 'diagram' in einem Array gespeichert, die Klasse 'datenreihe'.

Jetzt möchte man sichergehen, dass alle Unterobjekte von 'datenreihe' auch die selbe Anzahl an Datenpunkten haben, mit den selben Bezeichnungen auf der X-Achse (zum Beispiel sollen alle Datenreihen einen Zeitraum von einer bestimmten Woche darstellen).

Innerhalb der Klasse 'datenreihe' wird das recht haarig, da man ja nicht ohne weiteres auf die anderen Objekte zugreifen kann/sollte.
Und die Gleichheit in der Elternklasse sicherzustellen erscheint mir ebenfalls nicht ganz ideal, da man hier dann keinen Einfluss innerhalb der 'datenreihe'-Klasse hat, Prüfungen also von Außerhalb geschehen müssen.


Die Ideen, die ich hatte, war, mit einer Dummyinstanz von 'datenreihe' zu Arbeiten, welche auf alle anderen referenziert wird (heißt, wenn ich in unserem Wochenbeispiel in einer x-Beliebigen Instanz von 'datenreihe' den Mittwoch hinzufüge, dass in der Dummyinstanz dies ebenfalls automatisch passiert, und sich alle anderen Instanzen dann auf die Dummyinstanz zugreifen, wenn sie sich selbst auf Plausibiltät prüfen.)

Wie handhabt Ihr so etwas?
Ist überhaupt klar, was ich meine?

Lieben Gruß
Lukas

 

[Ni_hil]

hi,

Also haben wir eine Klasse 'diagram', und als Unterklasse, in 'diagram' in einem Array gespeichert, die Klasse 'datenreihe'.

Du bringst hier die Begriffe noch ein wenig durcheinander.
Eine Unterklasse ist eine Klasse welche von einer Oberklasse erbt.
Bsp: Fortbewegungsmittel (Oberklasse) <- Auto (Unterklasse)
Wenn ich Dich richtig verstehe, dann hast Du nur eine Beziehung zu anderen Klassen. Also ein einfaches Attribut, welches ein Array ist.
Diagram hat mehrere Datenreihen, welche durch einen Array verwaltet werden. Vom Beziehungstyp würde ich hier eine Komposition wählen. (Die Datenreihen dürfen nicht ohne ein dazugehöriges Diagram existieren)

Jetzt möchte man sichergehen, dass alle Unterobjekte von 'datenreihe' auch die selbe Anzahl an Datenpunkten haben, mit den selben Bezeichnungen auf der X-Achse (zum Beispiel sollen alle Datenreihen einen Zeitraum von einer bestimmten Woche darstellen).

Wenn Du nun einen neuen Wert (Mittwoch) hinzufügst, dann würde das so aussehen Diagram.addDatenreihe(Mittwoch) und das Diagramm könnte dann das Array durchlaufen und alle Reihen erweitern. Macht für mich von der Logik her gesehen Sinn.

Und die Gleichheit in der Elternklasse sicherzustellen erscheint mir ebenfalls nicht ganz ideal, da man hier dann keinen Einfluss innerhalb der 'datenreihe'-Klasse hat, Prüfungen also von Außerhalb geschehen müssen.

Da wir wie oben beschrieben eine Komposition einsetzen, wird es keine Datenreihe ohne das dazugehörende Diagramm geben. Also existiert immer die "Kontrollklasse".

Ich hoffe ich habe Dein Problem richtig verstanden ;-)
Ich würde die Kontrolle dem Diagramm überlassen. Dazu gehört auch das hinzufügen und entfernen von neuen Werten, diese Funktionen werden am Diagramm aufgerufen. (hab jetzt aber auch nicht groß drüber nachgedacht )

 

[anegmawad]

Wenn ich dich richtig verstanden haben sollte, dann helfen dir Multitones (Twintones) und Copy-on-Write (CoW) weiter.

Ganz kurz, in Band 2 gibt es das ausführlich:

Beim Twintoning verhält es sich so, dass sämtliche (unveränderlichen!) Instanzen einer Klasse in Wahrheit nur eine Instanz sind. Du hast zum Beispiel eine Number mit dem Integerwert 5. Jedes Mal, wenn du eine neue Instanz mit diesem Wert anforderst, schaust du zunächst nach, ob du bereits eine mit diesem Wert erstellt hast. Ist dies der Fall, dann gibst du diese alte Instanz zurück. Das setzt aber voraus, dass die Instanzen unveränderlich sind.

Beim Copy-on-Write erstellst du neue Instanzen erst bei Bedarf, nämlich bei Änderung. Das denkst du dir schon ganz richtig: Du erstellst im Vordergrund eine sehr kleine Instanz, die im Wesentlichen einen Verweis auf den Hintergrund hat. Sobald der Vordergrund verändert wird (was er in Wahrheit ja gar nicht wird, da er die Änderung nur an den Hintergrund weiterreicht), erzeugst du jetzt eine Kopie des Hintergrundes und änderst nur die Kopie.

Übrigens habe ich mir als Beispiel ebenfalls Messdaten ausgesucht, weil –*neben meinem persönlichen Hintergrund – du genau hier das Problem hast, dass du möglicherweise zahlreiche Instanzen mit gleichem Wert hast, die sehr groß sind und die nur selten geändert werden.

 

[torbenH]

Hallo zusammen,

eins vorweg: ich bin vielleicht ein bisschen kleinlich, ist nicht böse gemeint.

Wenn Du nun einen neuen Wert (Mittwoch) hinzufügst, dann würde das so aussehen Diagram.addDatenreihe(Mittwoch) und das Diagramm könnte dann das Array durchlaufen und alle Reihen erweitern. Macht für mich von der Logik her gesehen Sinn.

So wäre ein korrekter Entwurf unter den angenommenen Umständen (Komposition), ja. ;-)

Da wir wie oben beschrieben eine Komposition einsetzen, wird es keine Datenreihe ohne das dazugehörende Diagramm geben. Also existiert immer die "Kontrollklasse".

Und hier kommen jetzt die Probleme... Wenn es keine Komposition, sondern bloss Aggregation ist, also die Datenreihen bspw. in einem anderen Zusammenhang erstellt/gemessen werden und daher alleine für sich existieren können, wird das etwas umständlicher.
In so einem Fall könnte man aber dennoch in der "Aggregations-Klasse" (Diagramm) gewisse Kriterien festlegen, denen die hinzugefügten einzelnen Datenreihen genügen müssen. Beispielsweise die Anzahl der Messpunkte o.ä..

Ich hoffe ich habe Dein Problem richtig verstanden ;-)
Ich würde die Kontrolle dem Diagramm überlassen.

Da stimme ich absolut zu.
Es geht ja gewissermaßen um die Plausibilitätsprüfung des Diagramms. Die kann - tada - auch nur das Diagramm erledigen. ;-)

 

[Ni_hil]

Hallo zusammen,

eins vorweg: ich bin vielleicht ein bisschen kleinlich, ist nicht böse gemeint.


So wäre ein korrekter Entwurf unter den angenommenen Umständen (Komposition), ja. ;-)


Und hier kommen jetzt die Probleme... Wenn es keine Komposition, sondern bloss Aggregation ist, also die Datenreihen bspw. in einem anderen Zusammenhang erstellt/gemessen werden und daher alleine für sich existieren können, wird das etwas umständlicher.
In so einem Fall könnte man aber dennoch in der "Aggregations-Klasse" (Diagramm) gewisse Kriterien festlegen, denen die hinzugefügten einzelnen Datenreihen genügen müssen. Beispielsweise die Anzahl der Messpunkte o.ä..


Da stimme ich absolut zu.
Es geht ja gewissermaßen um die Plausibilitätsprüfung des Diagramms. Die kann - tada - auch nur das Diagramm erledigen. ;-)

Kein Problem, stimmst mir ja größtenteils eh zu. ;-)