Komponente von TCustomSocket ableiten?

[Pseudemys Nelsoni]

Moin,

ich habe ein Problem und zwar möchte ich eine Komponente schreiben (abgeleitet von TCustomSocket), das Problem ist nun, das es bei meiner Nachfolger-Komponente direkt vor dem Erzeugen des Form1's zu einem "Abstrakten Fehler"(EAbstractError) kommt.

Die Frage: Was kann ich da jetzt tun? Ich möchte auf keinen Fall von TClientSocket ableiten, da dort die meisten Properties (die ich in meiner Komponente einfach nicht brauche) bereits published sind.

Vielleicht habt ihr ja eine Idee ;)

MfG Mario

[Muetze1]

Moin!

Der Fehler kommt daher, weil der TCustomSocket abstrakte Methoden enthält die du in deiner Ableitung überschreiben musst. Wenn du dies nicht tust und den Socket instanziierst und er auf eine solche Methode zugreift (oder einfach nur findet??), dann gibt es diese Exception.

MfG
Muetze1

[Pseudemys Nelsoni]

Tag Muetze,

muss ich auch Code in diesen überschriebenen Methoden einfügen oder reicht es wenn ich sie "Nur" überschreibe?

[Muetze1]

Moin!

Es reicht die entsprechenden Methoden zu überschreiben - die Methode selber kann leer bleiben.

MfG
Muetze1

[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?

[Robert_G]

Damit du alle Nachfahren unter der abstrakten Basisklasse zusammenfassen kannst. ;)
Abstrakten Member versichern dir, dass der NAchfolger eine eigene Implementierung mitbringt.
Leere Rümpfe wären absoluter Blödsinn. Wenn die Methode beim Instanzieren, Verbinden, whatever von TCustomSocket benutzt wird, dann wird sie nunmal gebraucht. ;)

[Pseudemys Nelsoni]

Wenn es Blödsinn ist die Rümpfe leer zu lassen, woher wüsste ich dann was in selbige an Code einzufügen ist?

[alcaeus]

Naja...wenn du mit Sockets arbeitest, dann könnte man z.B. davon ausgehen, dass du ein Socket für ein best. Protokoll machen willst. Jedes Protokoll sendet beim Verbinden andere Daten, und genau das musst du eben machen ;)
Sieh dir am besten mal die Sourcen zu Server- und Clientsocket an...

Greetz
alcaeus

[Muetze1]

Moin!

Abstrakte Methoden bieten dir z.B. den Vorteil das du eine Basisklasse bauen kannst die schon alles kann. So kannst du z.B. das Empfangen von Daten schon aufrufen und mit den Daten umgehen in der Basisklasse aber das Empfangen als abstrakte Methode deklarieren. Dadurch kannst du den Socket schon programmieren ohne dich auf das Wie und Wo des Empfangens festzulegen. Das müssen denn die Ableitungen machen - einfach nur noch die Daten ermitteln und zurückgeben - egal wodrüber. Man könnte z.B. eine Ableitung von einem TCustomSocket machen und alles über DDE laufen lassen anstatt einem WinSocket. Aber die Verwaltung, Umgang mit den Daten etc. ist schon alles im TCustomSocket implementiert, Details kommen in der Ableitung.

Ohne abstrakte Methode könnte die Basisklasse z.B. nicht sagen: Ich lese mir die Daten ein - weil es keine Methode zum Aufrufen gibt. und eine virtuelle bringt einem nix, da die Basisklasse da nix reinschreiben könnte, da sie sich nicht um das Wie und Wo kümmert. Und eine virtuelle Methode bringt in dem Zusammenhang die Fehlerquelle mit, das Ableitungen vielleicht vergessen ihre Empfangsroutine zu implementieren und schon funktioniert es nicht...

MfG
Muetze1

[Pseudemys Nelsoni]

hallo muetze, danke für eine erklärung.

Könntest du - wenn du lust hast - mir ein kleines beispiel schreiben wo eine abstrakte methode z.b gebraucht wird? Ich kapier sowas immer ein bisschen schwer, wenn ich Code sehe eher leichter :(

MfG

EDIT:

Ich glaub ich habs nun doch kapiert ;) abstract; ist für soetwa, richtig?

Delphi-Quellcode:

unit Unit2;

interface

uses
  SysUtils;

type
  TMainClass = class
  private
    function calculate(const a, b: integer): Integer; virtual; abstract;
  public
    function anotherfunc: string;
  end;

  TSubClassMult = class(TMainClass)
  private
    function calculate(const a, b: integer): Integer; override;
  end;

  TSubClassAdd = class(TMainClass)
  private
    function calculate(const a, b: integer): Integer; override;
  end;

implementation

{ TMainClass }

function TMainClass.anotherfunc: string;
begin
  Result := IntToStr(calculate(9, 9));
end;

{ TSubClassMult }

function TSubClassMult.calculate(const a, b: integer): Integer;
begin
  Result := a * b;
end;

{ TSubClassAdd }

function TSubClassAdd.calculate(const a, b: integer): Integer;
begin
  Result := a + b;
end;

end.

Also wenn eine Methode aus der Basisklasse eine andere Methode benötigt, richtig?

[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:

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. :evil:

[Hansa]

Zitat:

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. :mrgreen: 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

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

[Hansa]

Zitat:

Zitat von IngoD7

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

Schon mal versucht, eine abstracte Methode zu debuggen ? Viel Vergnügen. :lol:

Und wenn wir schon dabei sind : wo liegt der entscheidende Vorteil, ohne die Nachteile in Kauf zu nehmen ?

[Robert_G]

Das dürfte in jedem 2. Beitrag hier stehen. :roll: (oder anders ausgedrückt: Jedem, der nicht von dir ist. :mrgreen: )

[IngoD7]

Zitat:

Zitat von Hansa

Schon mal versucht, eine abstracte Methode zu debuggen ?

Du meinst, wenn ein EAbstractError ohne weitere Hinweise und ohne definierten Stop im Quelltext kommt?
Nun, wenn man beim sinnvollen Gebrauch von abstract-Methoden die Warnungen des Compilers nicht in den Wind schlägt, ist das möglich, bzw. der Fehler dürfte gar nicht erst passieren.

Zitat:

[Warnung] Unit1.pas( 48 ): Instanz von 'TAbleitung' mit der abstrakten Methode 'TBasis.TestProc' wird angelegt

Wenn man z.B. eine fremde Unit einsetzt, die tatsächlich notwendige Implementierungen in Ableitungen auslässt (ist ja schon grober Frevel!), dann ist mir die Fehlermeldung immer noch lieber, als ein stillschweigendes Gar-Nichts-Machen bei deiner leeren Virtuell-Methoden-"Lösung". Das führt dann nämlich zu Logikfehlern im Programm und/oder erst später zu Programmabbrüchen, die genau so schwer zu orten sind. Ursache ist ja immer noch die vergessene Implementation einer Methode.

Ne, ne, dann lieber eine klare Fehlermeldung, die mir deutlich sagt: Mit dieser Klasse stimmt was nicht!

Zitat:

Zitat von Hansa

[...]irgendwann habe ich die Implementation dieser Prozedur tatsächlich vergessen.[...]und ich verwende "virtual" statt "abstract" und schreibe notfalls in der Ur-Klasse nur :

Delphi-Quellcode:

begin end;

Seitdem ist Ruhe.

Wie oben geschrieben: Ruhe ist das allerletze, was ich bei einer derart fehlerbehafteten Klasse haben möchte. :cyclops:

[Muetze1]

Moin!

Ach, Diskussionen mit Hansa sind immer wieder witzig und mich muss mich hier allen (ausser Hansa) mal anschliessen: Die abstrakten Methoden haben vor allem Vorteile und bisher sehe ich keine direkten Nachteile. Warnungen und Hinweise sind neben Fehlern eine wichtige Ausgabe des Compilers und sollten/müssen wahrgenommen werden.

Und eins kann ich dazu sagen: Wenn einer stillschweigend irgendwo mal Begin/End; hinschreibt weil er mit abstrakten Methoden nicht umgehen kann, dann ist dies schon grob fahrlässig. Da suchen nachher vielleicht 2 Programmierer fast 3 Tage um so eine leere Funktion zu finden um dann festzustellen, das ein anderer in der Ableitung mit der Methode nix gemacht hat. So ein teuren Spass wird sich keine Firma zweimalig leisten. Derjenige darf danach entweder nur noch Dokumente klammern oder Kaffee kochen - je nachdem welcher der vorherigen Ex-Programmierer woanders eine Stelle gefunden haben... :mrgreen: .

MfG
Muetze1

[Hansa]

Hi Theoretiker :

programmiert eine abstrakte Klasse. Dann leitet ihr davon eine andere ab und noch 2 weitere. Immer schön abstrakt. :mrgreen: Und dann baut ihr irgendwo mittendrin etwas nicht definiertes ein. Und dann ? 8) Abstrakte Klassen sind hier im Hause jedenfalls zum Eigenbedarf wegen Sinnlosigkeit durchgefallen. Thats it.

[Muetze1]

Moin!

Zitat:

Zitat von Hansa

Und dann baut ihr irgendwo mittendrin etwas nicht definiertes ein. Und dann ?

Das passiert dir genaus bei virtuellen Methoden wenn du diese z.B: in einer Klasse mitten drinne abänderst bzw. das Originale versteckst - das Beispiel hat rein gar nix mit den abstrakten Klassen zu tun.

Ausserdem haben die 2. und 3. Ableitung nix mehr mit den abstrakten Methoden der Basisklasse am Hut, da sie die erste Ableitung implementiert. In den Ableitungen 2 und höher kannst du machen was du willst - ableiten oder auch nicht...

Zitat:

Zitat von Hansa

Abstrakte Klassen sind hier im Hause jedenfalls zum Eigenbedarf wegen Sinnlosigkeit durchgefallen. Thats it.

Omg, dann sag uns noch schnell wie das Haus heisst und ich weiss wo ich mich freiwillig nicht bewerbe... :mrgreen:

MfG
Muetze1

[Hansa]

@Mütze : nicht rumoren. 8) "Abstract" trägt nicht dazu bei, etwas zu verbessern. Also los : wo liegt der definitive Vorteil davon. Erwarte Antwort. :mrgreen:

[Muetze1]

Moin!

Zitat:

Zitat von Hansa

@Mütze : nicht rumoren. 8) "Abstract" trägt nicht dazu bei, etwas zu verbessern. Also los : wo liegt der definitive Vorteil davon. Erwarte Antwort. :mrgreen:

Soll ich dir jetzt (fast) alle Beiträge quoten aus diesem Thread??

Der definitive Vorteil: Du hast als Basisklassenprogrammierer die Sicherheit, das die Methode implementiert wird in der Ableitung - ausser natürlich man schlägt alle Warnungen und Hinweise des Compilers in den Wind...

MfG
Muetze1

[Chewie]

Versuch einem Blinden nicht das Sehen zu erklären, Muetze. Ich glaube, er WILL es nicht verstehen :? .

[IngoD7]

Zitat:

Zitat von Muetze1

Der definitive Vorteil: Du hast als Basisklassenprogrammierer die Sicherheit, das die Methode implementiert wird in der Ableitung - ausser natürlich man schlägt alle Warnungen und Hinweise des Compilers in den Wind...

Exakt!
Oder aus einer anderen Richtung betrachtet:
Ist eine Klassenfamilie erst einmal sinn-, ziel- und funktionsgerecht fertig programmiert, so ist es dem Programmierer, der sie einsetzt, wurscht, ob abstrakte Methoden darin vorkommen oder nicht. Sie tut, was sie soll, und gut.

Die Verwendung von abstract soll und kann aber dem Klassenprogrammierer bei der Entwicklung (und Erweiterung) dieser Klassenfamilie helfen, überhaupt da hin zu kommen, nämlich sie fehlerfrei zu gestalten. Und wenn sie fehlerfrei ist, so kommt es auch zu keinen Abstract-Fehlern, die man debuggen müsste.

Ich verstehe daher, Hansa, deine Sorgen bzgl. des "Debuggen von abstrakten Methoden" nicht.

a.) Als Programmierer, der eine fertige Klassenfamilie in seinem Projekt einsetzt, sagt dir ein Abstract-Error, dass die Klassen Schrott sind, weil der Klassenprogrammierer wohl geschlafen hat. Sei dann froh, dass es dir gemeldet wurde, nimm es zur Kenntnis, und verzichte auf die Klassen.
b.) Als Klassenprogrammierer sagt dir ein dabei auftauchender Abstract-Error, dass du Mist gebaut hast. Sei dann froh, dass es dir gemeldet wurde, nimm es zur Kenntnis und korrigiere deine Klassen, damit sie anständig funktionieren.

Somit ist doch der Abstract-Error in jedem Fall eine Hilfestellung zur fehlerfreien Programm- und Klassenerstellung.