"Konstruktoraufruf muss die erste Anweisung in einem Konstruktor sein" Problem in Java [duplizieren]

8

Ich hätte gerne eine Konstruktorkette in Java. Zum Beispiel habe ich mit dem ersten Konstruktor eine Zeichenfolge als Parameter und rufe den zweiten Konstruktor auf, wenn ich ein Objekt aus der Parameterzeichenfolge erstelle.

%Vor%

Ich habe jedoch einen Fehler erhalten "Konstruktoraufruf muss die erste Anweisung in einem Konstruktor sein" -Fehler.

Ich habe einen gemeinsamen Code erstellt, der zwischen den beiden Konstruktoren geteilt wird, aber ich bin nicht sicher, dass dies die einzige Lösung ist, um das Problem zu umgehen.

%Vor%
  • Warum benötigt Java den Konstruktoraufruf als erste Anweisung? Was ist die Idee hinter dieser Anforderung?
  • Was ist die Konvention von Java für meinen Fall? Ist die aufrufende Methode ein guter Weg?
prosseek 28.12.2012, 16:25
quelle

4 Antworten

14

Es gibt keinen Grund, warum Java nicht erweitert werden könnte, um Anweisungen zuzulassen, die nicht auf this vor dem Konstruktor zugreifen. Dies würde jedoch die Sprachkomplexität erhöhen und den Code bei der Verwendung verschleiern (insbesondere wenn Sie annehmen, dass der Aufruf implizit ist).

Im Allgemeinen möchten Sie Konstruktoren so einfach wie möglich halten. init() Methoden sind eine schlechte Idee, da sie die Verwendung von final verhindern. Es scheint, dass der Code auf eine veränderbare statische Datei zugreift, was eine wirklich schlechte Idee ist.

Für Ihren spezifischen Code können Sie schreiben:

%Vor%

Ein allgemeinerer Hack ist das Aufrufen einer statischen Methode innerhalb des Aufrufs des Konstruktors:

%Vor%

Bearbeiten März 2018: In der Nachricht Datensätze: Konstruktion und Validierung Oracle schlägt vor, diese Einschränkung zu entfernen (aber im Gegensatz zu C # wird this definitiv nicht zugewiesen (DU) vor der Verkettung des Konstruktors).

  

Historisch muss dieses () oder super () zuerst in einem Konstruktor stehen. Dies   Einschränkung wurde nie populär und als willkürlich empfunden. Dort gab es   eine Reihe von subtilen Gründen, einschließlich der Überprüfung von   speziell, die zu dieser Einschränkung beigetragen haben. Über die Jahre,   Wir haben diese auf der VM-Ebene angesprochen, bis zu dem Punkt, an dem es wird   praktisch zu überlegen, diese Beschränkung aufzuheben, nicht nur für Aufzeichnungen,   aber für alle Konstruktoren.

    
Tom Hawtin - tackline 28.12.2012, 16:35
quelle
2

Lösung 1: Ihre Konstruktoren sollten einen gezielteren Fluss haben, um die Verwendung eines gemeinsamen init zu vermeiden. Ziemlich oft wird ein Konstruktor einfacher sein und ein komplettes gültiges Objekt konstruieren, dann kann der äußere Konstruktor dies dekorieren.

Lösung 2: Es ist oft eine gute Methode, eine statische Factory-Methode zu verwenden, die beispielsweise die benötigte Vorverarbeitung übernimmt. Das sieht nach einem guten Anwendungsfall für dieses Muster aus.

Lösung 3: Statt einer gemeinsamen init -Methode haben Sie nur statische Methoden, die die isolierte Vorverarbeitung für Sie erledigen. z.B. %Code%. Gewöhnliche myField = processInputField(myField) -Methoden spielen mit den letzten Feldern sehr schlecht, was ein stärkerer Grund ist, warum sie schlecht sind - im Wesentlichen ja, Konstruktoren sollten die gesamte Konstruktionsarbeit erledigen.

    
djechlin 28.12.2012 16:30
quelle
1

Siehe diese Antwort zu Ihrer ersten Frage wie für Ihre zweite Frage - ja es ist relativ akzeptiert, eine Art von init () -Methode für diese Fälle zu verwenden

    
radai 28.12.2012 16:31
quelle
0

Sehen Sie sich das an. Es könnte helfen, den Aufruf des Java-Aufrufers zu verstehen.

Der Konstruktoraufruf muss die erste Anweisung in einem Konstruktor sein

    
user1897705 28.12.2012 16:33
quelle

Tags und Links