takidoso
Erfahrenes Mitglied
Hi slowy,
also interessantes Beispiel mit dem Haus und den Räumen. Es verdeutlicht gut was Du meinst.
Also beim lesen was eine Komposition sei, stoße ich auf die generelle Beschreibung, dass ein Teil eines gesammten vergeht so das Gesammte nicht mehr existiere.
Es wird nicht darauf Bezug genommen in wie fern die Klasse selbst, die als Teil verwendet wird, nur in der oder einer Klasse vorkommen darf, die als Gesamtes fungiert.
Es wird auch nichts darüber erzählt, ob das Teilstück nicht auch außerhalb des Gesamtobjekts angesprochen werde darf (pivate/public etc).
In Deinem letzten Beispiel Haus und dem Vermerk, dass die Gabagecollection zuschlägt und in Deine Räume dann natürlich noch stehen bleibt ist tatsächlich erstmal ein Beleg einer implementatorischen Lücke. Sie gilt dann aber nur solange bis die Routine, die sich mal die Liste der Räume gekrallt und aufgehoben hat aufhört, vorausgesetzt, sie egibt die Refferenz auf die Raumliste nicht irgendwie weiter. Ich finde man sollte hier über die Eigenschaft von Java, selbst mit Garbagecolletion aufzuräumen etc. hinwegsehen, oder?
Aus meiner Sicht ist die Intenstion der Modelierung entscheident, nicht unbedingt die Lücke, die innerhalb eines Angebots der spezifischen Sprache übrig bleiben mag.
Wenn man also in dem Haus/Raum Beispiel sicher gehen möchte, dass ja niemals nicht ein Raum außerhalb eines Objektes Haus behalten werden kann, müssen halt alle Manipulationen, die bei einem Raum möglich sind, über (z.B.) Haus delegiert werden, und die Räume selbst dürften dann halt weder einzeln noch als Liste geholt werden können: (also eitwas wie getRaum() oder getRäume() gibt es dann halt nicht).
Ich wage sogar zu meinen, dass Raum nicht unbedingt eine private Klasse sein muss. Kann ja sein dass man Räume auch gerne für sich selbst oder für andere Situatioen verwenden können möchte, was an der "Komposition" Haus dann auch nichts änden würde.
Mit philosophischen Grüßen
Takidoso
also interessantes Beispiel mit dem Haus und den Räumen. Es verdeutlicht gut was Du meinst.
Also beim lesen was eine Komposition sei, stoße ich auf die generelle Beschreibung, dass ein Teil eines gesammten vergeht so das Gesammte nicht mehr existiere.
Es wird nicht darauf Bezug genommen in wie fern die Klasse selbst, die als Teil verwendet wird, nur in der oder einer Klasse vorkommen darf, die als Gesamtes fungiert.
Es wird auch nichts darüber erzählt, ob das Teilstück nicht auch außerhalb des Gesamtobjekts angesprochen werde darf (pivate/public etc).
In Deinem letzten Beispiel Haus und dem Vermerk, dass die Gabagecollection zuschlägt und in Deine Räume dann natürlich noch stehen bleibt ist tatsächlich erstmal ein Beleg einer implementatorischen Lücke. Sie gilt dann aber nur solange bis die Routine, die sich mal die Liste der Räume gekrallt und aufgehoben hat aufhört, vorausgesetzt, sie egibt die Refferenz auf die Raumliste nicht irgendwie weiter. Ich finde man sollte hier über die Eigenschaft von Java, selbst mit Garbagecolletion aufzuräumen etc. hinwegsehen, oder?
Aus meiner Sicht ist die Intenstion der Modelierung entscheident, nicht unbedingt die Lücke, die innerhalb eines Angebots der spezifischen Sprache übrig bleiben mag.
Wenn man also in dem Haus/Raum Beispiel sicher gehen möchte, dass ja niemals nicht ein Raum außerhalb eines Objektes Haus behalten werden kann, müssen halt alle Manipulationen, die bei einem Raum möglich sind, über (z.B.) Haus delegiert werden, und die Räume selbst dürften dann halt weder einzeln noch als Liste geholt werden können: (also eitwas wie getRaum() oder getRäume() gibt es dann halt nicht).
Ich wage sogar zu meinen, dass Raum nicht unbedingt eine private Klasse sein muss. Kann ja sein dass man Räume auch gerne für sich selbst oder für andere Situatioen verwenden können möchte, was an der "Komposition" Haus dann auch nichts änden würde.
Mit philosophischen Grüßen
Takidoso
Zuletzt bearbeitet:
