Konstruktor im Konstruktor aufrufen

[Neodym]

Hi,

ich wollte fragen, ob man mitten im Konstruktor einer Klasse einen anderen Konstruktor aufrufen kann, sodass dabei nur ein Objekt erzeugt wird (also der eine Konstruktor verrichtet bei mir Initialisierungsarbeiten).
Mit der normalen Standardkonstruktorverkettung komme ich nicht weiter, da ich erst einen Wert aus einer Datei lesen muss. Diesen Wert würde ich gerne als Parameter einem anderen Konstruktor übergeben.

Ich habe schon Folgendes versucht (für die Klasse Foo):
[highlight=c#]
this(meinParameter);
[/highlight]

Funktioniert nicht, da der Compiler hier eine Methode erwartet.
Dann bin ich beim Herumstöbern auf

[highlight=c#]
new Foo(meinParameter);
[/highlight]

gestoßen. Das funktioniert natürlich auch nicht, weil ja dann beim Erzeugen einer Instanz nocheinmal eine Instanz erzeugt wird, deren Referenz nicht gespeichert wird.

Hat jemand eine Idee?


Greets
Neodym

[gfoidl]

Hallo,

ob man mitten im Konstruktor einer Klasse einen anderen Konstruktor aufrufen kann

du meinst einen anderen Konstruktor der selben Klasse? Nein geht nicht.

der eine Konstruktor verrichtet bei mir Initialisierungsarbeiten

Lagere die Initialisierungsarbeiten in eine private Init-Methode aus. Diese kann dann von beiden Ctors aufgerufen werden.

Wenn das auch nicht reicht ist eine Fabrik (Factory) eine weitere Möglichkeit.


mfG Gü

[fanderlf]

Ehm naja sowas kann man halt machen:

[highlight=c#]
public class MyClass
{
public MyClass(string param1)
:this()
{
//Hier kann ich optional noch Parameter mitgeben
}

public MyClass()
{
//Hier steht das was immer passieren muss
}
}
[/highlight]

Dann wird automatisch der Konstruktor mit den leeren Parametern aufgerufen. Natürlich könnte man auch einen anderen mit Parametern aufrufen.

[Neodym]

@fanderlf
Wie gesagt, das geht ja nicht, weil ich ja den Konstruktor mit einem aus einer Datei gelesenen Wert aufrufen will.

@gfoidl
Ok, habe es so gemacht. Ist mir eigentlich auch zuerst in den Sinn gekommen, aber ich wollte eben wissen, ob ein solches Vorhaben prinzipiell möglich wäre. Jetzt weiß ich, dass es nicht geht (habe beim Suchen auch nichts dergleichen gefunden)

Danke für eure Hilfe.

Greets
Neodym

[fanderlf]

Das klingt irgendwie auch nach einem Konstrukt was nichts miteinander zu tun haben sollte. Etwas aus einem File laden hat nichts in einem Konstruktor einer Klasse verloren. Allein der Ladevorgang sollte schon in einer separaten Klasse stattfinden.

[gfoidl]

Hallo,

das Vorgehen mit dem Laden aus einer Datei kann schon auch Sinn machen. Z.B. bei Konfigurations-Zeugs. Hier würde ich das nicht in eine extra Klasse unbedingt aufteilen.

I.d.R. hat aber Florian recht. Auch der Testbarkeit wegen.


mfG Gü

[fanderlf]

Naja... aber Konfiguration direkt aus einem File in eine Datei reinladen ist schon fast grob fahrlässig. Für was haben wir denn DI und andere Konzepte zur Konfiguration einer Klasse? Ausserdem ist das Laden von irgendwelchen Daten aus einer Datei ein rein technischen Konzept. Die Konfiguration der Klasse ist wahrscheinlich ein fachliches Konzept. Betreibt man in irgendeiner Weise Separation of concerns (evtl. auch Domain Driven Design), dann darf so etwas nicht in derselben Klasse stehen.

So genug rumgemotzt

[Christian Marquardt]

Mal ein Blick hierein (wenns auch nicht NET ist)
http://de.wikipedia.org/wiki/Java_Ar...or_XML_Binding

Wozu sollte das Laden von Daten die in eine Klasse kommen sollen (Konfiguration, xxxx) dann in ein anderen Klasse erfolgen?

[gfoidl]

Hallo Florian,

aber Konfiguration direkt aus einem File in eine Datei reinladen ist schon fast grob fahrlässig.

Inwiedern unterscheidest du File und Datei? Für mich ist das dasselbe (bis auf die Sprache)

Für was haben wir denn DI und andere Konzepte zur Konfiguration einer Klasse?

Du schreibst von Konfiguration einer Klasse. Ich meine Konfiguration allgemeiner. Z.B. Connectionstrings, eigene Abschnitte in app.config od. einer XML-Datei od. sogar eigener DI-Container. Da macht das schon Sinn.

Auch SoC kann übertrieben werden

mfG Gü

[fanderlf]

Kleines Beispiel zur Klärung was ich dachte dass der OP vor hat:

[highlight=c#]
public class MyClass
{
public int Prop1 { get; private set; }
public int Prop2 { get; private set; }

public MyClass(string filename)
{
var config = File.ReadAllText(filename);
var values = config.split('\t');
Init(Convert.ToInt32(values[0]), Convert.ToInt32(values[1]));
}

public MyClass(int prop1, int prop2)
{
Init(prop1, prop2);
}

private void Init(int prop1, int prop2)
{
this.Prop1 = prop1;
this.Prop2 = prop2;
}
}
[/highlight]

Ich denke es macht hier einfach keinen Sinn den Filezugriff in den Konstruktor zu packen. Das hat da einfach nichts verloren Wenn dann eher eine Factory. Sowas vielleicht:

[highlight=c#]
public class MyClass
{
public int Prop1 { get; private set; }
public int Prop2 { get; private set; }

public MyClass(int prop1, int prop2)
{
Init(prop1, prop2);
}

private void Init(int prop1, int prop2)
{
this.Prop1 = prop1;
this.Prop2 = prop2;
}

public static MyClass Create(string filename)
{
var config = File.ReadAllText(filename);
var values = config.split('\t');
return new MyClass(Convert.ToInt32(values[0]), Convert.ToInt32(values[1]));
}
}
[/highlight]

Wenn man einen DI Container verwendet würde ich an dieser Stelle auch nicht static verwenden, sondern eine 2. Klasse bauen (IMyClassFactory - FileMyClassFactory) und mir diese injecten lassen. Die eigentliche Klasse sollte imho nichts mit ihrer Konfiguration zu tun haben.

[gfoidl]

Hallo Florian,

Die eigentliche Klasse sollte imho nichts mit ihrer Konfiguration zu tun haben.

Mit ihrer Konfiguraiton nichts -> dafür gibts DI, da sind wir uns einig. Aber wenn die Klasse die Konfiguration ist dann schon .

Aber kehren wir wieder zurück zum Thema des OT.

mfG Gü

[fanderlf]

Im Endeffekt gehts mir eigentlich ums Repository Pattern. Ich habe irgendwo Daten die ich laden und/oder speichern möchte, diese werden durch irgendeine Entity repräsentiert. Wo ich die jetzt her habe sollte durch ein Repository abstrahiert werden
Aber ich denke Du meinst auch das gleiche und wir reden einfach aneinander vorbei.

Back to topic

[Neodym]

Ok,

werde das Prinzip separation of concerns befolgen und das Einlesen trennen.
Vllt. zur Erklärung: Es ging darum etwas von Java nach C# zu portieren. Dabei ging es hauptsächlich um Algorithmen, d.h. um das Prinzip und nicht um eine konkrete Anwendung. Deshalb wurde im Konstruktor Daten aus Dateien gelesen, was ja eigentlich grob fahrlässig ist.
Danke für eine Kommentare, habe dadurch von Design Patterns erfahren, die ich bis jetzt noch gar nicht gekannt hatte.

Greets
Neodym