virtual / override ??

[Hansa]

Hi,

die Problemstellung ist folgende : ich brauche in abgeleiteten Forms eine Prozedur. Es steht aber beim Vorfahr noch nicht genau fest, was die im Endeffekt machen soll.

Ich habe diese Prozedur nun im Vorfahr deklariert. Und zwar als "virtual". Die Nachkommen sind als "override" deklariert.

Die 1. Frage ist nun, ob das so überhaupt richtig ist.

Die nächste ist dann, warum Delphi die Ursprungsprozedur rausschmeißt, sofern sie "leer" ist. Die abgeleitete Prozedur erzeugt dann nämlich einen Compiler-Fehler (Identifier blabla...).

Die Prozedur muß nämlich zunächst leer sein, da sie erst von den abgeleiteten Forms bestückt wird. Sie dient also quasi vorerst nur als Platzhalter. So ähnlich halt wie die Custom-Geschichten in der Delphi VCL.

[NicoDE]

definiere sie als (das was sie ist) abstract

Delphi-Quellcode:

procedure Foo; virtual; abstract;

Dann brauchst Du auch keine 'Dummy-Implementation' schreiben.

[Pseudemys Nelsoni]

Zitat:

Die 1. Frage ist nun, ob das so überhaupt richtig ist.

Ja.

Zitat:

Die nächste ist dann, warum Delphi die Ursprungsprozedur rausschmeißt, sofern sie "leer" ist. Die abgeleitete Prozedur erzeugt dann nämlich einen Compiler-Fehler (Identifier blabla...).

weil du sie überschrieben hast....kannste doch mit inherited aufrufen(falls du das überhaupt vorhast, wenn nicht dann ignorier das hier).


edit:

abstract kannt ich noch gar nicht ma anschauen^^

[Hansa]

[OT]Echt hammerhart. :shock: Da schreibt man mal so eine nicht ganz einfache Frage, in der Erwartung, daß wenn überhaupt, irgendwann nächste Woche eine Reaktion kommt und dann kommen sogar zwei. 8) [ENDE OT]

1. Das "abstract" ist mir unbekannt, wozu ist das da ? Muß mich wohl oder übel mit diesen Dingern intensiver beshäftigen. Wo steht nun mehr, als in den Delphi Handbüchern ? Dann noch die Kombinationen (und es gibt ja noch mehr: "reintroduce" usw.) Mir ist schon klar, daß das alles selten gebraucht wird, aber ich komme mit meinem umfangreichen Projekt nicht drumrum den kompletten Delphi-Sprachumfang zu kennen, egal ob DBs, Komponentenentwicklung, Zeiger usw.

2. Pseudo: wieso überschreibe ich was ? Es geht um die Ursprungsklasse. Wenn eine abgeleitete existiert, so kann die Ursprungsprozedur nicht einfach gelöscht werden. 8) Es sei denn sie wird nicht benutzt. Die Ursprungsprozedur wird nicht gelöscht, sofern nur ein Kommentar drin steht. Falls nicht, so ist sie weg und die abgeleitete Prozedur erzeugt einen Fehler, eben weil die Ursprungs-Prozedur eben fehlt. Nun steht aber in der abgeleiteten eine ShowMessage drin, sie dürfte insofern nicht gelöscht werden.

[nailor]

auf jeden fall abstract. und damit natürlich auch virtual ;). dann in den abgeleiteten klassen mit override überschreiben. auf überschriebene methoden kann man mit inherited zugreifen. bei konstruktoren sollte man das auch tunlichst zu allererst machen, bei konstruktoren analog zu allerletzt.

[nailor]

abstract macht genau das was du suchst. es steht nur im interface und meldet delphi, dass da was sein muss. eine implementation braucht man nicht. allerdings kann man die klasse nicht erzeugen, solange noch ein "abstract" darin ist. man muss erst davon ableiten und das abstract mit einem override "füllen". das abstract ist sowas wie eine forward-deklaration, die aber erst bei den erben implementiert werden muss. das abstract automatisch auch virtual sein muss, ist klar.

...das war eine von den "basiswissen"-sachen, die wir im zweiten jahr delphi gelernt haben in der schule (wo wir sonst echt nicht viel machen)

[Leuselator]

NicoDe's Version in Ausführlich:

Abstrakt bedeutet dem Compiler, dass dies nur ein "Platzhalter" für eine Methode ist, die in einem Nachfahre des aktuellen Objektes (mit "override") implementiert wird und er nicht schon in diesem Objekt nach einer Implementation zu suchen braucht.

Implementiert ein Nachfahre diese Methode dann doch nicht, gibt der Compiler eine Warnung: "Achtung: Objekt BlaFasel wird mit abstrakten Methoden instantiiert" aus um so anzuzeigen, dass wir da wohl was vergessen haben.

Prinzip-Beispiel:

Delphi-Quellcode:

TAnzeige = class TWinControl
public
  procedure Beschriften(Value:String); virtual; abstract;
end;

TLabelAnzeige = class(TAnzeige)
private
  FLabel : TLabel
public
  constructor Create(AOwner:TControl); override;
  destructor Destroy; override;
  procedure Beschriften(Value:String); override;
end;

TEditAnzeige = class(TAnzeige)
private
  FEdit : TEdit
public
  constructor Create(AOwner:TControl); override;
  destructor Destroy; override;
  procedure Beschriften(Value:String); override;
end;

implementation

constructor TLabelAnzeige.Create(AOwner:TComponent);
begin
  inherited;
  FLabel := TLabel.Create(self);
end;

procedure TLabelAnzeige.Beschriften(Value:String);
begin
  FLabel.Caption := Value;
end;

destructor TLabelAnzeige.Destroy(Value:String);
begin
  FLabel.Free;
  inherited;
end;

constructor TEditAnzeige.Create(AOwner:TComponent);
begin
  inherited Create(AOwner);
  FEdit := TEdit.Create(self);
end;

procedure TEditAnzeige.Beschriften(Value:String);
begin
  FEdit.Text := Value;
end;

destructor TEditAnzeige.Destroy(Value:String);
begin
  FEdit.Free;
  inherited;
end;

Gruß

[Nothine]

@nailor: abstract muss nicht automatisch virtual sein, es kann auch dynamic sein :roll:

[nailor]

stimmt schon. das wichtige ist (wie ich auch sagte) die platzhalter-eigenschaft der abstrakten methode.

@leuselator: *iii* alles in eine unit gequetscht!

[Leuselator]

da war wohl einer schneller...

Egal - zu reintroduce:

Wenn man eine Vorfahrmethode ohne Angabe von "override" überschreibt, dann "verdeckt" man somit die Vorfahrmethode (und kann sie auch nicht mit "inherited" aufrufen). Der Compiler warnt uns in diesem Fall. Wenn wir uns aber der Konsequenz des Verdeckens bewusst sind (und vielleicht auch genau das erreichen wollen), dann schreiben wir hinter die MethodenDeklaration "reintroduce" - und schon geht der Compiler davon aus, das ein Crack an der Tastatur hockt :-)