protected setter sinnvoll?



  • Hallo,

    ist es eigentlich sinnvoll, einen protected setter (auf eine private Variable) der entsprechenden protected Variablen vorzuziehen?

    Also statt:

    class A
    {
       protected:
          int a;
    }
    

    so:

    class A
    {
       private:
          int a;
    
       protected:
          void seta(int b) 
          {
             a = b;
          }
    }
    

    Dadurch kann ich ja festlegen, wie die vererbte Klassen auf a zugreifen.
    Ist sowas sinnvoll? Leider finde ich im Internet garnichts dazu.



  • Kann schon Sinn machen.
    Gibt Fälle wo man nach dem Setzen des Wertes noch andere Dinge updaten muss. Oder ne Range prüfen will. Oder halt irgendwas mehr als nur m_a = a; machen.

    Deswegen muss man das aber nicht gleich bei allen seinen Klassen so machen.



  • Mir sind bisher kaum Fälle vorgekommen, wo protected Variablen/Setter überhaupt sinnvoll waren.



  • protected ist effektiv genauso offen wie public, also würde ich mal vermuten, dass protected-Setter der Default sein sollten (wenn man überhaupt irgendwas protected haben will.)



  • Ganz klar: Nur Setter sind erlaubt.

    http://www.gotw.ca/gotw/070.htm

    In short, public data is evil (except only for C-style structs).

    Likewise, in short, protected data is evil (this time with no exceptions). Why is it evil? Because the same argument above applies to protected data, which is part of an interface too -- the protected interface, which is still an interface to outside code, just a smaller set of outside code, namely the code in derived classes. Why is there no exception? Because protected data is never just a bundle-o-data; if it were, it could only be used as such by derived classes, and since when do you use additional instances of one of your base classes as a convenient bundle-o-data? That would be bizarre. For most on the history of why protected data was originally permitted, and why even the person who campaigned for it now agrees it was a bad idea, see Stroustrup's The Design and Evolution of C++.[3]

    From the GotW coding standards:

    - encapsulation and insulation:

    - always keep class data members private (Lakos96: 65-69; Meyers92: 71-72; Murray93: 33-36)

    - except for the special case where all class members are public (e.g., C-style struct)



  • Oh, die Evangelisten!

    Ja, man kann diesen Standpunkt argumentieren. Wenn, dann aber bitte richtig.

    Protected Setter (genau so wie public Setter), sind meist nicht das was man möchte. Statt dessen sollte man sich überlegen welche Operationen man eigentlich anbieten möchte, und für diese dann Funktionen bereitstellen. Und meist sind das dann keine einfachen Setter mehr.

    Das ist der Knackpunkt bei der Sache. Einfach nur GetX/SetX Funktionen statt einer public/private Varialbe X anzubieten ohne weiter darüber nachzudenken macht auf jeden Fall keinen Sinn.



  • hustbaer schrieb:

    Das ist der Knackpunkt bei der Sache. Einfach nur GetX/SetX Funktionen statt einer public/private Varialbe X anzubieten ohne weiter darüber nachzudenken macht auf jeden Fall keinen Sinn.

    Für jemanden, der nicht darüber nachdenkt, sind Getter/Setter genau das richtige! Man erlangt Freiheit darüber, wie das Memory-Layout aussieht, man behält sich vor, nachträglich Checks einzuführen, usw.

    Bleibt die Frage, ob es einen begründeten Fall gibt, wo eine protected Varialbe der Einfachheit habler Get/Set vorzuziehen sind. Und nein, dieser Fall ist mir noch nie vorgekommen.



  • In C++ solltest du Vererbung sowieso vermeiden. Templates sind dein Freund. 🙂



  • mortified_penguin schrieb:

    ist es eigentlich sinnvoll, einen protected setter (auf eine private Variable) der entsprechenden protected Variablen vorzuziehen?

    Vermutlich nicht, protected setter verwende ich seltener als switch oder goto oder exit().



  • protector schrieb:

    In C++ solltest du Vererbung sowieso vermeiden. Templates sind dein Freund. 🙂

    Was soll der Mist?



  • quotator schrieb:

    hustbaer schrieb:

    Das ist der Knackpunkt bei der Sache. Einfach nur GetX/SetX Funktionen statt einer public/private Varialbe X anzubieten ohne weiter darüber nachzudenken macht auf jeden Fall keinen Sinn.

    Für jemanden, der nicht darüber nachdenkt, sind Getter/Setter genau das richtige!

    Aber sollte man jemanden, der nicht darüber nachdenkt, überhapt programmieren lassen?
    Also sicherlich sollten sich keiner der Neulinge hier im Board einen Stil angewöhnen, der für Leute gut ist, die nicht darüber nachdenken.
    Getter sind Ok. Aber statt Settern bitte Mover/Shrinker/Sorter nehmen.

    quotator schrieb:

    Man erlangt Freiheit darüber, wie das Memory-Layout aussieht, man behält sich vor, nachträglich Checks einzuführen, usw.

    Sie sind besser als public Attribute, klar. Aber noch schlecht.

    quotator schrieb:

    Bleibt die Frage, ob es einen begründeten Fall gibt, wo eine protected Varialbe der Einfachheit habler Get/Set vorzuziehen sind. Und nein, dieser Fall ist mir noch nie vorgekommen.

    So ist es. Trotzdem kein Grund für Setter.

    Wo hab ich nochmal Setter sinnvoll erleben dürfen? *grübel*…
    Glaube, das war bei GUI-Programmierung dlg.SetCaption("Wichtig");. Kann mich gerade nicht daran erinnern, warum es kein Konstruktorargument war. Ah, um die Überschrift blinken lassen zu können. Bei Monsterklassen sind Setter doch tatsächlich übersichtlicher, als Mover/Shrinker/Sorter.
    Naja, da erlebt man sogar protected Attribute in freier Wildbahn.

    Ich halte es so, daß ich im Modell recht genau auf Programmiestil achte, aber bei der Oberfläche einfach rumhure.



  • volkard schrieb:

    Ich halte es so, daß ich im Modell recht genau auf Programmiestil achte, aber bei der Oberfläche einfach rumhure.

    Und daher

    hustbaer schrieb:

    Deswegen muss man das aber nicht gleich bei allen seinen Klassen so machen.


Log in to reply