Komponente von TCustomSocket ableiten?

[Muetze1]

Moin!

Deine letzte Frage verstehe ich nicht, aber das Beispiel ist ein gutes Beispiel dazu. So kannst du in der Basisklasse z.b. die komplette Funktionalität implementieren und alle Aufrufe etc schon einbauen, aber wie es dann später genau implementiert wird bzw. wie gerechnet wird, hängt dann von der abgeleiteten Klasse ab.

MfG
Muetze1

[Pseudemys Nelsoni]

Moin Muetze,

mit meiner letzten Frage meinte ich, das Methoden die als "abstract;" definiert sind, in selbiger Klasse ja irgendwo aufgerufen werden, richtig?

[Muetze1]

Moin!

Ob sie aufgerufen werden ist die andere Frage, aber zumindest "... aufgerufen werden können", ja.

MfG
Muetze1

[Pseudemys Nelsoni]

Moin,

also für mich machen abstrakte methoden sonst keinen wirklichen sinn als eben wenn sie in der eigenen klasse bereits aufgerufen werden. Denn wozu wäre sie dann vorher als abstract definiert worden wenn sie nicht unbedingt gebraucht wird?

[Muetze1]

Moin!

Zitat von Pseudemys Nelsoni:

also für mich machen abstrakte methoden sonst keinen wirklichen sinn als eben wenn sie in der eigenen klasse bereits aufgerufen werden. Denn wozu wäre sie dann vorher als abstract definiert worden wenn sie nicht unbedingt gebraucht wird?

Da hast du auch vollkommen Recht mit allem, es würde keinen Sinn machen - ABER: es ist kein Zwang sie zu benutzen, auch wenn sie als abstrakt definiert wurde...

Du könntest damit auch Entwickler zwingen eine Procedure zu implementieren um auf irgendwas hinzuweisen bzw. eine Procedure zu implementieren die in der Basisklasse nicht gebraucht wird aber in jeder Ableitung genutzt werden muss...
Ist an den Haaren herbei gezogen und mir fällt kein Beispiel ein, aber wie ich oben schon geschrieben hatte: Du hast vollkommen Recht damit... - ich wollte nur darauf hinweisen das es kein Zwang ist - im Gegensatz zu dem Zwang die Methode zu implementieren in einer Ableitung...

MfG
Muetze1

[Pseudemys Nelsoni]

Gut Danke nochmal für die Erklärung

[Robert_G]

Abstrakte Methoden kannst du dir ähnlich wie Interfaces vorstellen. Wer immer sie implementiert geht eine Art Vertrag mit dir ein.
Damit du die Ableitung benutzen kannst muss sie sich an die Vereinbarung halten und diese Funktionalität implementieren.
Member, die für diese Vereinbarung unnütz sind, abstrakt zu deklarieren wäre natürlich totaler Blödsinn und würden das ganze Konzept ad absurdum führen.
Wenn ich abstrakte Member sehe, gehe ich davon aus, dass ich sie implmentieren muss.
Wenn sie der Autor nur aus Jux abstrakt deklariert hat würde ich ihm bei nächster Gelegenheit mit Anlauf in den Hintern treten.

[Hansa]

Zitat von Pseudemys Nelsoni:

Moin Mütze,

besten Dank

Könntest du mir noch erklären was der Sinn von abstrakten Methoden sein soll? Ich meine die Methoden selbst könnte man ja trotzdem einfach in einem Nachfolger deklarieren, wozu wird die vorher schon definiert?

Das ist doch ganz einfach : abstrakt ist eben abstrakt. Es existiert nur der Name der Prozedur und sonst nichts. Keinerlei Rumpf dafür. Das ganze dient hauptsächlich dazu, daß ein Komponentenentwickler Platzhalter schaffen kann und nur die DCU mitgibt. Also ist es normalerweiese nicht so wichtig. Solange du diesen Namen im Programm nicht verwendest passiert dann auch nichts. Falls doch, dann krachts eben. 8) Sofern das passiert, dann muß eben eine Prozedur mit gleichem Namen angelegt werden. Was da dann drin steht bleibt dir überlassen. 8)

[IngoD7]

Wurde eigentlich schon folgender wichtige Grund für Abstraktion genannt? Also:
Man kann - grob gesagt - eine abstract-Methode von TVater aufrufen kann und er guckt automatisch, welchen Typ die aufrufende Instanz besitzt. Abhängig davon, ob die Instanz vom Typ TKind1, TKind2 oder TKind3 ist, wird dann die Implementation der aufgerufenen Methode beim passenden Kind ausgeführt.

Das ist hier aber auch noch deutlicher erklärt.

[Muetze1]

Moin!

Nein, das erreiche ich auch mit einer puren virtuellen/dynamischen Methode - nur das ich dort nicht die Sicherheit habe, das die Nachfahren die Methode implementieren.

MfG
Muetze1