3. Noch mal Vererbung ?

Noch mal Vererbung ?

  • ?

    Hi noch mal eine Vererbungsfrage !

    Habe folgendes testprogramm zum ausprobieren geschrieben, wird der private Bereich nicht mit vererbt ? weil mir der Konstruktor von kreis sagt das er nicht auf x bzw. y zugreifen kann ?

    # include <iostream.h>

class punkt
{
private:

	int x;
	int y;

public:
	punkt(int xx, int yy){x=xx,y=yy;}
	void print();
};

void punkt::print()
{
	cout << "Punkt: " <<"(" << x << "," << y << ")" << "\n";
}

class kreis : public  punkt
{
private:
	int r;
public:
	kreis(int xx,int yy, int rr){x=xx,y=yy,r=rr;}
	void print();
};

void kreis::print()
{
	cout << "Kreis: " <<"(" << x << "," << y << ")" << "R:" << r <<"\n";
}

int main()
{
kreis k1(100,100,10);

punkt p3(500,500);
punkt p4(600, 600);

p3.print();
p4.print();
k1.print();

return 0;
}
    0
  • H

    Hallo,
    die privaten-Teile einer Klasse sind nur für Member und Friends zugänglich. Abgeleitete Klassen haben lediglich zugriff auf protected und public Bereiche der Basisklasse.

    0
  • ?

    Danke - ich dachte wohl das diese mitvererbt werden - gibt es da nicht ein befehl oder sowas für ?

    Gruß Soulfly

    0
  • G

    einfahc die variablen protectet machen.

    Also:

    class MyClass
{
protected:
int x;
int y;
};
    0
  • ?

    THX

    Genauso wollte ich es habe !

    gruß Soulfly

    0
  • H

    einfahc die variablen protectet machen.

    Ne. Bitte nicht.

    0
  • C

    einfahc die variablen protectet machen.

    nee, einfach die Klassen nicht von einander ableiten, is nämlich keine Beziehung zum Vererben zwischen nem Punkt und nem Kreis

    0
  • E

    soul:
    vererbung ist eine "ist-eine-beziehung".
    in deinem fall waere der kreis ja ein punkt...

    0
  • A

    Nicht wenn man dem Punkt einen Durchmesser geben kann (ya, ich weiß, ein Punkt hat kein Durchmesser). 😉 Aber man kann es als "Implementiert-mit" machen:

    class Kreis : private Punkt
{
   private:
       int durchmesser;
};

    Und den Punkt für die Platzierungangabe im Koordinaten-System nutzen.

    0
  • H

    Hallo,
    Vererbung macht scheinbar manchmal blind. Ich habe nun wirklich keine Ahnung von Mathe, aber in der Schule hatten Kreise immer einen Mittelpunkt und einen Radius.
    Also:
    Ein Kreis *hat ein* Mittelpunkt. Und ein Kreis *hat einen* Radius.
    Das passt viel Besser als "ist-ein" oder "ist-implementiert-in-Form-von".
    Eine simple Komposition ist imo hier das feinste:

    class Punkt {...};
class Kreis 
{
private:
    Punkt center_;
    int radius_;
...
};

    Aber mir ging es eigentlich überhaupt nicht um die unglückliche Vererbungsbeziehung (war ja wahrscheinlich nur ein Beispiel) sondern um die *hässliche* Angewohnheit Membervariablen protected zu machen.

    0
  • C

    HumeSikkins schrieb:

    Aber mir ging es eigentlich überhaupt nicht um die unglückliche Vererbungsbeziehung (war ja wahrscheinlich nur ein Beispiel) sondern um die *hässliche* Angewohnheit Membervariablen protected zu machen.

    Jetzt musst du dann aber bitte auch erklären, was daran hässlich sein soll.

    0
  • S

    C14 schrieb:

    Jetzt musst du dann aber bitte auch erklären, was daran hässlich sein soll.

    weil es fast wie public ist: jeder kann daran rumpfuschen!

    die abgeleitete klasse kann einer von deinen protected variablen einen ungueltigen wert zuweisen und das programm liefert ploetzlich undefiniertes verhalten und keiner weiss wieso.

    protected ist fast so schlimm wie public, denn jede abgeleitete klasse kann mit deinen implementations spezifischen werten mist bauen. wenn sie getter und setter nutzen wuerde, waere das nicht moeglich.

    ich habe noch nie eine situation erlebt wo member variablen protected sein haetten sollen/muessen/koennen.

    0
  • G

    Meiner Meinung nach müsste das mit privater Vererbung klappen.

    0
  • H

    weil es fast wie public ist: jeder kann daran rumpfuschen

    protected ist fast so schlimm wie public

    Streiche fast ersatzlos und ich bin deiner Meinung.
    Eine protected Variable ist genau wie eine public Variable eine die nicht allein in das Hoheitsgebiet der Klasse fällt in der sie deklariert wurde.
    Alle Nachteile die für public Variablen gelten, gelten auch für protected Variablen.

    Es kann insbesondere beliebig viel Code von einer solchen Variable abhängen. Demzufolge kann beliebig viel Code bei einer Änderung kaputt gehen.

    ich habe noch nie eine situation erlebt wo member variablen protected sein haetten sollen/muessen/koennen.

    Richtig. Es gibt vorallem einen fundamentalen Unterschied:
    Beginnt man mit protected-Variablen und hat man einmal eine Klasse mit einer protected-Variable öffentlich gemacht, so kann man die protected-Variable *niemals* mehr ändern/entfernen ohne dabei potentiell fremden Code kaputt zumachen.

    Startet man aber mit einer öffentlichen Schnittstelle und stellt dann *viel später* fest, dass der indirekte Zugriff einen messbaren negativen Einfluss auf die Performance hat, so kann man die Zugriffsmethode nachträglich inline machen *ohne* das dabei fremder Code kaputt gehen kann.

    Mit protected Membern kann man also nur Leben, wenn man genauso auch mit public Membern leben kann.

    0
Anmelden zum Antworten