Optionaler Parameter bei Methode, der nur optional ist?

[internet]

Hallo,

ich verwende einen Methodenaufruf einige 100 Mal in meinem Projekt.
Nun möchte ich einen zusätzlichen Parameter der Methode hinzufügen.

Das kann ich natürlich machen, aber dann muss ich auch bei 100 Stellen den Aufruf der Methode anpassen mit dem zusätzlichen Parameter.
Ich will das erst mal bei 20 Aufrufen ändern, sodass ich den Aufruf um den weiteren Parameter erweitere...

Gibt es denn eine Möglichkeit, dass ich einen weiteren Parameter der Methode hinzufüge, der bpsw. default - mäßig auf "true" ist?
Und ich dann innerhalb der Methode eben das Feld prüfe.

Andernfalls erstelle ich eben die gleiche Methode mit einem erweiterten Parameter und rufe diese dann bei den 20 Aufrufen auf - aber vllt. gibt es ja eine andere Möglichkeit?

Danke

 

[httpdigest]

In Java gibt es keine Parameter mit optionalem Default-Wert wie z.B. bei C++.
Du kannst hier, wie du schon sagtest, eine weitere Methode mit demselben Namen und demselben Rückgabetyp wie deine bisherige Methode, aber einem weiteren Parameter, anlegen, also diese Methode *überladen*.
Wenn irgendwann immer mehr und mehr optionale Parameter hinzukommen könnten, ist es auch nicht unüblich, ein Parameter-Objekt als einzigen Parameter der Methode zu verwenden. Also eine neue Klasse, die alle möglichen Parameter als Instanzvariablen enthält und optionale Parameter z.B. mit einem vorinitialisierten Instanzfeld-Wert belegt.
Alle required Parameter könntest du z.B. über einen Konstruktor dieser Parameterobjekt-Klasse setzen lassen.
Das geht dann schon in Richtung Builder-Pattern.

 

[internet]

Ok, schade - aber das beantwortet ja meine Frage
Vielen Dank

 

[fhoffmann]

Ok, schade

Aber so schlimm ist das ja nicht.
Wenn du bisher hattest:

tuWas(String bisherigeParameter) {
    // bisheriger Code
}

dann schreibst du nun:

tuWas(String bisherigeParameter) {
    tuWas(bisherigeParameter, true);
}

tuWas(String bisherigeParameter, boolean neuerParameter) {
    // bisheriger Code, den du auf den neuen Parameter anpassen kannst
}

Weil diese Änderung so einfach ist, hat man wahrscheinlich bei der Erfindung von Java auch beschlossen, keine Default-Parameter einzuführen.

 

[Neumi5694]

Anders machen's andere Sprachen ja auch nicht. Der kompilierte Code schaut bei denen nicht anders aus als wenn du in Java einfach 2 Methoden anlegst.
Es gibt allerdings eine Möglichkeit, ein Array optional anzugeben.

void  myMethod(int a, String s1, String... array) {
}

//Kann so aufgerufen werden.
void myCaller() {
    myMethod(14,"Hallo",new String[] {"Spencer","Wie","Geht's"}); //klassisch, wenn ein 'echtes' Array erwartet würde.
    myMethod(14,"Hallo","Spencer","Wie","Geht's"); //entspricht der oberen Zeile, aber ohne Array-Wrapper
    myMethod(14,"Hallo"); //erzeugt ein leeres Array.
}

Über den Aufruf in der ersten Zeile ist es möglich, ein null-Array zu übergeben, aber so gemein muss man schon sein wollen.
Ansonsten kann man sich in der Methode darauf verlassen, immer ein array ungleich null zu erhalten, das eben die Länge 0 hat, wenn keine Parameter angegeben wurden.

Man kann nur ein optionales Array angeben und es muss im Header an der letzten Stelle stehen.

 

[Neumi5694]

Persönlich finde ich die Überladung mit erzwungener Aufteilung auf 2 Methoden übrigens besser als optionale Parameter. Man weiß immer sehr genau, was man da eigentlich macht und jede Methode ist eindeutig identifizierbar.
Stell dir mal vor, Java würde das unterstützen.

//Pseudocode
void myMethod(optional int optionalParameter 14) {
 
}

void myMethod() {
}

void caller() {
    //welche der Methoden würde hier aufgerufen? Die ohne Parameter oder die mit optionalem Parameter?
    myMethod();
}

Das Gedankenspiel kann man noch an die Spitze treiben, wenn man von mehreren optionalen Parametern ausgeht

//Pseudocode
void myMethod(optional int optionA 14, optional int optionB 15) {
}
void caller() {
   myMethod(17); // und nu? Welcher der beiden Werte wird gesetzt?
}

Ich denke, der Verzicht darauf war eine sehr bewusste Entscheidung zu Gunsten der Überladungen, nicht nur eine quick&dirty Lösung.

 

[httpdigest]

Wobei ich fast behaupten würde, dass das Überladen von Methoden weniger dem Zweck dient, optionale Parameter einzuführen, sondern vielmehr "Adhoc-Polymorphismus" zu erlauben, also Methoden in ihrem Verhalten zu überladen basierend auf dem Parametertyp.
Z.B. eine append(int) Methode und eine append(String) Methode auf einem StringBuilder.
Die exzessive Verwendung von Methodenüberladung für mehr optionale Parameter würde ich genauso als Anti-Pattern sehen wie beim "Telescoping Constructor" Anti-Pattern.