wie kann ich überladene Konstruktoren "umleiten"?

[zero-2-one]

Hallo,

bin über die Suchfunktion gerade nicht fündig geworden...

Also ich habe eine Klasse in der zwei Konstruktoren sind. Der erste bekommt einen int übergeben und soll direkt etwas damit machen und der zweite bekommt einen String übergeben, den ich wenn möglich in einen int konvertiere (sonst halt ne exception) und der dann den ersten konstruktor mit genau diesem int aufruft. ich weiß jetzt aber nicht, wie ich auf den ersten Konstruktor umleiten kann und hoffe, dass mir das kurz wer erklärt.

  public Konstruktor(int x)  // Das ist mein Konstruktor 1
  {
     this.wert = x;
     tueWasMitX();
  }
  
  public Konstruktor(String x) // Das ist mein Konstruktor 2
  {
    try
    {
      int temp = Integer.parseInt(x);
      
     // das hier waren meine drei Ideen, aber in allen Fällen meckert der Compiler

      Konstruktor(temp);             //Variante 1
//      this(temp);                      //Variante 2
//      this.Konstruktor(temp);    //Variante 3

    }
    catch(NumberFormatException e)
    {
      meckereRum();
    }
  }

Also mir ist klar, dass ich in beide Konstruktoren einfach das gleiche reinschreiben könnte oder aber dadurch wird doch irgendwie die Wartbarkeit eingeschränkt, oder?

 

[SlaterB]

wenn du umleiten möchtest dann muss
this(int);
als erster Befehl im Konstruktor stehen,
z.B. this(Integer.parseInt(x));

du darfst nicht mal try/catch drumschreiben,
wenn die Exception zwingend abzufangen wäre, müsstest du throws Exception an den Konstruktor schreiben


als alternative bleibt noch der Aufruf eine Operation, idealerweise statisch:
this(parse(x));
darin dann alle Möglichkeiten

--------

Alternative: beide Konstruktoren rufen Operation init(int) auf,
der String-Konstruktor kann dann gerne vorher noch String in int wandeln

 

[Leroy42]

Also mir ist klar, dass ich in beide Konstruktoren einfach das gleiche reinschreiben könnte oder aber dadurch wird doch irgendwie die Wartbarkeit eingeschränkt, oder?

Richtig! Dein Ansatz ist wesentlich besser:

Deine Variante 2 ist korrekt!

 

[eicon11]

Hi, ich glaube eine Klasse kann keine 2 Konstruktoren enthalten, du kannst ja auch nit sei Methoden mit dem gleichen Namen in einer Klasse einbauen

Warum soll dass schlecht wartbar sein wenn du beides in einen Konstrucktor reinschreibst ?

 

[maki]

Warum soll dass schlecht wartbar sein wenn du beides in einen Konstrucktor reinschreibst ?

Redundanz, Code-Duplikation, die Wurzel fast allen übels....

 

[zero-2-one]

Danke für die Antworten, werd gleich noch ein bischen rumprobieren ob ich's so hinbekomme

@eicon11: man kann mehrere Konstruktoren, wie auch methoden mit dem gleichen namen haben (solange sie sich durch die übergebenen Variablentypen oder die Variablenanzahl eindeutig voneinander unterscheiden lassen)

und stell dir vor ich würde mir jetzt noch überlegen auch das ganze mit Double, Char,... machen zu wollen. Dann müsste ich überall im Konstruktor nochmal hinschreiben was ich eigentlich mit meinem int machen will. Wenn ich jetzt aufeinmal feststelle, dass ich aber irgendwann nochmehr mit dem int machen muss/will/wie auch immer, dann müsste ich in allen 4 oder nochmehr Konstruktoren was ändern - andernfalls nur in einem (auf den ich umleite).

 

[zero-2-one]

@ SlaterB:
Was du mit der parsemethode meinst ist mir klar - da mein Problem nicht sehr ausführlich ist werde ich das auch so machen

Aber könntest du mir kurz mit ein wenig quelltext zeigen wie ich meinen ersten Konstruktor ergänzen müsste, dass er bei der Übergabe eines falschen Typs eine Exception auslöst. Interessant wäre für mich dabei, wie ich dann auf die Exception reagieren kann (also rein syntaktisch). Also bisher ist geplant, dass beim auslösen einer Exception in eine Instanzvariable "ist keine Zahl" reingeschrieben wird.
Ich hab mich bisher nichnicht wirklich mit Exceptions befasst und wäre deshalb froh ein kleines Syntaxbeispiel zu haben.

Achja, und dann würde mich noch interessiern, warum du parsemethode statisch deklarieren würdest?

edit: ok, dass mit dem statischen hab ich gerade beim Kompilieren gemerkt... ich kann nicht auf die methode zugreifen, wenn der Konstruktor noch nicht abgearbeitet wurde, es sei denn sie ist static, oder? Dann habe ich aber das Problem, das ich im catch-Block (der sich jetzt in der parse befindet) nicht in meine Instanzvariable reinschreiben kann, was ja auch logisch ist. Naja, ich hoffe jetzt einfach doch noch auf ein throws exception Beispiel von dir

 

[SlaterB]

> ich kann nicht auf die methode zugreifen, wenn der Konstruktor noch nicht abgearbeitet wurde, es sei denn sie ist static, oder?

selbst wenn wäre es keine gute Idee, weil das Objekt in einem inkonsistenten Zustand ist,
zumal dürftest du zum Parsen nichts von dem (eh noch nicht ganz vorhandenen) Objekt brauchen, also sowieso eher statische Hilfsoperation

---------

> bei der Übergabe eines falschen Typs

die Typsicherheit in Java verhindert das, wenn du nicht gerade irgendwo Object-Parameter hast,
du meinst vielleicht die Übergabe eines falschen Strings,
wie gesagt kannst du nur in der parse-Methode ein try-catch schreiben,

wenn du dann erst im Konstruktor drauf reagieren willst wirds schwierig,
du könntest -1 oder sonst einen bestimmten Wert übergeben, um diese Information auszudrücken,
oder einen Integer, welcher zusätzlich noch null sein kann

 

[zero-2-one]

ok, das hab ich mir fast schon gedacht - schade eigentlich.

Aber das mit Integer und null als Fehlererkennung ist natürlich ne Möglichkeit.

Thx

 

[Gast]

man sollte immer statische factory methoden im hinterkopf behalten. die gestatten zum einen viel flexibilität, zum anderen haben sie den vorteil, benannt werden zu können.

class Foo
{
   public Foo( int i )
   {
      // irgendwas
   }

   public static Foo parseInt( final String str )
   {
        int i;
        // stell irgendwas tolles mit str an, prüfen, parsen etc.
        return new Foo( i );
   }
}

 

[Gast]

achso, und natürlich bieten diese statischen methoden auch den "vorteil", dass man zwecks einfacheren handlings z.b. intern ein NumberFormatException abfangen und stattdessen einfach null zurückgeben kann. für viele anwendungsfälle macht das code sehr viel übersichtlicher.

 

[zero-2-one]

Hab das jetzt auch mit ner statischen methode gelöst, allerdings hab ich meine Grundidee von int auf Integer umstellen müssen, um "null" als Ausnahmebedingung nutzen zu können. Naja, es läuft und ich bin glücklich und das mit der parsemethode ist ein angenehmes Standardmittel, das ich ab jetzt nutzen werde.

 public Zahlenausgabe(Integer x)
  {
    if (x == null)
    {
      this.wert = null;
      this.klartext = "ist keine Zahl";
    }
    else
    {
      this.wert = x;
      this.klartext = "";
      setKlartext();
    }
  }
  
  public Zahlenausgabe(String x)
  {
     this(parse(x));
  }
  
  private static Integer parse(String x)
  {
    Integer temp;
    try
    {
      temp = new Integer(x);
    }
    catch(Exception e)
    {
      temp = null;
    }
    return temp;
  }

Nochmal danke an die Unterstüzung von euch...[/quote]