Meine Probleme mit Delphi-OOP ...

[trebor90]

Obwohl ich sie eigentlich gar nicht verbergen moechte, sondern nur ueberladen?

[Jumpy]

Mal als Kommentar von der Seite, von jemandem, der OOP-mäßig ja noch in die Schule geht und da mit C# rumhampeln muss. Wenn du in einer abgeleiteten Klasse den Konstruktor überlädtst, dann überschreibst du ihn auch, mein ich. Sprich also du musst (zumindes in C# machen wir das so) in der abgeleiteten Klasse erst den Standardkontruktor überschreiben mit einem Standardkonstruktor und dann diesen überladen. Vllt. verwechsle ich das aber auch.

[MGC]

@Jumpy: Genauso ist es meines Erachtens auch korrekt. Da der Konstruktor in der Basislkase als virtuell deklariert wurde muss er in der abgeleiteten Klasse zuerst überschrieben werden (mit override) und wenn man dann weitere Konstruktoren mit variieender Parameterliste hinzufügen will, werden diese überladen (overload), so habe ich es auch gelernt. In wie weit man hinter den ersten Konstruktor allerding override und overload zugleich setzen kann, weiß ich jetzt aus dem Stehgreif auch nicht, werde ich aber mal testen.

@trebor90: In welche Variable (lokal oder global) Du ein Objekt erzeugst interresiert doch den Konstruktor nicht.
Aber ich verstehe jetzt auch nicht ganz, wieso Du solche Probleme mit Polymorphie hast, gehört doch auch zur OOP und nennt sich auch späte Bindung oder Overriding und ist somit nicht rein delphispezifisch.
Kann man z.B. auch auf Wikipedia nachlesen...

Zitat:

Polymorphie [Bearbeiten]

→ Hauptartikel: Polymorphie (Programmierung)

Unter bestimmten Voraussetzungen können Algorithmen, die auf den Schnittstellen eines bestimmten Objekttyps operieren, auch mit davon abgeleiteten Objekten zusammenarbeiten.

Geschieht dies so, dass durch Vererbung überschriebene Methoden an Stelle der Methoden des vererbenden Objektes ausgeführt werden, dann spricht man von Polymorphie. Polymorphie stellt damit eine Möglichkeit dar, einer durch ähnliche Objekte ausgeführten Aktion einen Namen zu geben, wobei jedes Objekt die Aktion in einer für das Objekt geeigneten Weise implementiert.

Diese Technik, das so genannte Overriding, implementiert aber keine universelle Polymorphie, sondern nur die sogenannte Ad-hoc-Polymorphie.

Viele Grüße.

[trebor90]

Also dass ich eine virtuelle Methode bzw. einen Konstruktor erst in einer abgeleiteten Klasse ueberschreiben muss, dass ich sie/ihn dann ueberladen kann - davon habe ich noch nie etwas gehoert.
Ich kann doch Sachen ueberladen, ohne sie vorher ueberschreiben zu muessen (egal ob virtuell oder nicht).

Und dass ich das mit den globalen und lokalen Variablen anspreche:
Hat nix mit dem Konstruktor zu tun. Nur, dass ich nicht mit grossen Fensterobjekten ueber globale Variablen agieren moechte, sondern, wie es sich gehoert, sie in lokale packe. Und darauf hinwies.
Die Frage waere naemlich, wie "ihr" das so macht? Lasst ihr den vorgefertigten Delphi-Quelltext so

Delphi-Quellcode:

var
  Form1: TForm1

implementation

...

oder aendert ihr das im Hauptprogramm in eine lokale Variable?

--

[mkinzler]

Zitat:

oder aendert ihr das im Hauptprogramm in eine lokale Variable?

Wenn dann in eine Eigesnchaft einer Klasse.

Zitat:

Also dass ich eine virtuelle Methode bzw. einen Konstruktor erst in einer abgeleiteten Klasse ueberschreiben muss, dass ich sie/ihn dann ueberladen kann - davon habe ich noch nie etwas gehoert.

Man muss eine Methode nur überschreibnen, wenn diese in der Superklaase abstrakt ist. (In Delphi auch nur, wenn man diese Nutzen möchte). Normale Methoden muss man nicht Überschreiben; virtual erlaubt das nur.

Zitat:

Ich kann doch Sachen ueberladen, ohne sie vorher ueberschreiben zu muessen (egal ob virtuell oder nicht).

Jein, da man nicht virtuelle Methoden ja nicht überschreiben kann.

[einbeliebigername]

Hallo,

ich gebe auch mal meinen Senf zum Thema überladen von virtuellen Methoden dazu.

Entweder so:

Delphi-Quellcode:

  TTest1= class
    procedure Test; virtual;
  end;

  TTest2= class(TTest1)
    procedure Test(const A: Integer); reintroduce; overload;
  end;

Oder so:

Delphi-Quellcode:

  TTest3= class
    procedure Test; overload; virtual;
  end;

  TTest4= class(TTest3)
    procedure Test(const A: Integer); overload;
  end;

einbeliebigername.

[trebor90]

@einbeliebigername:
Ok, dann ist das anders als zum Beispiel in C++. Da muss man Methoden nicht erst reintroducen, um eine Methode einer Basisklasse ueberladen zu koennen. Man ueberlaedt sie und - fertig.
Das heisst also, der Designer der Basisklasse legt in Delphi fest, ob man seine Methoden "einfach so" (ohne reintroduce) ueberladen kann?? Indem er hinter die betreffenden ein overload setzt????!

@mkinzler:
Nein. Warum denn eine Klasseneigenschaft?! Du hast mich wohl falsch verstanden. Ich rede nicht von pubnormalen Eigenschaften die faelschlicherweise oft als globale Variablen deklariert werden. Ich rede von einer Form, einem Fenster. Das Hauptfenster zum Beispiel, dass als erstes in der Applikation gestartet wird, muesste also eine lokale Variable der Hauptfunktion sein.
(Bitte schaut euch dazu meine Quelltexte an ...)
Sicherlich kann das jedes weitere Fenster eine Eigenschaft des Hauptfensters (und keine globale Variable) sein.

Zitat von mkinzler:

Man muss eine Methode nur überschreibnen, wenn diese in der Superklaase abstrakt ist. (In Delphi auch nur, wenn man diese Nutzen möchte). Normale Methoden muss man nicht Überschreiben; virtual erlaubt das nur.

--> Ok, warum blabbert mich dann aber Delphi mit Warnungen zu, obwohl ich Create UEBERLADE mit overload? Welches eben virtual ist, und welches ich nicht verdecken moechte (was mir aber der Compiler unterstellt).

Zitat von trebor90:

Ich kann doch Sachen ueberladen, ohne sie vorher ueberschreiben zu muessen (egal ob virtuell oder nicht).

Zitat von mkinzler:

Jein, da man nicht virtuelle Methoden ja nicht überschreiben kann.

Was??
Ich will doch gar nix ueberSCHREIBEN.
Ich wollte damit sagen, dass ich Methoden ueberladen kann. Dazu muss ich sie nicht ueberschreiben.
Egal ob sie virtuell sind oder nicht.
Ueberladen ohne sie vorher zu ueberschreiben, wie es einige sagen.
Ich muss Methoden nicht erst ueberschreiben, dass ich sie hinterher ueberladen kann.

--> Und in C++ muss eine Methode auch nicht virtuell sein, dass ich sie ueberschreiben kann. Das geht auch ohne.


Problem aber immer noch:
Was ist der Unterschied zwischen Verdecken und Ueberschreiben??
Ich kenne sowas wie "Verdecken" gar nicht.

[MGC]

Zitat von MGC:

In wie weit man hinter den ersten Konstruktor allerding override und overload zugleich setzen kann, weiß ich jetzt aus dem Stehgreif auch nicht, werde ich aber mal testen.

Ich zitiere mich hier mal selbst. Ich habe bereits im Thread mitgeteilt, dass ich mir nicht sicher bin ob es mit override und overload funktioniert. Hab ees jetzt getestet und bin in der Tat zu dem Schluss gekommen, dass man reintroduce verwenden muss, um überladene Methoden einzusetzen.

Was ich aber dennoch nicht ganz verstehe, weshalb eine feste Definition innerhalb einer Sprache nicht einfach hingenommen werden kann. Es gibt ja auch noch die Unterschiede bei div zwischen C++ und Delphi, wobei ich in dieser Hinsicht sagen muss, dass mir Delphi da besser gefällt. Auch dass es bei Delphi in der Grundeinstellung keine Header-Dateien gibt wie in C++ wurd enicht bemängelt, obwohl man dann von ganz unten bis nach ganz oben scrollen mus, anstatt einfach in den Header zu sehen wenn man Variablen oder Deklarartionen nochmals bearbeiten möchte.

[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.[...]