virtual / override ??

[Hansa]

Wie gesagt, die Prozeduren bleiben bei mir nicht komplett leer, deshalb brauche ich das abstract nicht.

Allerdings habe ich nun noch folgendes bemerkt : dekllariere ich eine Methode als virtual, so wird die abgeleitete Methode nicht ausgeführt (die ebenfalls als virtual deklariert ist). Deklariere ich die abgeleitete dagegen als "override", so wird sie ausgeführt.

Hierüber müßte ich schon Klarheit haben.

[Leuselator]

Lies bitte nochmal meinen Post Hansa - dort ging ich auf alle Deine Fragen ein.
Noch ein Beispiel für Override (Konstruktoren etc. weggelassen):

Delphi-Quellcode:

TMensch = Class(TObject)
  FGroesse    : Integer;
  FGeburtstag : TDateTime;
  FAugenfarbe : TColor;
  FVorname    : String;
  FName       : String;
public
  procedure Assign(Value: TMensch); virtual; // nicht abstrakt, da echte Funktionalität
                                             // darin steckt
  property Groesse    : Integer   read FGroesse    write FGroesse;
  property Geburtstag : TDateTime read FGeburtstag write FGeburtstag;
  property Augenfarbe : TColor    read FAugenfarbe write FAugenfarbe;
  property Vorname    : String    read FVorname    write FVorname;
  property Name       : String    read FName       write FName;
end;

TFrau = class(TMensch)
FAnzahlSchuhe : LongInt; // :-)
FGeburtsName : String;
public
  procedure Assign(Value: TMensch); override; // damit wir die in TMensch erledigte 
                                              // Arbeit hier wiederverwenden können
  property AnzahlSchuhe : LongInt read FAnzahlSchuhe write FAnzahlSchuhe;
  property GeburtsName  : String  read FGeburtsName  write FGeburtsName;
end;

TMann = class(TMensch)
FAlimenteZahler : Boolean;
public
  procedure Assign(Value: TMensch); reintroduce; // kein "override" (!), löscht bzw. verdeckt
                                                 // die ererbte Methode. Um CompilerWarnung 
                                                 // zu unterdrücken, Angabe von "reintroduce"
  property AlimenteZahler:Boolean read FAlimenteZahler write FAlimenteZahler;
end;

implementation

procedure TMensch.Assign(Value:TMensch);
begin
  FGroesse    := Value.Groesse;
  FGeburtstag := Value.Geburtstag;
  FAugenfarbe := Value.Augenfarbe;
  FVorname    := Value.Vorname;
  FName       := Value.Name;
end;

procedure TFrau.Assign(Value: TMensch);
begin
  inherited Assign(Value); // Groesse etc. wird abgelegt
                           // geringer Aufwand hier, da Vorfahrklasse die Arbeit erledigt
  if (Value is TFrau) then begin
    FAnzahlSchuhe := TFrau(Value).AnzahlSchuhe;
  end else raise Exception.Create('Dieser Mensch ist keine Frau!');
end;

procedure TMann.Assign(Value: TMensch);
begin
  // wir können die ererbte Methode TMensch.Assign nicht aufrufen, 
  // da die TMann.Assign-Methode diese verdeckt! Also müssen wir uns
  // hier erneut um den Kram kümmern:
  FGroesse    := Value.Groesse;
  FGeburtstag := Value.Geburtstag;
  FAugenfarbe := Value.Augenfarbe;
  FVorname    := Value.Vorname;
  FName       := Value.Name;
  if (Value is TMann) then begin
    FAlimenteZahler := TMann(Value).AlimenteZahler;
  end else raise Exception.Create('Dieser Mensch ist kein Mann!');
end;

Gruß

[Leuselator]

@nailor: Du liegst leider falsch -das weglassen von override verhindert eben den ererbten Aufruf der Vorfahrmethode - sie wird also verdeckt - nur wenn override angegeben wird, hat man in dem abgeleiteten Objekt über "inherited" (engl. für "ererbt") noch die Zugriffsmöglichkeit auf die Methode des Vorfahrobjektes.
Gruß

[Hansa]

Nun mal schön langsam. gaaaanz langsam. 8) Ich deklariere eine Methode also als "virtual". Insofern will ich sie vererben. Im Falle von "override" scheint es so zu sein, daß sie ersatzlos gestrichen wird und durch einen neuen Inhalt ersetzt wird.

Was nun, wenn ich in der Basisklasse schreibe i := 1; und dann noch ein paar Initialisierungen vornehme. In einer abgeleiteten Klasse soll alles bleiben, wie es ist, nur i := 2; soll gemacht werden. In diesem Fall nützt es wenig, alles andere ersatzlos zu streichen.

Was ist dann zu tun ?

[nailor]

Zitat:

Zitat von Leuselator

@nailor: Du liegst leider falsch -das weglassen von override verhindert eben den ererbten Aufruf der Vorfahrmethode - sie wird also verdeckt - nur wenn override angegeben wird, hat man in dem abgeleiteten Objekt über "inherited" (engl. für "ererbt") noch die Zugriffsmöglichkeit auf die Methode des Vorfahrobjektes.
Gruß

wenn du dir mal meinen post anschaust, wirst du feststellen, das sich die erste hälfte und die zweite irgendwie wiedersprechen. ich weiß auch nicht, wie ich dazú kam, es zu posten, aber die erste hälfte ist müll. bzw. mit reintruduce statt override eingesetzt würde sie zwar noch sinn machen, aber naja, der post war nicht das gelbe vom ei...

[Chewie]

Zitat:

Zitat von Hansa

Nun mal schön langsam. gaaaanz langsam. 8) Ich deklariere eine Methode also als "virtual". Insofern will ich sie vererben. Im Falle von "override" scheint es so zu sein, daß sie ersatzlos gestrichen wird und durch einen neuen Inhalt ersetzt wird.

Wenn du eine virtuelle Methode als "override" deklarierst, ersetzt diese bei der aktuellen Klasse die Methode mit dem Namen, das ist richtig. Aber: über "inherited" hast du noch die Möglichkeit, die Methode der Vorgängerklasse aufzurufen. Die Möglichkeit hast du bei "reintroduce" bzw. wenn du gar nichts angibst nicht.

Zitat:

Zitat von Hansa

Was nun, wenn ich in der Basisklasse schreibe i := 1; und dann noch ein paar Initialisierungen vornehme. In einer abgeleiteten Klasse soll alles bleiben, wie es ist, nur i := 2; soll gemacht werden. In diesem Fall nützt es wenig, alles andere ersatzlos zu streichen.

Was ist dann zu tun ?

Ich nehm mal an, i sei ein Objektfeld oder eine globale Variable: Dann rufst du zuerst die Funktionen der übergeordneten Klassen auf (per inherited). Hier wird alles initialisiert und i auf 1 gesetzt. Nun setzt du noch i auf 2, und fertig.

[Luckie]

Eventuell auch mal einen Blick in das entsprechende Tutorial von mir werfen, obwohl so detailiert bin ich darauf nicht eingegangen. ;)

[Hansa]

es geht weiter :

reintroduce fast abgehakt, sofern das hier so stimmt:

ich erweitere Leusels Bsp. um ein Adoptivkind (Kanzler sei Dank 8) ), von dem das Geburtsdatum nicht genau feststeht. Sagen wir, es ist ein Mädchen, also vom Typ TFrau. In diesem Fall ist das Geburtsdatum irrelevant. TFrauAdoptiv soll nur das Geburtsjahr beinhalten. Ich steige also mit "reintroduce" neu in die Vererbungskette ein. Also TMensch -> TFrau -> TFrauAdoptiv als "reintroduce", was dann allerdings bedeutet, daß alle bereits in TMensch und danach deklarierten Eigenschaften neu definiert (zumindest initialisiert) werden müssen :?:

dynamic abgehakt, wegen Überflüssigkeit. :mrgreen:

overload nicht abgehakt

Ist zwar soweit klar, aber ich habe mir das MessageDlg mal näher angesehen. Das ist auch "overload", d.h. die Parameterliste wird flexibel. Nun stellt sich für mich folgende Frage :

Mich hat immer schon gewundert, daß "writeln" egal war, ob ein integer, ein string oder sonstwas angezeigt werden sollte. Geht das Overload in diese Richtung ?


noch was ?

[nailor]

overload: mehere namensgleiche funktionen, die allerdings unterschiedliche datentypen erwarten. z.b. kannst du display für strings und ints proggen und überladen. wird dann display mit einem string aufgerufen, machst du showmessage(string), bei einem int machst du showmessage(inttostr(int)). natürlich könntest du auch kommplett unterschiedliche sachen machen...

[Leuselator]

@Hansa verdeckt: siehe Zeilen 31ff und 58ff in meinem letzten Codebeispiel!