Mehrere unterschiedliche Objektersteller alle als 'Create'?

[Mikkey]

Ich habe eine Klasse, die bereits zwei Konstruktoren besitzt. Nun entsteht eine weitere Methode, die auf eine dritte Weise ein Objekt (mit einer anhängenden baumartigen Struktur aus gleichen Objekten) erzeugt, das dann als Wurzelelement des Baums dient.

In C# oder C++ würde ich das mit verschiedenen statischen Funktionen machen.

Ist es in Delphi angebracht, alles als Konstruktoren zu erzeugen:

Delphi-Quellcode:

constructor Create(vorgaenger: TKlasse); overload;       // Bearbeitungsmodus
constructor Create(wert1, wert2, wert3: TTyp); overload; // Erstellen aus vorhandenen Daten
constructor Create(ID: Integer); overload;               // Einlesen aus Datenbank, Erstellen Baum

Alternative:

Delphi-Quellcode:

class function CreateFromValues(wert1, wert2, wert3: TTyp): TKlasse;
class function CreateFromDB(ID: Integer): TKlasse;

Oder ist es eher eine Frage des persönlichen Geschmacks?

[Neutral General]

Hallo,

Also in meinen Augen ist das Geschmackssache.

[sx2008]

Der Code im Konstruktor sollte möglichst einfach sein und insbesondere keine potentielle Quelle für Exceptions sein.
Den folgenden Konstruktor nennt man copy constructor weil das übergebene Objekt von gleichen Typ wie die Klasse selbst ist:

Delphi-Quellcode:

constructor TKlasse.Create(vorgaenger: TKlasse); overload;

Innerhalb des Konstruktors werden nur Daten kopiert und das geht so auch völlig in Ordnung.

Auch der Konstruktor der mehrere Werte aus einfachen Typen entgegen nimmt und im Objekt ablegt ist kein Problem.

Aber der Konstruktor

Delphi-Quellcode:

constructor Create(ID: Integer); overload; // Einlesen aus Datenbank, Erstellen Baum

passt hier nicht rein.
1. können bei Datenbankzugriffen Exceptions ausgelöst werden und 2. muss zwangsläufig auf globale Variablen (Datenmodul, Query, Connection) zugegriffen werden.

Günstiger wäre es die Erzeugung eines Objekts dieser Klasse an anderer Stelle vorzunehmen:

Delphi-Quellcode:

function TDatenModul.CreateXYobjekt(ID: Integer):TKlasse;
begin
  Query1.parameters.ParamValues['ID'] := ID;
  Query1.Open;
  Result := TKlasse.Create(Query1['...'], ...);
  Query1.Close;
end;

Für die Beantwortung der Frage was in einen Konstruktor gehört und was nicht, versuche Dir einfach vorzustellen du müsstest die Unit mit der Klasse in einem anderen Programm benützen.
Das bedeutet z.B. das der Zugriff auf globale Variablen nicht möglich ist.

[Dragon27]

Hallo,

also ich denke auch, dass es eher Geschmackssache ist. Wobei ich die statischen Funktionen nicht verwenden würde, einfach
weil man es seltener sieht. Auch das Freigeben der zurückgelieferten Klasse kann zu Memory Leaks führen. In C# ist das Thema
ja nicht zu beachten ;)

[himitsu]

Ein Contructor "muß" nicht immer "Create" heißen ... auch da sind unterschiedliche Namen möglich.

Man kann es zwar auch als "externe" Funktion machen, aber wenn, dann nehm ich lieber Class-Funktions, aber im Prinzip ist es fast das Gleiche wie ein Contructor ... aber in einer Klasse oder einem Record, sind diese wenigstens in einem "Namespace" zusammengefasst.

[Mikkey]

Der Konstruktor mit dem Parameter 'vorgaenger' ist kein Copy-Konstruktor, sondern dient zum Aufbau der Baumstruktur während der Bearbeitung. Bei einem Copy-Konstruktor hieße der Parameter 'source'.

Zitat:

Zitat von sx2008 (Beitrag 1231656)

Günstiger wäre es die Erzeugung eines Objekts dieser Klasse an anderer Stelle vorzunehmen:

Delphi-Quellcode:

function TDatenModul.CreateXYobjekt(ID: Integer):TKlasse;
begin
  Query1.parameters.ParamValues['ID'] := ID;
  Query1.Open;
  Result := TKlasse.Create(Query1['...'], ...);
  Query1.Close;
end;

Das halte ich nun wieder für überhaupt nicht zielführend, denn ausschließlich meine Klasse weiß, welche Variablen sie enthält und welche sie damit aus einer Datenbankabfrage (deren Semantik auch nur sie selbst kennen kann) gewinnen kann.

Das Argument, dass bei der Abfrage etwas schiefgehen kann, zieht natürlich, also werde ich die Static-Function-Variante wählen.

[Furtbichler]

Ich persönlich würde einen einzigen Konstruktor verwenden, und zwar einen, der das Objekt instantiiert und notwendige Daten initialisiert. Sonst nix, wie sx2008 schon sagte. Bei Dependency Injection kann man hier natürlich überladene Konstruktoren angeben.

Wenn ich das Objekt auf unterschiedliche Art und Weise initialisiere (denn das ist es ja eigentlich, was die einzelnen Konstruktoren tun), dann könnte ich mir eine 'Initialize' - Methode vorstellen, die dann überladen ist.

Eine Methode soll genau eine Sache erledigen. Konstruktoren erzeugen (ggf. auch abhängige Felder). Fertig.

[Mikkey]

Zitat:

Zitat von himitsu (Beitrag 1231659)

Ein Contructor "muß" nicht immer "Create" heißen ... auch da sind unterschiedliche Namen möglich.

Das ist mir bewusst, aber die Argumente, die ich hier bisher dafür gelesen habe, sind schon zündend.

Zitat:

Zitat von himitsu (Beitrag 1231659)

Man kann es zwar auch als "externe" Funktion machen, aber wenn, dann nehm ich lieber Class-Funktions, ... aber in einer Klasse oder einem Record, sind diese wenigstens in einem "Namespace" zusammengefasst.

Das sehe ich auch so...

[Mikkey]

Zitat:

Zitat von Furtbichler (Beitrag 1231661)

Wenn ich das Objekt auf unterschiedliche Art und Weise initialisiere (denn das ist es ja eigentlich, was die einzelnen Konstruktoren tun), dann könnte ich mir eine 'Initialize' - Methode vorstellen, die dann überladen ist.

Wenn ich Objekte mit einem Konstruktor initialisiere, stelle ich damit sicher, dass die privaten Felder nur auf die Weise geändert werden, die die Klasse vorgibt. Wenn ich eine Initialize-Methode veröffentliche, habe ich das Risiko, dass die eben nicht nur unmittelbar nach dem Erzeugen des Objekts aufgerufen wird, sondern auch danach noch.

[Furtbichler]

Zitat:

Zitat von Mikkey (Beitrag 1231663)

Wenn ich eine Initialize-Methode veröffentliche, habe ich das Risiko, dass die eben nicht nur unmittelbar nach dem Erzeugen des Objekts aufgerufen wird, sondern auch danach noch.

Das ist richtig. Aber das kannst Du ja sicherstellen. Ich kann doch ein Objekt instantiieren und erst später zum Gebrauch Initialisieren.

Delphi-Quellcode:

Constructor TMyClass.Create(ImportantValues : TSetOfValues);
Begin
  ThisAndThat := ImportValues;
  Initialized := False;
End;

procedure TMyClass.LoadFromDatabase(...);
Begin
  If Initialized then Raise Exception.Create("Object allready initialized");
  Database.Load(Self);
  Initialized := true;
End;

Ist jetzt nicht so kompliziert. Ich kann deinen Einwand aber nachvollziehen. Das Belegen mit Initialwerten gehört in den Konstruktor, denn damit wird das Verhalten der Instanz definiert.

Das Laden aus einer Datenbank gehört eindeutig nicht dort hin. Es ist zudem viel schlechter testbar.