Meine Probleme mit Delphi-OOP ...

[himitsu]

overload = überladen
override = überschreiben

überladen = gleichzeitig mehrere Methoden mit gleichem Namen, bzw. alte aus Vorfahren Methode nicht verdecken. (absichtliches Verdecken wird mit reintroduce angeben)
überschreiben = virtuelle (virtual) oder dynamische (dynamic) Methode des Vorfahren überschreiben, also den Eintrag in der VMT ändern.


scrollen ... dafür ibt es Listen und Tastenkürzel, im schnell hin- und herzuspringen, wie z.B. Strg+Shift+Hoch oder +Runter

[MGC]

@himitsu: Ist dies eine allgemeingültige Definition und somit auch auf Delphi übertragbar? Ich wäre jetzt sehr dankbar, wenn Du mir erklären würdest, warum der Delphi-Compiler dies anscheinend anders sieht.

Abgesehen davon, wenn man mit reintroduce absichtlich eine Methode überdeckt, aber mit inherited dafür sorgt, dass die originale Methode dennoch ausgeführt wird, was soll daran so schlimm sein?
Ich verstehe eben nach wie vor nicht, wen es gewisse Regeln zu geben scheint, an die man sich einfach zu halten hat, warum es so schwer ist genau dies zu tun?

Ich möchte hier niemandem mit dem Finger drohen, wie es anscheinend rüberkommt. Denke aber immer daran, dass die ursprüngliche Definition der OOP zugunsten der Praktikabilität nicht vollkommen umgesetzt wurde (z.B. bei der Polymorphie).

Zitat:

Aus Wikipedia - Prinzipien Objektorientiertes Design (Liskovsches Substitutionsprinzip)
[...]Damit ist garantiert, dass Operationen vom Typ Superklasse, die auf ein Objekt des Typs Subklasse angewendet werden, auch korrekt ausgeführt werden. Dann lässt sich stets bedenkenlos ein Objekt vom Typ Superklasse durch ein Objekt vom Typ Subklasse ersetzen. Objektorientierte Programmiersprachen können eine Verletzung dieses Prinzips, das aufgrund der mit der Vererbung verbundenen Polymorphie auftreten kann, nicht von vornherein ausschließen. Häufig ist eine Verletzung des Prinzips nicht auf den ersten Blick offensichtlich.[...]

[himitsu]

Wegen den anderen fragen schau ich dann nochmal nach.

Aber reintroduce schaltet eigentlich nur die Compilerwarnung ab.

Wenn man eine Methode verdeckt, dann wird man vom Compiler gewarnt. Und hat man absichtlich verdeckt, dann kann man das über reintroduce auch so markieren und weg ist die Warnung.



Ob die verdeckte Methode intern dann via inherited oder sonstwie aufberufen wird, ist dabei unwichtig.
Das Verdecken bezieht sich nur auf die äußere Schnittstelle, also das Interface (Deklaration) und nicht die Implementation (Code).

[MGC]

@himitsu: Besten Dank, wird notiert. Vielleicht nehme ich auch viel zu viel einfach als gegeben hin.

[himitsu]

Zitat:

Ist dies eine allgemeingültige Definition und somit auch auf Delphi übertragbar?

Ob es allgemeingültig ist, weiß ich nicht, was ich würde mal blind "ja" denken.
Overload, Override ist zumindestens in Delphi/Pascal so umgesetzt.


Virtual und Override ist so:

Gibt man in einer Klasse virtual für eine Methode an, dann wird dafür, in/ab diesem Typ ein Eintrag in der VMT angelegt.
Wenn man jetzt eine Variable mit diesem Typ anlegt, dann kennt dieser Typ seine VMT.

Nun könnte man in einer Variable auch einen Nachfahren dieses Typen abspeichern.

Ist in dem abgeleiteten Typen diese Methode überschrieben, dann wird das in der VMT vermerkt.
Damit kennt dann auch der Vorfahr den Zeiger zur neuen Methode, da es ja in der VMT drinsteht.

Wurde diese Methode aber nur verdeckt (egal ob sie Virtual ist oder nicht), dann kennt der Vorfahr diesen Zeiger nicht und kann damit immer nur seine Methode aufrufen.

Aus diesem Grund sind alle VCL-Komponenten von TComponent abgeleitet, wo vorallem der Constructor virtuell ist,
sowie bei allen Klassen der Destructor virtual ist.

Auf diese Weise kann die VCL den richtigen Constructor laden und auch immer der richtige Destructor ausgeführt werden, da der Vorfahre diese kennt.

[MGC]

Zitat von himitsu:

Aus diesem Grund sind alle VCL-Komponenten von TComponent abgeleitet, wo vorallem der Constructor virtuell ist,
sowie bei allen Klassen der Destructor virtual ist.

Auf diese Weise kann die VCL den richtigen Constructor laden und auch immer der richtige Destructor ausgeführt werden, da der Vorfahre diese kennt.

Stimmt, die Sache mit dem Eintrag in die VMT hatte ich vergessen. Daher muss ich ab diesem Punkt tatsächlich trebor90 rechtgeben. Die Handhabe von Delphi in bezug auf überladene Methoden, wenn die Hauptmethode im Basistyp als virtuell deklariert wurde, steht tatsächlich im Widerspruch zur OOP.

Verdecke ich ich einfach die original Methode, dann wird hier kein Eintrag in der VMT hinterlegt und ich muss sehr genau wissen ab welcher Stufe der Vererbung die entsprechende Methode mit reintroduce verdeckt wurde.

Wie verhält es sich nun bei Weiterveerbung? Sidn die Subklassen dann in der VMT ab hier auf die verdeckte Methode des Vorfahr bezogen oder wieder aufgrund der VMT auf die Superklasse?

Ich habe tatsächlich sehr viel dazugelernt. Bisher hätte ich nicht erwartet, dass Delphi sich im Gegensatz zu anderen OOP-Sprachen doch so entscheidende Abweichungen erlaubt.

Darüber hinaus habe ich auch mal Experimente mit der Mainform angestellt, weil ich jetzt wirklich wissen wollte, ob die globale Variable für das MainForm überflüssig ist.
Und uups, in der Tat es ist so, wenn ich das Fensterhandle des MainForms auslesen will, muss ich Application.Handle verwenden und tatsächlich nicht MainForm.Handle.

Vielen Dank für diesen Augenöffner.

[himitsu]

Mit der neuen RTTI könnte man zwar theoretisch auf auf die VMT und virtuelle Methoden verzichten, da man ja die Funktionen alle suchen und über die RTTI aufrufen könnte. (solange man die neue RTTI nicht einschränkt/abschaltet)
Bzw. über Published-Methoden der alten RTTI ginge es auch schon.

Aber schneller ist es über die VMT, denn ein indizierter Zugriff und man hat die aktuelle Methode.

Nachteil über die RTTI: Man könnte Methoden nicht verdecken, da sie dann ja automatisch überschrieben würden, wenn man ausnahmslos das Aktuellste sucht.
Und Klassenmethoden über eine Objektinstanz aufgerufen wären vermutlich nicht überschreibbar.