Komponente von TCustomSocket ableiten?

[IngoD7]

Zitat:

Zitat von Muetze1

Nein, das erreiche ich auch mit einer puren virtuellen/dynamischen Methode

Stimmt. :gruebel: Für das, was ich ausgedrückt hatte, braucht man kein abstract.

Aber:

Zitat:

Zitat von Muetze1

- nur das ich dort nicht die Sicherheit habe, das die Nachfahren die Methode implementieren.

Kann man das so sagen? Die Sicherheit hast du doch nie.

Der Unterschied ist, dass wenn der Nachfahre die Methode nicht implementiert hat, es bei abstract zu einem Laufzeitfehler kommt, während bei nur-virtuell die beim Vorfahren dann zwangsläufig vorhandene (und dem Nachfahren vererbte) Methode abgearbeitet wird.

Wenn man dieses Beispiel von eben betrachtet, so kommt dort für die Methoden von TKoerper nur abstract in Betracht, weil eine Volumen- und Oberflächen-Berechnung (bzw. die Implementierung der entsprechenden Functionen) für TKoerper selbst unsinnig wäre.

[Muetze1]

Moin!

Zitat:

Zitat von IngoD7

Zitat:

Zitat von Muetze1

- nur das ich dort nicht die Sicherheit habe, das die Nachfahren die Methode implementieren.

Kann man das so sagen? Die Sicherheit hast du doch nie.

Doch, bei abstrakten Methoden - einzige Voraussetzung: ich nutze sie in meiner Klasse wo sie einführe...

Zitat:

Zitat von IngoD7

Wenn man dieses Beispiel von eben betrachtet, so kommt dort für die Methoden von TKoerper nur abstract in Betracht, weil eine Volumen- und Oberflächen-Berechnung (bzw. die Implementierung der entsprechenden Functionen) für TKoerper selbst unsinnig wäre.

Richtig.

MfG
Muetze1

[IngoD7]

Zitat:

Zitat von Muetze1

Zitat:

Zitat von IngoD7

Zitat:

Zitat von Muetze1

- nur das ich dort nicht die Sicherheit habe, das die Nachfahren die Methode implementieren.

Kann man das so sagen? Die Sicherheit hast du doch nie.

Doch, bei abstrakten Methoden - einzige Voraussetzung: ich nutze sie in meiner Klasse wo sie einführe...

Ich weiß, was du meinst - aber ich meinte, dass niemand einen Klassenprogrammierer zwingen kann, eine im Vorgänger abstracte Methode auch tatsächlich in seiner Ableitung zu implementieren. Wenn er es nun mal nicht will :mrgreen: oder es einfach vergisst ...

Daher auch meine danach folgende Aussage:

Zitat:

Zitat von IngoD7

Der Unterschied ist, dass wenn der Nachfahre die Methode nicht implementiert hat, es bei abstract zu einem Laufzeitfehler kommt, während bei nur-virtuell die beim Vorfahren dann zwangsläufig vorhandene (und dem Nachfahren vererbte) Methode abgearbeitet wird.

[Hansa]

Zitat:

Zitat von IngoD7

...Ich weiß, was du meinst - aber ich meinte, dass niemand einen Klassenprogrammierer zwingen kann, eine im Vorgänger abstracte Methode auch tatsächlich in seiner Ableitung zu implementieren. Wenn er es nun mal nicht will :mrgreen: oder es einfach vergisst ...

Und ? Dann greift aber zumindest die Methode des Vorgängers. Um es kurz zu machen : selber "abstract" zu benutzen ist einfach nur Unsinn. :mrgreen: Warum ? ein Beispiel aus der Praxis : ich habe eine Prozedur "ErmittlePreis" Diese soll nun verschiedene Tabellen benutzen, je nach Lage. Ich kann allerdings in der Vorfahrklasse noch gar nicht wissen, um was es später genau geht. Dann habe ich gedacht, was solls, deklariere das einfach als abstract. Und dann kams zwangsläufig so : irgendwann habe ich die Implementation dieser Prozedur tatsächlich vergessen. 8) Delphi macht dann folgendes : es sucht danach beim Vorfahr. Ist nichts da, bei dessen Vorfahr usw. Irgendwann wird es auf die abstract-Deklaration stoßen mit der sagenhaften Fehlermeldung "abstrakter Fehler". Und sonst nichts :!: Im ersten Moment hatte ich gar nicht so weit gedacht, daß das Wort "abstrakt" in der Fehlermeldung die Ursache nannte.

Seitdem ist das ganze für mich erledigt und ich verwende "virtual" statt "abstract" und schreibe notfalls in der Ur-Klasse nur :

Delphi-Quellcode:

begin end;

Seitdem ist Ruhe.

[Robert_G]

@Hansa
Das war doch ein ParadeBeispiel für einen Grund einer abstrakten Methode.
Deine nachträgliche Lösung ist das Paradebeispiel für schlechtes Code design. :mrgreen:

[Hansa]

Dummschwätzer. :mrgreen: Kümmere dich besser um deinen Oracle-Mist. :lol:

[Sanchez]

Wenn ich eine leere virtuelle Funktion statt einer abstrakten nehme ists doch viel leichter mal zu übersehen, dass man die überschreiben wollte.
Nimm eine abstrakte und der Kompiler meldet dann: Instanz von 'X' mit der abstrakten Methode 'Y' wird angelegt.

[Hansa]

So ist es. Ätsch :mrgreen: @RG

[Robert_G]

Zitat:

Zitat von Hansa

So ist es. Ätsch :mrgreen: @RG

Du hast schon bemerkt, dass dir auch Sanchez widersprochen hat? :gruebel:

[IngoD7]

Zitat:

Zitat von Hansa

Zitat:

Zitat von IngoD7

...Ich weiß, was du meinst - aber ich meinte, dass niemand einen Klassenprogrammierer zwingen kann, eine im Vorgänger abstracte Methode auch tatsächlich in seiner Ableitung zu implementieren. Wenn er es nun mal nicht will :mrgreen: oder es einfach vergisst ...

Und ? Dann greift aber zumindest die Methode des Vorgängers.

:shock: Hallo?!? Die Methode beim Vorgänger ist im zitierten Fall abstract und somit nicht vorhanden. Es greift also nuscht nix.

Außerdem beschreibst du im Rest deines Postings genau diesen Fall doch auch selbst :roll: : Er stößt auf eine abstract-Methode und fällt mit Fehler auf die Nase, was bei sinnvoller Anwendung von abstract ja auch gewünscht ist.

Dass dir die Stille einer leeren virtual-Methode lieber ist, als der klare Hinweis auf eine fehlerhafte Klassenprogrammierung, wundert mich nun schon etwas.