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

[günni0]

In einem Konstruktor einer Klasse verarbeite ich eine Stringvariable. Wenn der Inhalt in irgendeiner Art und Weise korrupt ist, wird im Constructor nichts weiter verarbeitet.

Das Problem ist, dass ich diese Klasseninstanz beim Erzeugen in eine generische TObjectList<> packe: GenerischeTObjectList.Add(Klasse.Create(Parameter)); Wenn im Konstruktor nun wegen korrupter Daten keine weiteren Daten vorbereitet werden, soll ein Schlussstrich gezogen werden und diese Instanz nicht in die generische TObjectList gepackt werden.

Wie bewerkstellige ich das?

[freimatz]

Im constructor eine exception raisen und außen dann entsprechend behandeln.
Oder das ganze Design überarbeiten. Solche Dinge gehören eigentlich nicht in einen Konstruktor.

[günni0]

Es ist nur ein String der dort verarbeitet wird. Wird so schlimm nicht sein

Ansonsten hätte ich diese Verarbeitung bzw. einen Prozeduraufruf doppelt, da ich zwei Stellen habe wo ich den Constructor aufrufe.

Ist das hier ausreichend (Code ist nur zum Verständnis)

Delphi-Quellcode:

try
 InstanceX := ClassX.Create(); // raise exception im Constructor mit Nachricht für mein Log-File
except
end;

if Assigned(InstanceX) then
 GenerischeListe.Add(InstanceX);

[himitsu]

Kein Constructor, sondern eine Class-Function, die auch gern CreateIrgendwas heißen darf.
Da drin kannst du dann machen was du willst.

[Stevie]

Arbeit im Konstruktor ist ein Anti Pattern

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

[bernau]

Zitat von himitsu:

Kein Constructor, sondern eine Class-Function, die auch gern CreateIrgendwas heißen darf.
Da drin kannst du dann machen was du willst.

So würde ich das auch machen

bzw. ich mache das so öfters.

[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

[günni0]

Zitat von himitsu:

Kein Constructor, sondern eine Class-Function, die auch gern CreateIrgendwas heißen darf.
Da drin kannst du dann machen was du willst.

So einfach ist das nicht.
Das ist eine Klasse deren Konstruktor entweder einen Thread A oder Thread B erzeugt. Thread A hat zudem ein Notify-Event als Parameter.

Und dann kommt noch hinzu, dass meine generische Liste Instanzen dieser Klasse aufnimmt.
Einfach hier und da was ändern is nich.

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