Zugriff auf verschachtelte private Membervariablen



  • Hi,

    ich habe eine Frage, was schöner ist zu programmieren.

    Also angenommen ich habe eine Klasse namens Fahrrad. Diese Klasse hat wiederum eine private Membervariable mit dem Namen Reifen. Reifen ist auch wieder eine Klasse, die wiederum die Funktion "getDruck()" definiert.

    Jetzt ist die Frage, wie ich am besten auf den Reifendruck von aussen zugreife.

    Sollte ich das lieber implementieren als:
    "Fahrrad.getReifen().getDruck()"
    oder ist es besser mit:
    "Fahrrad.getReifenDruck()"

    Also die Frage ist, sollte ich für jede private Membervariable einen separaten Getter erstellen, oder lieber eine Funktion, die gleich auf den Druck durchreicht.

    In meiner echten C++ Applikation ist die Verschachtelung noch was tiefer.

    Hoffe, ich habe das verständlich formuliert 🙂



  • Besser du gibst den ganzen Reifen zurück, dann hast du auch Zugriff auch andere möglichen Eigenschaften.



  • @alatar

    Für was brauchts du denn den Druck des Reifens? Also beim Fahrrad würde ich dann z.B. je nach Verwendung bool Fahrrad.Fahrbereit() machen (Also einfach als Ergänzung, weiss nicht ob es sinnvoll wäre).



  • Da es sich hier wohl über einen abstrakten Sachverhalt handelt, ist die Entscheidung ob nun der „Reifen“ rausgereicht wird oder das „Fahrrad“ Reifen-Methoden hat davon abhängig, ob der „Reifen“ ggf. ganz privat dem Fahrrad gehört.

    Nehmen wir ein anderes Beispiel um das zu verdeutlichen; Klasse „Hotel“ mit „Zimmern“ und der Frage ob dieses Zimmer frei ist. Das Zimmer kann wohl wissen, dass es selbst frei ist. Aber ggf. wollen wir es dem „Hotel“ überlassen, wie es mit seinen Zimmern umgeht um ihm z.B. zu erlauben einen Gast von ein Zimmer in ein anderes zu verschieben. In diesem Fall wäre ein Liefern des einzelnen Zimmers nicht zielführend.

    Um wieder auf den „Reifen“ zurück zu kommen. Den kann ich auch ohne Fahrrad z.B. aufpumpen und somit würde ich diesen vom Fahrrad, wie von @spiri vorgeschlagen „liefern“ lassen.
    mfg



  • Allgemein ist die Variante die gesamte Klasse rauzugeben oft mit vielen Problemen behaftet und ich würde als Faustregel möglichst darauf verzichten. Das mit Real World Logik zu begründen, halte ich immer für sehr fragwürdig.



  • @tggc sagte in Zugriff auf verschachtelte private Membervariablen:

    Allgemein ist die Variante die gesamte Klasse rauzugeben oft mit vielen Problemen behaftet

    Könntest Du mal ein, zwei nennen?



  • @belli

    Ich sehe das zwar pauschal nicht so problematisch wie TGGC, aber ein Problem sind sicherlich die setter.
    Wenn du gesamte Klasse raus gibst, dann gibst du auch alle setter raus.
    Und für jede Instanz an sich, kann eine Änderung ok sein (wird durch den setter gesichert), aber im Kontext meiner Klasse ist das vielleicht nicht ok (z.B. 2 Reifen , deren Druck sich nicht zu sehr unterscheiden darf, selbst wenn jeder Druck für sich okay ist).



  • Sogesehen kannst du deine Reifen sogar public deklarieren, schließlich sind sie kein Implementierungsdetail, und der Dieb, der dir die Reifen abmontiert braucht somit keine bereitgestellte Methode des Fahrrads.

    Schlussendlich entscheidest du selbst als Programmierer, wie die Reifen zu benutzen sind. Du solltest also weniger darauf achten mögliche Fehler zu umgehen und mehr Wert darauf legen das Teil designmäßig korrekt zu implementieren.

    Ich weiß ja nicht wie weit deine Abstraktionen gehen sollen, aber bei solchen Übungen wie mobilen Geräten kannst du da schon ziemlich weit ausholen. Beispielsweise könnte deine Fahrrad-Klasse auch von öffentlichen Reifen-Aggregaten profitieren, schließlich müssen die Reifen nicht gleich mit dem Fahrrad untergehen, sondern können auch abmontiert und unabhängig vom Fahrrad in der Ecke liegen.

    EDIT: Statt getter/setter einfach nur public.



  • @belli sagte in Zugriff auf verschachtelte private Membervariablen:

    @tggc sagte in Zugriff auf verschachtelte private Membervariablen:

    Allgemein ist die Variante die gesamte Klasse rauzugeben oft mit vielen Problemen behaftet

    Könntest Du mal ein, zwei nennen?

    Hier ganz konkret? Wenn man das Projekt weiterentwickelt, merkt man evtl. das Der Druck nicht allein vom Reifen abhängt, sondern auch vom Gewicht des Fahrrads. Wenn es jetzt tausend Stellen gibt, die von Reifen den Druck abrufen statt vom Fahrrad hast du einen Riesen Umbau.

    Wenn du einmal den Reifen rausgibst, hast du keine Kontrolle mehr, wo der überall hin weitergereicht wird. Konsequent angewandt, fuehrt dieses Schema dazu, dass überhaupt nichts mehr gekapselt ist.



  • Relevant in diesem Zusammenhang:
    Law of Demeter



  • @jockelx

    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.



  • @daddy_felix

    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.



  • @tggc sagte in Zugriff auf verschachtelte private Membervariablen:

    der sollte im Idealfall komplett im Fahrrad sein

    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.

    @tggc sagte in Zugriff auf verschachtelte private Membervariablen:

    Das mit Real World Logik zu begründen, halte ich immer für sehr fragwürdig.

    Leuchtet mir zwar ein 🌄


  • Global Moderator

    @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?


  • Global Moderator

    @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.



  • @tggc sagte in Zugriff auf verschachtelte private Membervariablen:

    Das mit Real World Logik zu begründen, halte ich immer für sehr fragwürdig.

    Also finde ich auch. Also zum Fahrrad bei Anwendungen kommen mir Fahrräder in Games oder eine Bürosoftware für den Velohandel in den Sinn.

    Ich schreibe bei Klassennamen den Anfangsbuchstaben immer gross (Wollte das nicht in die Welt setzen), also gleich wie beim Substantiv (in der normalen Sprache). Verben wären dann wohl eher Funktionen. Verben kann man glaube ich in Substantive "umformen". tun als Verb. Das Tun als Substantiv.

    😴 🙄