Zugriff auf verschachtelte private Membervariablen
-
Relevant in diesem Zusammenhang:
Law of Demeter
-
Wenn du gesamte Klasse raus gibst, dann gibst du auch alle setter raus.
Und wenn man die gesamte Klasse als konstante Referenz rausgibt, kann man mit den Settern nichts anfangen.
-
Mmh, ja, stimmt, meine Antwort war mehr oder weniger quatsch.
-
Das jemand die Daten des Reifen aendert mag sich loesen lassen. Aber es ist schon schlimm genug das überhaupt irgendwelcher Code geschrieben wird, der direkt mit einem Reifen operiert, der sollte im Idealfall komplett im Fahrrad sein. Ich glaube Bashars Link erklärt das nochmal ausführlicher.
-
Dieser Beitrag wurde gelöscht!
-
@titan99_ sagte in Zugriff auf verschachtelte private Membervariablen:
Kommt das nicht auf die Anwendung an? Was wenn die Reifen ein Loch haben und man sie wechseln oder reparieren muss? Vielleicht kann man es zuweit treiben. Also Reifen bestehen aus Gummi, Gummi bestehen aus Molekülen, usw.
Dann würde der Reparateur auf den Reifen wirken, seinen Gummikleber nehmen und auf das Gummi vom Reifen wirken lassen. Der Kleber nimmt seine Klebemoleküle und lässt diese auf die Moleküle vom Gummi wirken. Jeweils eine Ebene tiefer graben ist auch nach dem Gesetz von Demeter ok. Und das schöne ist nun, dass es dem Reifenreparateur nun total egal sein kann, wie sein Kleber auf Molekularebene arbeitet und der Kleber ist auch nicht auf das Kleben von Gummifahrradreifen beschränkt.
PS: Man glaubt echt nicht, wie gut Law of Demeter wirklich ist, bevor man es nicht selber mal ausprobiert hat.
-
@seppj sagte in Zugriff auf verschachtelte private Membervariablen:
@titan99_ sagte in Zugriff auf verschachtelte private Membervariablen:
Kommt das nicht auf die Anwendung an? Was wenn die Reifen ein Loch haben und man sie wechseln oder reparieren muss? Vielleicht kann man es zuweit treiben. Also Reifen bestehen aus Gummi, Gummi bestehen aus Molekülen, usw.
Dann würde der Reparateur auf den Reifen wirken
Dazu müsste das Fahrrad aber den Reifen doch erst mal rausgeben?
-
@belli sagte in Zugriff auf verschachtelte private Membervariablen:
@seppj sagte in Zugriff auf verschachtelte private Membervariablen:
@titan99_ sagte in Zugriff auf verschachtelte private Membervariablen:
Kommt das nicht auf die Anwendung an? Was wenn die Reifen ein Loch haben und man sie wechseln oder reparieren muss? Vielleicht kann man es zuweit treiben. Also Reifen bestehen aus Gummi, Gummi bestehen aus Molekülen, usw.
Dann würde der Reparateur auf den Reifen wirken
Dazu müsste das Fahrrad aber den Reifen doch erst mal rausgeben?
Ich nehme doch mal an, dass ein Fahrrad den Reparateur an sich ran lässt.
-
Natürlich kann man zu allem immer ein Gegenbeispiel finden, wann es nicht klappt und doch besser anders sein soll. 20 Jahre Erfahrung sagen mir persönlich das man das diese Informationen zu Beginn oft nicht oder unvollständig hat und die Faustformel das zunächst maximal restriktiv zu handeln, die bessere ist.
Wie gesagt finde ich die es im Grunde Quatsch das jetzt mit irgendwelchen Eigenschaften eines realen Fahrrads zu begründen. Meine Idee für "reparien", in einem abstrakten Modell, wäre das alle reparierbaren Komponenten ein "Repairinterface" haben. Teil dieses Interface könnte enthalten, das man einen Vektor mit Subkomponenten mit Repairinterface holen kann, und dann nacheinander überall NeedsRepair() testet. Damit kannst du erstmal mit sehr generischem Code die konkrete Instanz finden, die repariert werden muss. Wenn zum Reparieren aber die Funkion Fahrrad.getReifen() nötig ist, dann sind damit plötzlich ganz viele solche Funktionen nötig, die irgendwo im Reperaturcode stehen müssen, damit der überhaupt an die kaputte Komponente kommt. Das hört sich sehr aufwendig und wartungsintensiv an und wäre für mich ein weiterer Grund, warum Fahrrad.getReifen() nicht existieren sollte.
-
Dieser Beitrag wurde gelöscht!
