Welchen Sinn hat das protected Privileg ??

[BasicMan01]

wenn du mit public vererbst, dann kannst du innerhalb deiner abgeleiteten Klasse auf public und protected - Elemente der Elternklasse zugreifen. Von außen allerdings nur auf public - Elemente.

Wie du vererbst (public, protected, private) hat aber weniger Einfluss darauf, wie du aus deiner abgleiteten Klasse auf deine Elternklasse zugreifen kannst.
Vielmehr wird hier der Sichtbarkeitsbereich auf deine abgeleitete Klasse festgelegt.

[l'abra d'or]

Bacid90210 schrieb:

Erbt meine abgeleitete Klasse denn nur public Variablen und Member Funktionen wenn ich sie public ableite.Und die privat Variablen die ich Vererben möchte muss ich als protected deklarieren damit meine Unterklassen zugriff darauf haben ich aber nicht möchte dass von außen darafu zugegriffen werden kann ...??

Glaub noch nicht ganz. Mit der Art der Ableitung hat das nix zu tun. Damit steuerst du, wie von Außen ein Objekt deiner abgeleiteten Klasse ansprechbar ist. public-Vererbung bedeutet hier, dass alle public-Methoden der Basisklasse von außen errecihbar sind. protected-Vererbung würde den public-Bereich der Basisklasse nach protected schieben, das heißt nur von Derived abgeleitete Klassen können auf den public-Bereich von Base zugreifen. private-Vererbung schottet die Basis komplett ab.
friend weicht aber das ganze Konzept wieder auf.
Das protected in der Klasse ist jetzt speziell für den Vererbungsfall gedacht, um einen Bereich zu schaffen, der dem ordinären Nutzer verschlossen bleibt, der aber geschützten Zugriff auf spezielle Methoden(/Variablen) bietet, mit der die Basis kontrolliert werden kann.

[Gast]

Bacid90210 schrieb:

Erbt meine abgeleitete Klasse denn nur public Variablen und Member Funktionen wenn ich sie public ableite.Und die privat Variablen die ich Vererben möchte muss ich als protected deklarieren damit meine Unterklassen zugriff darauf haben ich aber nicht möchte dass von außen darafu zugegriffen werden kann ...??
Habe ich das jetz richtig verstanden ...

Vererbt wird alles (da in einem Derived-Objekt immer ein Base-Objekt steckt).

Die Zugriffsmodifizierer spezifizieren lediglich,
ob die abgeleitete Klasse Zugriff darauf hat oder nicht.

private: abgeleitete Klasse darf nicht darauf zugreifen.

protected: abgeleitete Klasse darf darauf zugreifen.

public: abgeleitete Klasse und jeder Andere (also auch von außen) darf darauf zugreifen.

[ EDIT ] ... falsch gelesen, es geht ja um die Art der Ableitung ...

Habe dir mal ein Beispiel dazu gemacht.

class Base
{
    private:
        int i_private;

    protected:
        int i_protected;

    public:
        int i_public;
};

class PrivateVererbung : private Base
{
    /*
        In dieser Klasse gilt:
            i_protected und i_public werden private.
    */
};

class ProtectedVererbung : protected Base
{
    /*
        In dieser Klasse gilt:
            i_protected bleibt protected.
            i_public wird protected.
    */
};

class PublicVererbung : public Base
{
    /*
        An der Zugriffsspezifikation ändert sicht nichts:
            i_public bleibt public.
            i_protected bleibt protected. --> Man kann die Sichtbarkeit nie erweitern.
    */
};

class Test : public PrivateVererbung
{
    /*
        Diese Klasse hat nun also kein Zugriff auf i_protected und i_public,
        da sie ja in der Klasse "PrivateVererbung" private sind.
    */
};

[Bacid90210]

Es ist schon so spät und ich aknn eigentlich nicht mehr ..
Aber ich muss das jetzt verstehen ..
Vieleicht erkennt jemand meinen Denkfehler ..

So denke ich :

class Base
{
    private:
        int _priv;
    protected:
        int _prot;
};

class Derived : public Base // DIESE KLASSE ERBT ALSO ALLE MEMBER
{
private :
int _priv; //GEERBT
protected:
int _prot; //GEERBT

public:
        void foo ()
        {
             _prot = 5; // ok
             _priv = 5; // DANN MÜSSTE DAS DOCH AUCH OK SEIN ICH GREIFE DOCH
//INNERHALB DER ABGEL. KLASSE DARAUF ZU ..
        }
};

[l'abra d'or]

public:
        void foo ()
        {
             _prot = 5; // ok
             _priv = 5; // DANN MÜSSTE DAS DOCH AUCH OK SEIN ICH GREIFE DOCH
//INNERHALB DER ABGEL. KLASSE DARAUF ZU ..
        }
};

Nein, da dir Base EXPLIZIT verbietet darauf zuzugreifen - das ist eben das private! Auf private-Member haben nur Instanzen dieser Klasse selber und alle friends Zugriff.

[BasicMan01]

ich glaub deine Eltern hätten was dagegen, wenn du auf ihre privaten Finanzen zurückgreifst nur weil du von ihnen "abgeleitet" bist.

[ipsec]

Etwa gleicher Sachverhalt wie:

Base b;         // b hat alle Member von Base
b._priv = 5;    // Oh, wiso geht das nicht?

Die Member sind natürlich da, aber der Zugriff ist gesperrt.

[Bacid90210]

Ok ich glaube ich habs jetz , wenn ich als möchte dass meine geerbeten private Member von mir verändert werden dürfen , muss meine Oberklasse sie als protected deklarieren .
Wenn ich dann also erbe ohne protected Privilegien zu nutzen ...
Kann ich die Member Variablen ja nach dem Initialsieren über den Konstruktor nicht mehr bearbeiten.

[Athar]

Bacid90210 schrieb:

Wenn ich dann also erbe ohne protected Privilegien zu nutzen ...
Kann ich die Member Variablen ja nach dem Initialsieren über den Konstruktor nicht mehr bearbeiten.

Kommt darauf an. Du kannst in der abgeleiteten Klasse natürlich ebenso öffentliche Funktionen der Basisklasse aufrufen und so evtl. private Member verändern lassen. protected benötigt man nicht besonders oft, da die benötigte Funktionalität der Basisklasse idealerweise über das öffentliche Interface verfügbar ist und die privaten Member von diesen Funktionen angemessen verwaltet werden.

BasicMan01 schrieb:

ich glaub deine Eltern hätten was dagegen, wenn du auf ihre privaten Finanzen zurückgreifst nur weil du von ihnen "abgeleitet" bist.

Das Beispiel ist gar nicht so schlecht

[Bacid90210]

Ok ..
Klasse B welche von Klasse A erbt kann die private Member also nur mit Elemtfunktionen der Oberklasse A ändern .
Kennzeichne ich die Member der Oberklasse als protected , kann meine Unterklasse aber auch mit den eigenen Funktionen daran herum scharauben , von außen habe ich aber keinerlei Zugriff ...

So ..jetz ist es aber richtig formuliert

[asc]

Bacid90210 schrieb:

Klasse B welche von Klasse A erbt kann die private Member also nur mit Elemtfunktionen der Oberklasse A ändern .

Sofern diese Funktion auch wieder mindestens protected oder public ist.

Aber ansonsten geht deine Formulierung durch. Generell würde ich aber die Abhängigkeit auch in einer Vererbung möglichst gering halten (und überlege mir daher gut, bevor ich eine Variable oder Funktion protected oder public mache). Um so weniger Kopplungen existieren, um so eher kann man eine Klassenhirachie nachträglich ändern (und dann sind Elementfunktionen den Variablenzugriffen in der Regel vorzuziehen, da man Funktionen leichter ändern kann, ohne den Code groß umzuschreiben).

[TheBigW]

ehrlich gesagt fallen mir kaum Anwendungsfaelle ein, bei denen es keine Alternative zu protected gegeben haette, oder wo protected Zugriff mir irgendeinen Vorteil gebracht haette, ausser um "mal schnell" was zu prototypen.

[Nexus]

TheBigW schrieb:

ehrlich gesagt fallen mir kaum Anwendungsfaelle ein, bei denen es keine Alternative zu protected gegeben haette, oder wo protected Zugriff mir irgendeinen Vorteil gebracht haette, ausser um "mal schnell" was zu prototypen.

Protected-Variablen habe ich zwar fast nie, aber für Funktionen fallen mir schon ein paar Anwendungsfälle ein. Alternativen gibt es natürlich immer, aber die sind oft umständlicher, weniger elegant oder haben andere Nachteile.

Wenn eine Klasse den Memberzugriff auf abgeleitete Klassen beschränken will, was ist daran grundsätzlich falsch? Oder anders gefragt: Was würdest du in folgenden Situationen tun?

• Du hast eine überschriebene, nicht-öffentliche Methode (virtuell oder nicht) und willst die Basisklassenversion aufrufen. Zum Beispiel:

void Derived::Render()
{
    Base::Render()
    // Zeichne restliche Teile dieser Instanz
}

• Du willst eine Basisklasse etwas fragen. Ich hatte kürzlich einen Fall im Zusammenhang mit mutable und verzögerten Berechnungen:

bool Base::NeedsXYUpdate();

void Derived::DoSomething()
{
    if (NeedsXYUpdate())
        // ...
}

• Du willst, dass man eine nicht-polymorphe Klasse nicht direkt instanziieren kann, sondern nur über abgeleitete Klassen, und deklarierst die Konstruktoren der Basisklasse protected .
• ...

[TheBigW]

hast recht: ich hab mehr in Richtung Variablen - Zugriff gedacht. Fuer funktionen mag es schon Anwednugsfaelle geben (wie von Dir gezeigt).

Aber oft ist dann die Frage berechtigt warum die Funktion nicht gleich public sein darf (zumal jeder sowieso nach Ableitung public zugriff haben kann) - kommt natuerlich auf den Anwendungsfall an....

[l'abra d'or]

TheBigW schrieb:

Aber oft ist dann die Frage berechtigt warum die Funktion nicht gleich public sein darf (zumal jeder sowieso nach Ableitung public zugriff haben kann) - kommt natuerlich auf den Anwendungsfall an....

Weil es nicht nur darum geht, Zugriff auf irgendwelche Elemente zu geben.
Ein kurzes Beispiel aus Qt4:
http://doc.qt.nokia.com/4.6/qabstractitemmodel.html#protected-functions
createIndex macht als public keinen Sinn, genauso die ganzen "beginInsert***". Das kann sogar ziemlich in die Hose gehen, wenn jeder der ein Qt-Model verwendet diese Funktionen aufrufen kann Das sind reine Internals. Bei createIndex der void*-Parameter wird dafür verwendet, ein eigenes Objekt aus einer internen Datenstruktur zu übergeben. Die casts zurück zur Verwendung des Objekts (z.B. in data()) können ziemlich böse enden (appCrashEvent() :P) wenn irgend ein Doldi nen Schmarrn übergeben kann.

[TheBigW]

wie gesagt: kommt natuerlich auf den Anwendungsfall an....

ich hab nie behaupted, das protected keine berechtigung hat, nur das protected unter umstaenden genauso gefaehrlich ist wie public.

mit public UND protected werden funktionen zum interface meiner klasse und jeder kann damit tun und lassen was er will.

[Nexus]

TheBigW schrieb:

mit public UND protected werden funktionen zum interface meiner klasse und jeder kann damit tun und lassen was er will.

Nicht ganz. Für Zugriffe auf public -Methoden muss man gar nichts tun, während protected seinen Tribut (Vererbung, eine sehr starke Bindung) fordert.

Und denk dran: Du entwickelst eine Klasse für den Anwender und nicht gegen ihn. Wenn dieser meint, er müsse protected -Member in abgeleiteten Klassen öffentlich machen, dann lass ihn lustig sein. Am Zugriff auf private -Member kannst du einen bösartigen Programmierer genauso wenig hindern.

[TheBigW]

Ich will hier nicht bestreiten, dass protected unter Umstaenden durchaus Sinn macht.
Ausgangspunkt war eher, das man IMO zweimal nachdenken sollte, ob man es nicht gleich public anbieten sollte oder ganz versteckt (private). Wenn man zu dem schluss kommt das protected die beste Loesung ist, warum nicht.

Ich schreib ja auch keinen protected freien code :).

..er müsse protected-Member in abgeleiteten Klassen öffentlich machen, dann lass ihn lustig sein. Am Zugriff auf private-Member kannst du einen bösartigen Programmierer genauso wenig hindern.

naja, Bevormundung liegt mir fern, fuer mich geht es eher um die Wahrung meiner Abstraktion. Fuer mich heisst "Interface" eher: "hier ist das fuer das ich garantiere das es funktioniert", wers ignoriert hat pech :).

Eigentlich koennen wir hier aufhoeren: wir sind uns einig, das protected:

-eher seletenere Anwendung findet als public und private
-fuer datenmember verboten gehoert ( bis auf Ausnahmen )

(bei bedarf die liste bitte anpassen - mag nicht mehr streiten )

[Nexus]

Da kann ich dir nur zustimmen!