Klassendesign: Blockierender Constructor?

[Zacherl]

Hallo zusammen,

ich re-designe grade eine Klasse, die eine Netzwerk-Protokoll-Schicht implementiert. Dabei wollte ich beim Klassendesign folgende Aspekte vereinen:

• SÄMTLICHE Kommunikation soll über meine IO-Handler Klasse ablaufen (Send Methoden und Receive Events)
• Die darunterliegende Socket Implementierung (nur blocking) soll austauschbar sein

Für eingehende Daten hatte der IO-Handler bisher eine Methode HandleData , an die der Benutzer manuell die Daten übergeben musste, die er mit seinem Socket empfangen hat.
Für ausgehende Daten hatte ich bisher zwei Ansätze:

1. Socket Instanz wird im Constructor übergeben und der IO-Handler ruft dann selbstständig Send auf
2. IO-Handler hat ein OnSend Event, was vom Benutzer implementiert werden muss

Nun möchte ich aber einerseits HandleData loswerden und anderseits, dass der IO-Handler selbstständig senden kann (also eher Ansatz 1). Sprich: Der IO-Handler soll "Besitzer" des Sockets sein.

Meine Idee war jetzt das Socket im Constructor zu übergeben und dann selbstständig zu pullen:

Delphi-Quellcode:

type
  ISocket = interface
    function Send(Data: Pointer; Size: UInt32): UInt32;
    function Receive(Data: Pointer; Size: UInt32): Integer;
  end;

  TIOHandler = class(TObject)
  private
    FSocket: ISocket;
  public
    constructor Create(Socket: ISocket);
  end;

constructor TIOHandler.Create(Socket: ISocket);
var
  Data: array[0..1024 * 16] of Byte;
  Size: Integer;
begin
  inherited Create;
  FSocket := ISocket;
  // ..
  // internen Send-Thread erzeugen
  // ..
  repeat
    Size := FSocket.Receive(@Data[0], SizeOf(Data)); // blocking
    if (Size > 0) then
    begin
      InternalHandleData(@Data[0], Size);
    end;
  until (Size < 0);
end;

Meiner Intuition nach empfinde ich es allerdings als schlechtes Design im Constructor zu blockieren und komplexe Operationen auszuführen. Was sagt ihr dazu? Alternative wäre das Pullen in eine Methode auszulagern, aber dann habe ich wieder eine Art HandleData Methode, die extra aufgerufen werden müsste (was ich gerne vermeiden will).

Viele Grüße
Zacherl

[Stevie]

Da fiel mir sofort das hier ein: http://misko.hevery.com/code-reviewe...oes-real-work/

[Der schöne Günther]

Zitat von Zacherl:

Meiner Intuition nach empfinde ich es allerdings als schlechtes Design im Constructor zu blockieren und komplexe Operationen auszuführen. Was sagt ihr dazu?

Absolut.

Vielleicht möchte ich, als Benutzer der Klasse noch gar nichts senden. Vielleicht möchte ich die Klasse nur testen und sitze grade irgendwo ohne Netz. Es gibt viele Gründe, Google, Microsoft und Konsorten raten in ihren Ratgebern explizit immer davon ab, "real work" im constructor zu erledigen.

Der hier z.B. fasst das ganz nett zusammen:
http://www.daedtech.com/beware-the-bloated-constructor/

[himitsu]

Es gibt auch noch AfterConstruction, aber aus sicht des Programmierers wird das auch "im" TMyClass.Create aufgerufen.

Alternativ eine Start/Init-Methode, welche von Extern nach dem Create aufgeufen wird.

[Zacherl]

Okay, dann sind wir uns bezüglich des Constructors ja schonmal einig Testen der Klasse ohne Internet ist kein Problem. Dafür kann man das Socket Interface ja als Dummy implementieren.

Dann mal die Frage nach der besten Alternative. Momentan steht zu Auswahl:

• AfterConstruction
• Init/Start Methode, um Polling zu starten

Oder würdet ihr an meiner Stelle das Polling doch eher dem Benutzer überlassen (also der alte HandleData Ansatz)?

[Uwe Raabe]

Wie wäre es denn mit einem Event-gesteuerten Ansatz in der Art Socket.OnDataAvailable := MyHandleDataEvent ?

[Zacherl]

Zitat von Uwe Raabe:

Wie wäre es denn mit einem Event-gesteuerten Ansatz in der Art Socket.OnDataAvailable := MyHandleDataEvent ?

Das ginge ja in die selbe Richtung wie mein alter HandleData Ansatz. Da aber ja nicht jede Socket Komponente so ein Event besitzt (vor allem nicht mit der selben Parameter-Definition), sollte der Benutzer damals selbst auf ein OnDataAvailable Event reagieren und darin dann HandleData vom IO-Handler aufrufen. Bzw. im Fall von blocking Sockets hat der Benutzer entsprechend nach neuen Daten gepollt und bei Empfang dann HandleData aufgerufen.

Ist natürlich ohne Frage der Ansatz, der dem Benutzer die größte Freiheit lässt.

Was mich einfach stört ist, dass das Senden dann dem IO-Handler obliegt, das Empfangen aber in der Hand des Benutzers ist. Das Receive im Socket Interface wäre damit auf jeden Fall obsolet.