Thema: Delphi Problem mit Tpbject

Einzelnen Beitrag anzeigen

Muetze1
(Gast)

n/a Beiträge
 
#15

Re: Problem mit Tpbject

  Alt 18. Jul 2009, 13:05
Zitat von shmia:
Oha! - dir ist wohl gerade eine Laus über die Leber gelaufen, sonst wäre dein Ton nicht so.
Nein, mich regt auf wenn Wissen falsch vermittelt bzw. falsches Wissen vermittelt wird.

Zitat von shmia:
Ich sag mal wenn man irgendwo eine Methode Assign nennt, dann muss man im Universum der VCL auch richtig machen.
Was hat TObject mit VCL zu tun? Rein gar nichts. VCL ist die Visual Component Library, also im Endeffekt TButton, etc. Dies hat nichts mit TObject zu tun. TObject ist die Basisklasse aller Objektorientiertkeit von Delphi. Es gibt nichts anderes. Und da die VCL objektorientiert ist, basiert sie schlussendlich auf TObject. Aber was die VCL implementiert kann jedem anderen OO Nutzer in Delphi schnuppe sein, wenn er nichts entsprechendes nutzen will bzw. entwickeln will.

Zitat von shmia:
(wird ja immer wieder falsch gemacht, weil das Prinzip dahinter nicht ganz einfach ist)
Das Prinzip ist mehr als einfach und es ist auch nichts mysteriöses dran.

Zitat von shmia:
Man darf natürlich jederzeit eigene Zuweisungsmethoden schreiben, dann sollte man aber nicht direkt den Namen Assign verwenden:
Das nächste Ding. Warum sollte man dies nicht Assign() nennen? Darf ich bei einer Ableitung von TObject auch meine Methoden nicht Paint, Resize, SetBounds etc nennen weil die VCL sie in einem ganz anderen Zweig des Klassenbaums einführt und so nennt? Wenn man ein eigenes System entwickelt - objektorientiert, also von TObject abgeleitet - dann muss man diese anders nennen obwohl man sich selbst die gesamte Struktur ausdenkt? Na dann sollten den heutigen Entwicklern bei Delphi ja bald die Namen für die Methoden ausgehen, da schon viele Jahre zuvor andere Entwickler ihnen die besten Namen wegschnappen konnten in dem sie sie verwendet haben.

Grundlegend: Der Delphi Compiler kann objekt-orientierten Code übersetzen und dabei gelten nur die Regeln die dieser definiert. Dabei gibt es bis auf die paar Schlüsselwörter und Basisklasse TObject (was optional ist bei der Angabe) nichts weiter zu beachten. Alles was man dann implementiert oder nennt ist in seinem eigenen Interesse.

/EDIT:

Zitat von shmia:
Was jetzt noch fehlt, sind zwei weitere Konstruktoren:
Warum fehlen die? Was willst du damit erreichen? 20 Constructoren in dern 6. Ableitung? Und was ist wenn man mal im Constructor was initialisieren muss? 20 Constructoren neu definieren und implementieren? Wenn ich Arbeit suche, dann frage ich beim Arbeitsamt und mache mir nicht selber Überstunden mit so etwas.

Vor allem da man sich für ein sauberere OOP Konzept diese überladenen Konstruktoren sparen sollte, stellen sie nichts anderes dar als eine Zusammenfassung des Standardkonstruktoraufrufs und anschliessendem Assign() Aufruf. Wenn du nun schon Assign() implementierst, dann brauchst du keine überladenen Konstruktoren mehr.

Vor allem sehe ich auch hier nicht ein, dass dieses als "fehlend" gekennzeichnet wird. Die fehlen ganz und gar nicht. Die sind überflüssig und erschweren jede weitere Ableitung.
  Mit Zitat antworten Zitat