Protected Attribute - ja/nein?



  • Normalerweise sollte man ja alle Attribute private machen und falls nötig getter/setter bereitstellen (wenn man nicht gerade nur ne sammlung von daten hat).

    Wie handhabt ihr das bei Attributen bei Basisklassen?
    Macht ihr die protected, oder macht ihr die private und tut bei protected getter für abgeleitete Basisklassen rein?
    Oder je nach Situation (was für Sonderfälle gibt es?)
    Was spricht dafür, was dagegen?



  • Ich mache die Attribute private und wenn nötig protected Operationen. Getter sind ev. ja nicht mal nötig, wenn die "arbeit" in der Basis Klasse stattfinden kann.



  • Q schrieb:

    Wie handhabt ihr das bei Attributen bei Basisklassen?
    Macht ihr die protected, oder macht ihr die private und tut bei protected getter für abgeleitete Basisklassen rein?

    Weder noch. Lieber Tuer als Getter und Setter.
    Attribute nur private.
    Wenn mal ein Getter sein muß, kann der auch public sein.
    Setter sind zu selten, um dafür eine Regel zu haben, fürchte ich.



  • Was meinstn mit Tür?

    Das gleiche wie

    Ich mache die Attribute private und wenn nötig protected Operationen. Getter sind ev. ja nicht mal nötig, wenn die "arbeit" in der Basis Klasse stattfinden kann.

    ?

    Und natürlich geht es nur um Attribute (oder operationen dadrauf), bei denen es überhaupt sinnvoll ist, der abgeleiteten Klasse Zugriff zu geben, und nicht darum, ALLES protected oder mit Getter/Setter zu machen.



  • Mach doch mal ein Beispiel.



  • Q schrieb:

    Was meinstn mit Tür?

    Tuer wie Macher, nicht Tür wie Fenster. Lustiges Wortspiel.



  • Ich frage mich, wie Du auf Getter verzichten kannst. Ich habe einige und könnte die auch nicht wegkriegen, indem ich umstrukturiere. Ich habe einfach komplizierte Verhältnisse zwischen den Strukturen und komme nicht drum herum, manchmal Objekt A um Objekt B zu bitten, weil Objekt C das für irgendwelche Abfragen benötigt. Oder ich benötige Teile von B, dann nehme ich mir diese. Aber die kriege ich ja auch nur wieder über Getter.

    Und in der UI-Programmierung ist es ja noch krasser. Da wird ja mit Gettern und Settern nur so um sich geschmissen. Wie würdest Du ein UI-Framework denn anders aufbauen? Bist Du darüber hinaus nur gegen Getter oder auch gegen Setter?



  • Mehr gegen Setter als gegen Getter. Getter sind nicht böse. Jeder darf mein Objekt jederzeit ausfragen.

    Setter wie setSize() mag ich gar nicht zugunsten von resize(), setZähler()/setNenner() sind auch doof, dafür gibt es den Konstruktor.

    Zugegeben, bei UI-Frameworks wimmelt es davon.



  • Okay, das freut mich. Hatte schon befürchtet, ich hätte etwas Grundsätzliches missverstanden.

    Bei den UI-Dingern dient das halt zur Änderung von Eigenschaften. In der Backend-Schicht werden Dinge ja oft automatisch geändert, wie du es jetzt auch entwickeln würdest. Viel davon wird aber nur auf das UI übertragen. Das ist ja auch normal, das UI hat ja meistens keine komplexe Logik mehr, sondern dient nur als (evtl. adaptiertes) Abbild.

    Und bei QT z.B. dient das dann auch einfach der Erweiterung. Es wird automatisch Code generiert, der die ctors nutzt. Möchte man etwas ändern, ist es also einfacher im Nachhinein Eigenschaften zu ändern, als einen super-dynamischen ctor zu basteln.

    Dein Ansatz geht eben mehr in die Richtung, dass man komplexe Logik implementiert. Dann sollte nicht einfach etwas gesetzt werden, sondern es sollte geschaut werden, wer was macht und wofür verantwortlich ist. Aber im UI trifft das wohl nicht so ganz zu.



  • volkard schrieb:

    Q schrieb:

    Was meinstn mit Tür?

    Tuer wie Macher, nicht Tür wie Fenster. Lustiges Wortspiel.

    Ach... Du meinst doer und nicht door 🤡



  • Da muss man sich ja direkt nach sprachlichen Zusammenhängen zwischen den beiden Wörtern in die Kammer zurückziehen und in der Dunkelheit viele Nächte und Tage meditieren, bis der Mond die Erde mehrfach umkreist hat, um dann zu der Erkenntnis zu kommen, dass...


Anmelden zum Antworten