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.

[Namenloser]

Kann man sich drüber streiten. Ich finde es spricht nichts dagegen, eine statische Factory-Methode zu haben, die eine Instanz erzeugt und die Initialwerte aus der Datenbank liest. Ob man das jetzt als statische Methode implementiert oder als zusätzlichen Konstruktor, macht eigentlich keinen Unterschied.

Ich würde dazu tendieren, im Falle von Konstruktoren diese dann unterschiedlich zu benennen (aber alle mit Präfix „Create“), da ich finde, je mehr der Name einer Methode darüber verrät, was sie macht, desto besser.

Zu Dependency Injection kann ich hier nur sagen KISS.

[himitsu]

Zitat:

Zitat von NamenLozer (Beitrag 1231676)

Ich würde dazu tendieren, im Falle von Konstruktoren diese dann unterschiedlich zu benennen (aber alle mit Präfix „Create“), da ich finde, je mehr der Name einer Methode darüber verrät, was sie macht, desto besser.

Das sowieso, vorallem da man es hier auch mit der Codevervollständigung einfacher hat.

[Mikkey]

Zitat:

Zitat von Furtbichler (Beitrag 1231673)

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

Das war der Anlass der Frage, das Laden der komplexen Struktur wird also kein Konstruktor.

[Mikkey]

Zitat:

Zitat von himitsu (Beitrag 1231677)

Codevervollständigung

Du meinst die Delphi7-Sanduhrfunktion? Das habe ich abgeschaltet, damit ich mit nicht nach dem Tippen jedes Punktes einen Kaffee holen gehe. :(

[Furtbichler]

Da scheinst Du aber entweder ein Riesenprojekt oder einen total lahmen PC zu haben. Ich hab ein Legacy-Projekt in D6 mit 200.000 LOC und keine Probleme damit. Nur am Anfang kurz (weil ja irgendwann alles geladen werden muss).

[Mikkey]

Zitat:

Zitat von Furtbichler (Beitrag 1231740)

Da scheinst Du aber entweder ein Riesenprojekt oder einen total lahmen PC zu haben. Ich hab ein Legacy-Projekt in D6 mit 200.000 LOC und keine Probleme damit. Nur am Anfang kurz (weil ja irgendwann alles geladen werden muss).

der PC ist schon OK, aber die Entwicklung ist in XP-VM. Allerdings besteht das Projekt aus 7 MB .Pas und 4 MB .DFM-Dateien (Lines habe ich noch nicht gezählt).

[Lemmy]

Zitat:

Zitat von Mikkey (Beitrag 1231741)

der PC ist schon OK, aber die Entwicklung ist in XP-VM. Allerdings besteht das Projekt aus 7 MB .Pas und 4 MB .DFM-Dateien (Lines habe ich noch nicht gezählt).

dann geh nochmal in dich: XP-VM mit Delphi 7 (und installierten AH-Tools!) pas über 20 MByte, dfm um die 15 MByte. Nullos Problemos! Die VM hat 2GByte RAM und es läuft auch allerhand sonst noch (ja auch ein Virenscanner :-)....

Nachtrag: Ich hoffe nicht, dass du eine pas mit 7MByte hast - das würde das Verhalten in jedem Fall erklären...