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?