AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Meine Probleme mit Delphi-OOP ...

Ein Thema von trebor90 · begonnen am 22. Feb 2012 · letzter Beitrag vom 25. Feb 2012
Antwort Antwort
Seite 2 von 4     12 34   
trebor90

Registriert seit: 28. Mai 2009
43 Beiträge
 
#11

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 14:55
Ja, ok das stimmt.
Diesen ersten Konstruktor kann ich entfernen. Da ist richtig.
Aber es geht ja auch darum, dass ich hier eine lokale Variable erstellt habe. Dazu sagt z. B. niemand was.
Und es ging ja auch mehr um den ueberladenen Konstruktor der anderen Form, denn der verursacht die Warnung.

Und naja, um die ganzen anderen Probleme die bisher ungenuegende Beruecksichtigung fanden.
"Es amüsiert mich immer wieder, wenn Menschen all ihr Unglück dem Schicksal, dem Zufall oder dem Verhängnis zuschreiben, während sie ihre Erfolge oder ihr Glück mit ihrer eigenen Klugheit, ihrem Scharfsinn oder ihrer Einsicht begründen."
  Mit Zitat antworten Zitat
Benutzerbild von Bummi
Bummi

Registriert seit: 15. Jun 2010
Ort: Augsburg Bayern Süddeutschland
3.470 Beiträge
 
Delphi XE3 Enterprise
 
#12

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 15:00
Hat was damit zu tun das Create urspünglich virtual deklariert wurde

Delphi-Quellcode:
  TMyClass=Class
    Procedure TuWas(a:Integer);
    Procedure TuWasvirtual(a:Integer);virtual;
  End;
  TMyClass1=Class(TMyClass)
    Procedure TuWas(a:Integer;b:Integer);overload;
    Procedure TuWasvirtual(a:Integer;B:Integer);overload;
  End;
führt auch zu

[DCC Warnung] Unit2.pas(16): W1010 Methode 'TuWasvirtual' verbirgt virtuelle Methode vom Basistyp 'TMyClass'
Thomas Wassermann H₂♂
Das Problem steckt meistens zwischen den Ohren
DRY DRY KISS
H₂ (wenn bei meinen Snipplets nichts anderes angegeben ist Lizenz: WTFPL)
  Mit Zitat antworten Zitat
trebor90

Registriert seit: 28. Mai 2009
43 Beiträge
 
#13

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 15:27
Obwohl ich sie eigentlich gar nicht verbergen moechte, sondern nur ueberladen?
"Es amüsiert mich immer wieder, wenn Menschen all ihr Unglück dem Schicksal, dem Zufall oder dem Verhängnis zuschreiben, während sie ihre Erfolge oder ihr Glück mit ihrer eigenen Klugheit, ihrem Scharfsinn oder ihrer Einsicht begründen."
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.717 Beiträge
 
Delphi 6 Enterprise
 
#14

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 15:57
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.
Ralph
  Mit Zitat antworten Zitat
Benutzerbild von MGC
MGC

Registriert seit: 15. Mai 2008
Ort: Helsa
106 Beiträge
 
Turbo Delphi für Win32
 
#15

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 18:22
@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.
Marc
Programmieren ist wie Chemie:
1. Wenn man alles einfach nur zusammenschmeisst kommt es zu unerwarteten Reaktionen.
2. Wenn es plötzlich anfängt zu qualmen, muss man eben noch mal von vorn anfangen.
  Mit Zitat antworten Zitat
trebor90

Registriert seit: 28. Mai 2009
43 Beiträge
 
#16

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 20:16
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?

--
"Es amüsiert mich immer wieder, wenn Menschen all ihr Unglück dem Schicksal, dem Zufall oder dem Verhängnis zuschreiben, während sie ihre Erfolge oder ihr Glück mit ihrer eigenen Klugheit, ihrem Scharfsinn oder ihrer Einsicht begründen."
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.830 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 20:47
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.
Markus Kinzler
  Mit Zitat antworten Zitat
einbeliebigername

Registriert seit: 24. Aug 2004
140 Beiträge
 
Delphi XE8 Professional
 
#18

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 21:17
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.
  Mit Zitat antworten Zitat
trebor90

Registriert seit: 28. Mai 2009
43 Beiträge
 
#19

AW: Meine Probleme mit Delphi-OOP ...

  Alt 23. Feb 2012, 22:49
@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.
"Es amüsiert mich immer wieder, wenn Menschen all ihr Unglück dem Schicksal, dem Zufall oder dem Verhängnis zuschreiben, während sie ihre Erfolge oder ihr Glück mit ihrer eigenen Klugheit, ihrem Scharfsinn oder ihrer Einsicht begründen."

Geändert von trebor90 (23. Feb 2012 um 22:58 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von MGC
MGC

Registriert seit: 15. Mai 2008
Ort: Helsa
106 Beiträge
 
Turbo Delphi für Win32
 
#20

AW: Meine Probleme mit Delphi-OOP ...

  Alt 24. Feb 2012, 00:31
So, jetzt wirds richtig konfus.

Also erstmal zum Thema lokale Variable:
Wie muss ich das verstehen? Du ordnest Deinem MainForm eine lokale Variable unter, in die Du dan diese MainForm erzeugen willst? Meinst DU damit, dass Du diese Variable als Feld in Deinem MainForm hinterlegst? Dann würdest Du ja Dein Form in sich selbst erzeugen und kannst eigentlich erst richtig auf Dein Feld zugreifen, wenn Du Dein Form (das Objekt) erzeugt hast... Das klingt seltsam. Meine MainForm ist grundsätzlich in einer globalen Variable hinterlegt, es sei denn ich würde das MainForm aus einem eigenen Objekt heraus erzeugen und mich selbst um die Verwaltung (erzuegen, verwalten, freigeben) kümmern, bzw. einen Parent angeben, ansonsten überlasse ich das vollkommen Delphi.

Dann zum Thema überladen und reintroduce. Auf reintroduce bin ich nicht eingegangen, da Du es unbedingt vermeiden wolltest, weshalb auch immer.
Sieh das ganze mal aus der Sicht des Compilers. Du hast ein, von einer Basisklasse abgeleitetes, Objekt (in OOP ganz normal) dessen Konstruktor in der Basisklasse als virtuell deklariert ist (nicht abstrakt, sonst müsstest Du es auf jedenfall selbst beleben, siehe z.B. TStrings). Wenn Du nun einen eigenen Konstruktor Create erzeugst und nicht angibst, dass es sich um eine mögliche Erweiterung Deinerseits zum ursprünglichen Create, dann gibt es jetzt zweimal Create und der Compiler warnt Dich, dass Dein, in Deiner abgeleiteten Klasse angegebenes Create, den originalen virtuell deklarierten Konstruktor Create verdeckt. Da Du aber beim überladen den Befehl overload hinter beide Konstruktoren setzen musst, ist es zwingend erforderlich dieses dem Compiler mitzuteilen. Daher kannst Du entweder bereits den originalen Konstruktor überschreiben und erweitern, ein override udn ein overload hinzufügen und dann einen weiteren Konstruktor mit overload hinzusetzen, wenn seine Parameterliste sich vom ersten unterscheidet. Willst Du den originalen Konstruktor nicht erweitern, dann teilst Du dem Comiler mit reintroduce udn overload mit, dass es sich bei dem ersten Konstruktor um den originalen aus der Basisklasse handelt und das Du weitere überladene Konstruktoren für andere Zwecke hinzufügst.

In wie weit es in einer anderen Sprache anders gehandhabt wird ist uninteressant, ich kann auch nicht diskutieren, dass ich es in C++ blöd finde immer diese {} zu setzen, wo das doch in Delphi auch nicht so ist und aus meiner Sicht nur die Lesbarkeit des Quellcodes verschlechtert.

Innerhalb der Zeit, in der wir hier unzählige Symbole aneinandergefügt haben um miteinander zu diskutieren, hätte man zigmal reintroduce schreiben können, egal ob man es blöd findet oder nicht.

Aber bitte diese Antwort nicht bös auffassen, sie ist nicht so polemisch gemeint, wie sie vielleicht klingen mag, wenn man sich in ein Thema hineingesteigert hat.

Viele Grüße.
Marc
Programmieren ist wie Chemie:
1. Wenn man alles einfach nur zusammenschmeisst kommt es zu unerwarteten Reaktionen.
2. Wenn es plötzlich anfängt zu qualmen, muss man eben noch mal von vorn anfangen.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:51 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf