Java supporta i valori dei parametri predefiniti?

Mi sono imbattuto in alcuni codici Java che avevano la seguente struttura:

public MyParameterizedFunction(String param1, int param2)
{
    this(param1, param2, false);
}

public MyParameterizedFunction(String param1, int param2, boolean param3)
{
    //use all three parameters here
}

So che in C ++ posso assegnare a un parametro un valore predefinito. Per esempio:

void MyParameterizedFunction(String param1, int param2, bool param3=false);

Java supporta questo tipo di sintassi? Ci sono dei motivi per cui è preferibile questa sintassi in due passaggi?

No, la struttura che hai trovato è come Java lo gestisce (vale a dire con sovraccarico invece di parametri predefiniti).

Per i costruttori, consultare il suggerimento dell'articolo 1 della Guida linguistica effettiva: programmazione 1 (considerare i metodi statici di fabbrica anziché i costruttori) se il sovraccarico si sta complicando. Per altri metodi, può essere utile rinominare alcuni casi o utilizzare un oggetto parametro. Questo è quando hai abbastanza complessità che la differenziazione è difficile. Un caso definito è quello in cui devi differenziare usando l'ordine dei parametri, non solo il numero e il tipo.

No, ma puoi usare il Builder Pattern , come descritto in questa risposta Stack Overflow .

Come descritto nella risposta collegata, il Builder Pattern ti consente di scrivere codice simile

Student s1 = new StudentBuilder().name("Eli").buildStudent();
Student s2 = new StudentBuilder()
                 .name("Spicoli")
                 .age(16)
                 .motto("Aloha, Mr Hand")
                 .buildStudent();

in cui alcuni campi possono avere valori predefiniti o essere facoltativi.

Esistono diversi modi per simulare i parametri predefiniti in Java:

1. Metodo sovraccarico.

   void foo(String a, Integer b) {
       //...
   }
   
   void foo(String a) {
       foo(a, 0); // here, 0 is a default value for b
   }
   
   foo("a", 2);
   foo("a");

   Una delle limitazioni di questo approccio è che non funziona se si hanno due parametri opzionali dello stesso tipo e uno qualsiasi di essi può essere omesso.

2. Varargs.

   a) Tutti i parametri opzionali sono dello stesso tipo:

   void foo(String a, Integer... b) {
       Integer b1 = b.length > 0 ? b[0] : 0;
       Integer b2 = b.length > 1 ? b[1] : 0;
       //...
   }
   
   foo("a");
   foo("a", 1, 2);

   b) I tipi di parametri opzionali possono essere diversi:

   void foo(String a, Object... b) {
       Integer b1 = 0;
       String b2 = "";
       if (b.length > 0) {
         if (!(b[0] instanceof Integer)) { 
             throw new IllegalArgumentException("...");
         }
         b1 = (Integer)b[0];
       }
       if (b.length > 1) {
           if (!(b[1] instanceof String)) { 
               throw new IllegalArgumentException("...");
           }
           b2 = (String)b[1];
           //...
       }
       //...
   }
   
   foo("a");
   foo("a", 1);
   foo("a", 1, "b2");

   Lo svantaggio principale di questo approccio è che se i parametri opzionali sono di tipi diversi si perde la verifica del tipo statico. Inoltre, se ogni parametro ha un significato diverso, è necessario un modo per distinguerli.

3. Null. Per affrontare i limiti degli approcci precedenti è possibile consentire valori null e quindi analizzare ogni parametro in un corpo del metodo:

   void foo(String a, Integer b, Integer c) {
       b = b != null ? b : 0;
       c = c != null ? c : 0;
       //...
   }
   
   foo("a", null, 2);

   Ora devono essere forniti tutti i valori degli argomenti, ma quelli predefiniti potrebbero essere nulli.

4. Classe opzionale. Questo approccio è simile ai null, ma utilizza la classe opzionale Java 8 per i parametri che hanno un valore predefinito:

   void foo(String a, Optional<Integer> bOpt) {
       Integer b = bOpt.isPresent() ? bOpt.get() : 0;
       //...
   }
   
   foo("a", Optional.of(2));
   foo("a", Optional.<Integer>absent());

   Facoltativo rende esplicito un contratto di metodo per un chiamante, tuttavia, è possibile trovare tale firma troppo dettagliata.

5. Modello del costruttore. Il modello builder viene utilizzato per i costruttori e viene implementato introducendo una classe Builder separata:

    class Foo {
        private final String a; 
        private final Integer b;
   
        Foo(String a, Integer b) {
          this.a = a;
          this.b = b;
        }
   
        //...
    }
   
    class FooBuilder {
      private String a = ""; 
      private Integer b = 0;
   
      FooBuilder setA(String a) {
        this.a = a;
        return this;
      }
   
      FooBuilder setB(Integer b) {
        this.b = b;
        return this;
      }
   
      Foo build() {
        return new Foo(a, b);
      }
    }
   
    Foo foo = new FooBuilder().setA("a").build();

6. Mappe. Quando il numero di parametri è troppo grande e per la maggior parte di essi vengono solitamente utilizzati valori predefiniti, è possibile passare argomenti del metodo come una mappa dei loro nomi / valori:

   void foo(Map<String, Object> parameters) {
       String a = ""; 
       Integer b = 0;
       if (parameters.containsKey("a")) { 
           if (!(parameters.get("a") instanceof Integer)) { 
               throw new IllegalArgumentException("...");
           }
           a = (String)parameters.get("a");
       } else if (parameters.containsKey("b")) { 
           //... 
       }
       //...
   }
   
   foo(ImmutableMap.<String, Object>of(
       "a", "a",
       "b", 2, 
       "d", "value")); 

Si noti che è possibile combinare uno di questi approcci per ottenere un risultato desiderabile.

Purtroppo no.

Sfortunatamente sì.

void MyParameterizedFunction(String param1, int param2, bool param3=false) {}

potrebbe essere scritto in Java 1.5 come:

void MyParameterizedFunction(String param1, int param2, Boolean... params) {
    assert params.length <= 1;
    bool param3 = params.length > 0 ? params[0].booleanValue() : false;
}

Ma se dovresti dipendere o meno da come ti senti riguardo al compilatore che genera un

new Boolean[]{}

per ogni chiamata.

Per più parametri predefinibili:

void MyParameterizedFunction(String param1, int param2, bool param3=false, int param4=42) {}

potrebbe essere scritto in Java 1.5 come:

void MyParameterizedFunction(String param1, int param2, Object... p) {
    int l = p.length;
    assert l <= 2;
    assert l < 1 || Boolean.class.isInstance(p[0]);
    assert l < 2 || Integer.class.isInstance(p[1]);
    bool param3 = l > 0 && p[0] != null ? ((Boolean)p[0]).booleanValue() : false;
    int param4 = l > 1 && p[1] != null ? ((Integer)p[1]).intValue() : 42;
}

Ciò corrisponde alla sintassi C ++, che consente solo i parametri predefiniti alla fine dell'elenco dei parametri.

Oltre alla sintassi, c'è una differenza in cui questo ha il controllo del tipo di tempo di esecuzione per i parametri predefiniti passati e il tipo C ++ li controlla durante la compilazione.

No, ma puoi emularli molto facilmente. Cosa c'era in C ++:

public: void myFunction(int a, int b=5, string c="test") { ... }

In Java, sarà una funzione sovraccarica:

public void myFunction(int a, int b, string c) { ... }

public void myFunction(int a, int b) {
    myFunction(a, b, "test");
}

public void myFunction(int a) {
    myFunction(a, 5);
}

In precedenza è stato menzionato che i parametri predefiniti hanno causato casi ambigui nel sovraccarico delle funzioni. Questo semplicemente non è vero, possiamo vedere nel caso del C ++: sì, forse può creare casi ambigui, ma questi problemi possono essere facilmente gestiti. Semplicemente non è stato sviluppato in Java, probabilmente perché i creatori volevano un linguaggio molto più semplice come lo era il C ++ - se avevano ragione, è un'altra domanda. Ma la maggior parte di noi non pensa che usi Java per la sua semplicità.

Puoi farlo in Scala, che gira su JVM ed è compatibile con i programmi Java. http://www.scala-lang.org/

vale a dire

class Foo(var prime: Boolean = false, val rib: String)  {}

No , ma il modo più semplice per implementarlo è:

public myParameterizedFunction(String param1, int param2, Boolean param3) {

    param3 = param3 == null ? false : param3;
}

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

o invece dell'operatore ternario , puoi usare if:

public myParameterizedFunction(String param1, int param2, Boolean param3) {

    if (param3 == null) {
        param3 = false;
    }
}

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

Potrei affermare l'ovvio qui, ma perché non implementare semplicemente il parametro "predefinito" da solo?

public class Foo() {
        public void func(String s){
                func(s, true);
        }
        public void func(String s, boolean b){
                //your code here
        }
}

per impostazione predefinita, dovresti usare entrambi

func("my string");

e se non desideri utilizzare il valore predefinito, lo utilizzeresti

func("my string", false);

Come è stato menzionato Scala, vale la pena menzionare anche Kotlin . Nella funzione di Kotlin anche i parametri possono avere valori predefiniti e possono anche fare riferimento ad altri parametri:

fun read(b: Array<Byte>, off: Int = 0, len: Int = b.size) {
    ...
}

Come Scala, Kotlin gira su JVM e può essere facilmente integrato in progetti Java esistenti.

No.

È possibile ottenere lo stesso comportamento passando un oggetto con valori predefiniti intelligenti. Ma di nuovo dipende dal tuo caso.

No. In generale Java non ha molto (alcun) zucchero sintattico, dal momento che hanno cercato di creare un linguaggio semplice.

Invece di usare:

void parameterizedMethod(String param1, int param2) {
    this(param1, param2, false);
}

void parameterizedMethod(String param1, int param2, boolean param3) {
    //use all three parameters here
}

È possibile utilizzare la funzionalità opzionale di Java utilizzando un solo metodo:

void parameterizedMethod(String param1, int param2, @Nullable Boolean param3) {
    param3 = Optional.ofNullable(param3).orElse(false);
    //use all three parameters here
}

La differenza principale è che è necessario utilizzare le classi wrapper anziché i tipi Java primitivi per consentire l' nullinput. Booleaninvece di boolean, Integerinvece di inte così via.

Non è supportato ma ci sono diverse opzioni come l'uso del pattern di oggetti parametro con un po 'di zucchero di sintassi:

public class Foo() {
    private static class ParameterObject {
        int param1 = 1;
        String param2 = "";
    }

    public static void main(String[] args) {
        new Foo().myMethod(new ParameterObject() {{ param1 = 10; param2 = "bar";}});
    }

    private void myMethod(ParameterObject po) {
    }
}

In questo esempio costruiamo ParameterObjectcon i valori predefiniti e li sovrascriviamo nella sezione di inizializzazione dell'istanza di classe{ param1 = 10; param2 = "bar";}

Prova questa soluzione:

public int getScore(int score, Integer... bonus)
{
    if(bonus.length > 0)
    {
        return score + bonus[0];
    }

    return score;
}

È possibile utilizzare Java Method Invocation Builder per generare automaticamente il builder con valori predefiniti.

Aggiungi @GenerateMethodInvocationBuilder alla classe o all'interfaccia e @Default ai parametri nei metodi in cui desideri i valori predefiniti. Un builder verrà generato al momento della compilazione, utilizzando i valori predefiniti specificati con le annotazioni.

@GenerateMethodInvocationBuilder
public class CarService {
 public CarService() {
 }

 public String getCarsByFilter(//
   @Default("Color.BLUE") Color color, //
   @Default("new ProductionYear(2001)") ProductionYear productionYear,//
   @Default("Tomas") String owner//
 ) {
  return "Filtering... " + color + productionYear + owner;
 }
}

E poi puoi invocare i metodi.

CarService instance = new CarService();
String carsByFilter = CarServiceGetCarsByFilterBuilder.getCarsByFilter()//
  .invoke(instance);

Oppure imposta uno dei valori predefiniti su qualcos'altro.

CarService instance = new CarService();
String carsByFilter = CarServiceGetCarsByFilterBuilder.getCarsByFilter()//
  .withColor(Color.YELLOW)//
  .invoke(instance);

Un approccio simile a https://stackoverflow.com/a/13864910/2323964 che funziona in Java 8 consiste nell'utilizzare un'interfaccia con getter predefiniti. Questo sarà più spazioso, ma è beffardo, ed è perfetto per quando hai un sacco di casi in cui vuoi attirare l'attenzione sui parametri.

public class Foo() {
    public interface Parameters {
        String getRequired();
        default int getOptionalInt(){ return 23; }
        default String getOptionalString(){ return "Skidoo"; }
    }

    public Foo(Parameters parameters){
        //...
    }

    public static void baz() {
        final Foo foo = new Foo(new Person() {
            @Override public String getRequired(){ return "blahblahblah"; }
            @Override public int getOptionalInt(){ return 43; }
        });
    }
}

Ho trascorso un bel po 'di tempo per capire come usarlo con metodi che restituiscono valori e finora non ho visto alcun esempio, ho pensato che potesse essere utile aggiungere questo qui:

int foo(int a) {
    // do something with a
    return a;
}

int foo() {
    return foo(0); // here, 0 is a default value for a
}

È così che l'ho fatto ... non è conveniente forse come avere un 'argomento opzionale' rispetto al parametro definito, ma ottiene il lavoro fatto:

public void postUserMessage(String s,boolean wipeClean)
{
    if(wipeClean)
    {
        userInformation.setText(s + "\n");
    }
    else
    {
        postUserMessage(s);
    }
}

public void postUserMessage(String s)
{
    userInformation.appendText(s + "\n");
}

Nota che posso invocare lo stesso nome di metodo con una sola stringa o posso invocarlo con una stringa e un valore booleano. In questo caso, l'impostazione di wipeClean su true sostituirà tutto il testo nel mio TextArea con la stringa fornita. L'impostazione di wipeClean su false o l'esclusione di tutti insieme aggiunge semplicemente il testo fornito a TextArea.

Nota anche che non sto ripetendo il codice nei due metodi, sto semplicemente aggiungendo la funzionalità di poter resettare TextArea creando un nuovo metodo con lo stesso nome solo con il booleano aggiunto.

In realtà penso che questo sia un po 'più pulito rispetto al fatto che Java fornisse un' argomento opzionale 'per i nostri parametri poiché dovremmo quindi codificare i valori predefiniti ecc. In questo esempio, non devo preoccuparmi di nulla. Sì, ho aggiunto un altro metodo alla mia classe, ma è più facile da leggere a lungo termine secondo la mia modesta opinione.

NO, ma abbiamo un'alternativa sotto forma di sovraccarico di funzioni.

chiamato quando nessun parametro è passato

void operation(){

int a = 0;
int b = 0;

} 

chiamato quando è stato passato un parametro "a"

void operation(int a){

int b = 0;
//code

} 

chiamato quando viene passato il parametro b

void operation(int a , int b){
//code
} 

Ci sono mezza dozzina o problemi migliori come questo, alla fine, arrivi al modello statico di fabbrica ... vedi l'API crypto per quello. Ordinamento difficile da spiegare, ma pensalo in questo modo: se hai un costruttore, predefinito o meno, l'unico modo per propagare lo stato oltre le parentesi graffe è o avere un valore booleano isValid; (insieme a null come valore predefinito v costruttore non riuscito) o genera un'eccezione che non è mai informativa quando viene recuperata dagli utenti sul campo.

Codice corretto, maledizione, scrivo migliaia di costruttori di linee e faccio ciò di cui ho bisogno. Trovo che usando isValid nella costruzione di oggetti - in altre parole, costruttori a due righe - ma per qualche ragione, sto migrando al modello statico di fabbrica. Sembra che tu possa fare molto se in una chiamata di metodo, ci sono ancora problemi di sincronizzazione () ma i valori predefiniti possono essere "sostituiti" meglio (più sicuri)

Penso che ciò che dobbiamo fare qui sia affrontare il problema di null come valore predefinito rispetto a qualcosa String one = new String (""); come variabile membro, quindi eseguendo un controllo per null prima di assegnare una stringa passata al costruttore.

Molto notevole la quantità di informatica grezza e stratosferica realizzata in Java.

C ++ e così via ha librerie del fornitore, sì. Java può superarli su server di grandi dimensioni grazie alla sua enorme cassetta degli attrezzi. Studia i blocchi di inizializzatori statici, resta con noi.

Non è supportato in Java come in altre lingue per esempio. Kotlin.

Puoi usare il seguente-

public void mop(Integer x) {
  // Define default values
        x = x == null ? 200 : x;
}