Zitat von
Hansa:
Echt schön.
Aber wo ist jetzt die Antwort ? Es fehlt die Begründung, undefinierte Sachen zu benutzen.
Ok, mal ein einfaches Beispiel, extra fuer dich:
Gegeben sei die Basisklasse TStream, welche diverse Methoden deklariert, wie bspw. Read, Write, Close ect.
Es gibt dann diverse Klassen, die von TStream abgeleitet sind, und die Methoden implementieren.
So, TStream kann jetzt diese Methoden
- als abstrakte Methode deklarieren
- mit virtual kennzeichnen und eine leere Methode ranpflanzen
Und nun folgendes Szenario:
Ich will Daten aus einem beliebigen Stream laden, und verwende dazu logisch meine Basisklasse.
Delphi-Quellcode:
procedure LoadData(Data: Stream);
begin
//blubbdibla
end;
Nun beobachten wir folgenden Fall:
Delphi-Quellcode:
var
MyData: TStream;
begin
MyData := TStream.Create;
LoadData(MyData);
end;
Kompiliert einwandfrei.
Wenn wir die erste Moeglichkeit nehmen, also abstrakte Methoden in TStream deklariert haben, dann kriegen wir eine
Exception um die Ohren geschmissen: Achtung, du baust da richtig Mist. Stimmt auch.
Wenn wir die zweite Moeglichkeit nehmen, also die virtuellen Methoden verwenden, dann kriegen wir keine Exceptions. Ok, das Programm laeuft vielleicht ohne Exceptions zu ende, aber funktionieren tuts trotzdem nicht - Es werden keine Daten geladen. Und da ich keine Fehlermeldung kriege, dann kann ich mich mal ein paar Stunden dransetzen, um den Fehler zu suchen um dann zu merken, dass abstract doch ned so bloed gewesen waere.
Damit sollte der Vorteil wohl offensichtlich sein, und wenn du jetzt nochmal den Thread durchliest, dann wirst du sehen, dass es darin genuegend dementsprechende Beispiele gegeben hat, die dir genau das selbe sagen.
greetz
Mike