C# Konstruktor überladen möglich?

Nein das geht nicht.

Wie müsste ich alternativ Vorgehen?

Du schreibst einfach eine privat Methode (ich würde diese "init" 
nennen), die aus dem Konstruktor mit den gewünschten Parametern 
aufgerufen wird. Innerhalb deines Objekts kannst du diese "init" mit den 
neuen Parametern aufrufen. Stell nur sicher, dass alle Felder, 
Eigenschafte zurückgesetzt werden, damit du keine unsauberen Zustände 
hast.

Je nach Scope wäre das erstellen eines neuen Objekts das einfachste, mit 
dem du dein vorhandenes überschreibst.

Sollte das alles nicht passen, würde ich mich mit Creational Patterns 
beschäftigen, im Detail mit dem Builder Pattern.

Als erste Idee:
http://www.dofactory.com/net/design-patterns


Grüße
Lucas

Da gibts drei Möglichkeiten.

1. Du machst dir eine Methode, die alles Einrichtet und ruft die aus dem 
ctor heraus auf (und dann mehr oder weniger direkt, wenn du dein Object 
ändern willst)

2. du wirfst das alte Object weg und erstellst ein neues.

3. Du überlegst dir, ob dein bisheriges Konstrukt nicht verbessert 
werden kann.

Hi!

Warum möchtest Du den Konstruktor neu aufrufen?

Hast Du keinen Zugriff auf den Code, um Zugriffsmethoden für die 
Objekteigenschaften hinzuzufügen?

Ist irgendwie gehen das Konstruktorprinzip. Der Konstruktor wird bei zur 
Erstellung eines Objekts aufgerufen. Du willst aber an einem bestehenden 
Objekt was ändern. Du brauchst eine neue Methode dafür.

Wenn NJ recht hat und du eine Bibliothek benutzt, solltest du dir 
Extension Methods anschauen. Damit könntest du eine Extension schreiben, 
die ein neues Objekt erstellt und das vorhandene überschreiben. Fühlt 
sich dann wie eine Methode der Klasse an, hat aber keinen Zugriff auf 
privat oder protected.


https://docs.microsoft.com/de-de/dotnet/csharp/programming-guide/classes-and-structs/extension-methods

Grüße
Lucas

Hallo, eine Methode ist in diesem Fall auch nicht richtig, weil es 
sicherlich um Eigenschaften des Objekts handelt, deshalb wären hier 
öffentliche Eigenschaften des Objekts besser.

1

public class MyServer

2

{

3

4

  public string IP {get;set}

5

  public string Name {get;set}

6

7

  //ctor 1 

8

  public MyServer()

9

  {

10

  }

11

12

  // ctor 2

13

  public MyServer(string ip, string name)

14

  {

15

    IP = ip;

16

    Name = name;

17

  }

18

19

}

Dirk schrieb:
> Hallo, eine Methode ist in diesem Fall auch nicht richtig, weil es
> sicherlich um Eigenschaften des Objekts handelt, deshalb wären hier
> öffentliche Eigenschaften des Objekts besser.
>
> public class MyServer
> {
>
>   public string IP {get;set}
>   public string Name {get;set}
>
>   //ctor 1
>   public MyServer()
>   {
>   }
>
>   // ctor 2
>   public MyServer(string ip, string name)
>   {
>     IP = ip;
>     Name = name;
>   }
>
> }

Damit verlagerst Du aber die Logik vom der aufgerufenen Klasse in die 
aufrufende Methode. Aus Sicht von "Separation of Concerns", Kapselung, 
... völlig falsch.

Grüße
Markus

Deine Meinung kann ich nich vertreten, weil es in meinem Beispiel nach 
MVVM pattern ein Model ist und über die öffentlichen Eigenschaften 
lassen sich die Eigenschaften durch Viewbinding komfortabel darstellen.