Sinn von protected

[Der Tobi]

Stimmt, Konstruktoren hab ich auch schon protected gemacht. Gibts noch mehr?

Prinzipiell alles, was nach außen unsichtbar in abgeleiteten Klassen aber sichtbar sein soll. Was das genau ist kommt auf dein Design/Projekt an, das kann man so pauschal nicht sagen.

[out]

dot schrieb:

Warum virtual, wenn er eh schon protected ist?

Hast recht. Hab ich Müll geschrieben.
Korrektur: protected + non-virtual (oder eben public + virtual)

[merkantilist]

Der Tobi schrieb:

Was das genau ist kommt auf dein Design/Projekt an, das kann man so pauschal nicht sagen.

In meinem Design/Projekt kommt protected eben nicht vor. Nun frag ich mich ernsthaft, ob das ein Designfehler ist, weil ich protected nicht richtig verstanden habe.

Was es als Schlüsselwort macht, ist mir klar. Nur kann ich mir nicht vorstellen, wo es sinnvoll sein könnte. Wäre nett, wenn du ein Beispiel aus deinem Projekt geben könntest, wo du protected verwendest.

[dot]

merkantilist schrieb:

In meinem Design/Projekt kommt protected eben nicht vor.

merkantilist schrieb:

Nun frag ich mich ernsthaft, ob das ein Designfehler ist, weil ich protected nicht richtig verstanden habe.

Ganz im Gegenteil. protected braucht man eben relativ selten, dass du ohne auskommst, ist eher ein gutes Zeichen. Nur weil ein Sprachmittel existiert, heißt das noch lange nicht, dass man es auch verwenden muss...

[Sone]

merkantilist schrieb:

Was es als Schlüsselwort macht, ist mir klar. Nur kann ich mir nicht vorstellen, wo es sinnvoll sein könnte. Wäre nett, wenn du ein Beispiel aus deinem Projekt geben könntest, wo du protected verwendest.

Das protected existiert, heißt nicht, dass es verwendet werden muss. Man sollte vorsichtig damit sein, weil protected so eine Halbe-Halbe Sache ist - einerseits will man den Member verbergen, andererseits können Kinder einfach darauf zugreifen... ich sehe protected zu gefühlten 95% nur bei Funktionen.

Wie ich gerade im anderen Thread so schön gehört habe: access-level so restriktiv wie möglich halten...

[merkantilist]

Sone schrieb:

ich sehe protected zu gefühlten 95% nur bei Funktionen.

Ich sehe protected gar nie (ausser einmal bei einem Konstruktor). Kannst du mir einer deiner Funktionen raussuchen?

@dot: Danke, jetzt bin ich etwas erleichtert.

[Sone]

merkantilist schrieb:

Sone schrieb:

ich sehe protected zu gefühlten 95% nur bei Funktionen.

Ich sehe protected gar nie (ausser einmal bei einem Konstruktor). Kannst du mir einer deiner Funktionen raussuchen?

http://www.cplusplus.com/reference/iostream/streambuf/
Scroll mal runter, da sind viele....

[Eisflamme]

Also ein häufiger Anwendungsfall ist eben, wenn man das Verhalten einer Klasse in einer abgeleiteten Klasse überschreiben möchte, wobei man da an Stellschrauben dreht, die nicht zum öffentlichen Interface der Klasse gehören. Und das dann gleichzeitig, wenn man die Basisfunktionalität noch ausnutzen möchte.

Bei einer UI-Klasse mit paint() z.B. kann man in paint() definieren, dass noch etwas mehr gezeichnet werden soll. Am Anfang der Methode ruft man Base::paint() auf, um erstmal das Basisgezeichne zu machen (z.B. ein Rahmen oder so). Und danach fügt man die weiteren Zeichenoperationen an. Ich bin nicht sicher, ob das nach strenger Definition zutrifft, aber das wäre so etwas wie das Decorator-Pattern.

[pumuckl]

Ich hab mal mein aktuelles Projekt durchsucht und genau 3mal das Wort protected gefunden: zwei nach folgendem Schema:

struct ServerEvent;

struct ServerEventHandlerInterface
{
  virtual void processEvent(ServerEvent) const = 0;
protected: //no polymorphic delete
  ~ServerEventHandlerInterface() {}
};

Und eines für die Konstruktoren und clone-Methode einer rein technischen Basisklasse - beides dient zur Kontrolle, dass die Klasse jeweils wirklich nur auf die beabsichtigte Art als Basisklasse verwendet wird.

[Sone]

Korrigiere: 99,9 %

Jetzt wo ich mich besinne, sehe ich so gut wie nie eine Variable mit protected scope.

[asc]

Auch wenn ich protected eher sparsam verwende, setze ich es sicherlich häufiger ein als Sones 0,1%.

Sei es bei Methoden die eine gemeinsame Vor- und Nachbehandlung über alle Instanzen haben, oder bei den Verhalten schlicht Instanzabhängig ist, aber nicht zwangsweise public nötig ist (Grundsätzlich mache ich immer alles erst private, dann protected und erst wenn wirklich nötig public - nach der Regel kommt protected daher bei mir nicht ganz so selten vor).

Ein durchaus vorkommender Fall (zur Vereinfachung alles zusammengeschrieben):

class A
{
  protected:
    virtual void TuEtwasIntern() = 0;
  public:
    void TuEtwas() {
        // <-- Einheitliche Vorbehandlung
        TuEtwasIntern();
        // <-- Einheitliche Nachbehandlung
    }
}

[Th69]

Hallo asc,

aber protected braucht es nur zu sein, wenn die überschreibende Klasse diese explizit aufrufen will (überschreiben geht auch bei "private virtual"), s.a Non-Virtual Interface (Guideline #3).

Ich selber habe aber auch fast immer jede virtuelle Funktion als protected deklariert.

[pumuckl]

asc schrieb:

Auch wenn ich protected eher sparsam verwende, setze ich es sicherlich häufiger ein als Sones 0,1%.

Sones 0.1% bezog sich ausschließlich auf Membervariablen, nicht auf Methoden.
Wobei ich für Membervariablen garkeinen Sinn für protected sehe.

[asc]

Th69 schrieb:

aber protected braucht es nur zu sein, wenn die überschreibende Klasse diese explizit aufrufen will...

Danke, das war mir tatsächlich neu. Würde protected bei mir tatsächlich massiv reduzieren, aber auch nicht ganz eliminieren.