Constructor Rückgabewert nil-en statt Instanz zurückzugeben?

[Stevie]

Zitat von bernau:

Zitat von Stevie:

Arbeit im Konstruktor ist ein Anti Pattern

Wäre dann TFilestream.create ein Antipattern? dort wird ja auch im Constructor die Datei geöffnet.

Ein TFileStream klatscht dir mit einer Exception um die Ohren, wenn die Datei aus welchen Gründen auch immer nicht geöffnet werden kann und überlässt dir nicht nil oder eine unbrauchbare Instanz - und das ist dann auch eine Ausnahme.

Da ich nicht der "niemals/immer" Typ bin, bin ich persönlich keineswegs gegen alles außer Zuweisungen im Konstruktor. Wenn das, was dort geschieht zur Objektinitialisierung dient - und ein TFileStream ist ja nunmal dafür da (gut, man könnte jetzt argumentieren, dass das eigentliche Öffnen in einer Open Methode geschehen sollte), dann lass ich das durchaus zu.

Davon abgesehen ist die RTL und VCL aber keineswegs das Maß der Dinge, wenn es um guten Stil oder Befolgung von Patterns geht

[bytecook]

Zitat von Stevie:

Zitat von bernau:

Zitat von Stevie:

Arbeit im Konstruktor ist ein Anti Pattern

Wäre dann TFilestream.create ein Antipattern? dort wird ja auch im Constructor die Datei geöffnet.

Ein TFileStream klatscht dir mit einer Exception um die Ohren, wenn die Datei aus welchen Gründen auch immer nicht geöffnet werden kann und überlässt dir nicht nil oder eine unbrauchbare Instanz - und das ist dann auch eine Ausnahme.

Da ich nicht der "niemals/immer" Typ bin, bin ich persönlich keineswegs gegen alles außer Zuweisungen im Konstruktor. Wenn das, was dort geschieht zur Objektinitialisierung dient - und ein TFileStream ist ja nunmal dafür da (gut, man könnte jetzt argumentieren, dass das eigentliche Öffnen in einer Open Methode geschehen sollte), dann lass ich das durchaus zu.

Davon abgesehen ist die RTL und VCL aber keineswegs das Maß der Dinge, wenn es um guten Stil oder Befolgung von Patterns geht

This!

Eventuell auch in diesem Zusammenhang für den Threadersteller interessant: Dependency Injections von Nick Hodges (https://leanpub.com/dependencyinjectionindelphi)
(Stevie brauchts hws nicht mehr lesen )

[günni0]

Schön zu lesen, dass sich nicht alle unbedingt an irgendwelche Vorgaben halten die irgendjemand irgendwann mal in die Welt geworfen hat.
Was in meinem Konstruktor passiert sind kleinere Überprüfungen, Stringmanipulationen und das Erzeugen eines Threads. Mehr nicht.

Dafür, um das jetzt schön sauber zu bekommen, zerbreche ich mir jetzt nicht Tage lang den Kopf.

[DevLinus]

Wie wäre es mit einer Funktion, die man dazwischen Schaltet. Sprich eine Funktion die den String überprüft und wenn der String Valied ist wird der Constructor aufgerufen und wenn nicht gibt die Funktion Nil zurück.

Ich bin ein Fan davon nur richtige Werte an einen Constructor zu übergeben und mögliche "Fehlerquellen" vorher auszuschließen.

[günni0]

Ich versuche es mal.

Am liebsten wäre es mir natürlich, wenn meine ObjectList Records (mit class vars und class functions/procedures) aufnehmen könnte statt Klasseninstanzen. Dann hätte ich das ganze Problem erst gar nicht.

[Uwe Raabe]

Zitat von günni0:

Am liebsten wäre es mir natürlich, wenn meine ObjectList Records (mit class vars und class functions/procedures) aufnehmen könnte statt Klasseninstanzen.

Und warum nimmst du dann nicht eine TList<TMyRecord>?

[günni0]

Ich versuche es heute Nachmittag mal.
Schade nur, dass ich dann den Destructor verliere, oder ist dem nicht so?

Eigentlich bin ich ganz zufrieden so wie es jetzt ist.

[freimatz]

Zitat von günni0:

... und das Erzeugen eines Threads. Mehr nicht.

Der war gut

[günni0]

Ich gebe mal etwas vor. Wie sähe das denn korrekt aus mit einer Factory-Class?

Delphi-Quellcode:

type
 TMyClass = class
 public
  constructor Create(Parameter);
  destructor Destroy; override;
end;

implementation

constructor TMyClass .Create(Parameter);
begin
 prüfe dies

 prüfe das

 WENN Fehler/korrupte Daten, dann raise exception und abbrechen

 SONST
  am Ende erstelle Thread -A- oder -B-
end;

destructor TMyClass .Destroy;
begin
 if Assigned(ThreadA) then
  begin
   ThreadA.Stop; // Funktion in der Thread-Unit selber - hat schon seinen Sinn :P
   ThreadA.Free;
  end;

  // ThreadB, wenn Assigned, wird an anderer Stelle von Hand freigegeben

 inherited Destroy;
end;

Delphi-Quellcode:

TMyClass: TList;


try
 myClass := TMyClass.Create(Parameter);
except
end;

if Assigned(myClass) then // wenn oben rause ausgelöst wird, ist myClass not Assigned und muss nicht hinzugefügt werden
 MyGenericTList.Add(myClass);

[Uwe Raabe]

Warum nicht so?

Delphi-Quellcode:

try
  myClass := TMyClass.Create(Parameter);
  MyGenericTList.Add(myClass);
except
  // hier sollte schon och was passieren, oder?
end;