Java prend-il en charge les valeurs de paramètres par défaut?

Je suis tombé sur du code Java qui avait la structure suivante:

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

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

Je sais qu'en C ++, je peux attribuer à un paramètre une valeur par défaut. Par exemple:

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

Java prend-il en charge ce type de syntaxe? Y a-t-il des raisons pour lesquelles cette syntaxe en deux étapes est préférable?

Non, la structure que vous avez trouvée est la façon dont Java la gère (c'est-à-dire avec surcharge au lieu des paramètres par défaut).

Pour les constructeurs, reportez -vous à Astuce 1 du Guide de langage de programmation efficace (Considérez les méthodes d'usine statiques au lieu des constructeurs) si la surcharge devient compliquée. Pour d'autres méthodes, renommer certains cas ou utiliser un objet paramètre peut aider. C'est lorsque vous avez suffisamment de complexité que la différenciation est difficile. Un cas précis est celui où vous devez différencier en utilisant l'ordre des paramètres, pas seulement le nombre et le type.

Non, mais vous pouvez utiliser le modèle de générateur , comme décrit dans cette réponse Stack Overflow .

Comme décrit dans la réponse liée, le modèle de générateur vous permet d'écrire du code comme

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

dans lequel certains champs peuvent avoir des valeurs par défaut ou être facultatifs.

Il existe plusieurs façons de simuler les paramètres par défaut en Java:

1. Surcharge de méthode.

   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");

   L'une des limites de cette approche est qu'elle ne fonctionne pas si vous avez deux paramètres facultatifs du même type et que l'un d'eux peut être omis.

2. Varargs.

   a) Tous les paramètres facultatifs sont du même type:

   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) Les types de paramètres facultatifs peuvent être différents:

   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");

   Le principal inconvénient de cette approche est que si les paramètres facultatifs sont de types différents, vous perdez la vérification de type statique. De plus, si chaque paramètre a une signification différente, vous avez besoin d'un moyen de les distinguer.

3. Nulls. Pour remédier aux limites des approches précédentes, vous pouvez autoriser les valeurs nulles, puis analyser chaque paramètre dans un corps de méthode:

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

   Maintenant, toutes les valeurs des arguments doivent être fournies, mais celles par défaut peuvent être nulles.

4. Classe facultative. Cette approche est similaire aux valeurs null, mais utilise la classe facultative Java 8 pour les paramètres qui ont une valeur par défaut:

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

   Facultatif rend explicite un contrat de méthode pour un appelant, cependant, on peut trouver une telle signature trop verbeuse.

5. Modèle de générateur.Le modèle de générateur est utilisé pour les constructeurs et est implémenté en introduisant une classe de générateur distincte:

    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. Plans.Lorsque le nombre de paramètres est trop important et que la plupart d'entre eux sont généralement utilisés par défaut, vous pouvez passer des arguments de méthode sous forme de mappage de leurs noms / valeurs:

   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")); 

Veuillez noter que vous pouvez combiner n'importe laquelle de ces approches pour obtenir un résultat souhaitable.

Malheureusement non.

Malheureusement oui.

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

pourrait être écrit en Java 1.5 comme:

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

Mais si vous devez ou non dépendre de ce que vous pensez du compilateur générant un

new Boolean[]{}

pour chaque appel.

Pour plusieurs paramètres par défaut:

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

pourrait être écrit en Java 1.5 comme:

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;
}

Cela correspond à la syntaxe C ++, qui autorise uniquement les paramètres par défaut à la fin de la liste des paramètres.

Au-delà de la syntaxe, il existe une différence dans le cas où le type d'exécution a vérifié les paramètres par défaut passés et le type C ++ les vérifie lors de la compilation.

Non, mais vous pouvez très facilement les émuler. Ce qui était en C ++ était:

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

En Java, ce sera une fonction surchargée:

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);
}

Plus tôt, il a été mentionné que les paramètres par défaut provoquaient des cas ambigus de surcharge de fonctions. Ce n'est tout simplement pas vrai, nous pouvons le voir dans le cas du C ++: oui, il peut peut-être créer des cas ambigus, mais ces problèmes peuvent être facilement traités. Il n'a tout simplement pas été développé en Java, probablement parce que les créateurs voulaient un langage beaucoup plus simple que le C ++ - s'ils avaient raison, c'est une autre question. Mais la plupart d'entre nous ne pensent pas qu'il utilise Java en raison de sa simplicité.

Vous pouvez le faire dans Scala, qui s'exécute sur la JVM et est compatible avec les programmes Java. http://www.scala-lang.org/

c'est à dire

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

Non , mais la façon la plus simple de mettre en œuvre ceci est:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

ou au lieu de l' opérateur ternaire , vous pouvez utiliser if:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

Je dirais peut-être l'évidence ici, mais pourquoi ne pas simplement implémenter le paramètre "par défaut" vous-même?

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

pour la valeur par défaut, vous utiliserez soit

func("my string");

et si vous ne souhaitez pas utiliser la valeur par défaut, vous utiliserez

func("my string", false);

Comme Scala a été mentionné, Kotlin mérite également d'être mentionné. Dans la fonction Kotlin, les paramètres peuvent également avoir des valeurs par défaut et ils peuvent même faire référence à d'autres paramètres:

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

Comme Scala, Kotlin fonctionne sur la JVM et peut être facilement intégré dans des projets Java existants.

Non.

Vous pouvez obtenir le même comportement en passant un objet qui a des valeurs par défaut intelligentes. Mais encore une fois, cela dépend de votre cas.

Non. En général, Java n'a pas (beaucoup) de sucre syntaxique, car ils ont essayé de créer un langage simple.

À la place d'utiliser:

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

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

Vous pouvez utiliser la fonctionnalité facultative de java en ayant une seule méthode:

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

La principale différence est que vous devez utiliser des classes wrapper au lieu de types Java primitifs pour autoriser l' nullentrée. Booleanau lieu de boolean, Integerau lieu de intet ainsi de suite.

Il n'est pas pris en charge mais il existe plusieurs options comme l'utilisation d'un modèle d'objet de paramètre avec du sucre de syntaxe:

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) {
    }
}

Dans cet exemple, nous construisons ParameterObjectavec des valeurs par défaut et les remplaçons dans la section d'initialisation d'instance de classe{ param1 = 10; param2 = "bar";}

Essayez cette solution:

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

    return score;
}

Vous pouvez utiliser Java Method Invocation Builder le générateur d' pour générer automatiquement le générateur avec des valeurs par défaut.

Ajoutez simplement @GenerateMethodInvocationBuilder à la classe ou à l'interface et le @Default aux paramètres dans les méthodes où vous souhaitez des valeurs par défaut. Un générateur sera généré au moment de la compilation, en utilisant les valeurs par défaut que vous avez spécifiées avec vos annotations.

@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;
 }
}

Et puis vous pouvez invoquer les méthodes.

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

Ou définissez l'une des valeurs par défaut sur autre chose.

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

Une approche similaire à https://stackoverflow.com/a/13864910/2323964 qui fonctionne dans Java 8 consiste à utiliser une interface avec des getters par défaut. Ce sera plus d'espaces verbeux, mais est moquable, et c'est génial lorsque vous avez un tas d'instances où vous voulez réellement attirer l'attention sur les paramètres.

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; }
        });
    }
}

J'ai maintenant passé pas mal de temps à comprendre comment utiliser cela avec des méthodes qui retournent des valeurs, et je n'ai vu aucun exemple jusqu'à présent, j'ai pensé qu'il pourrait être utile d'ajouter ceci ici:

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

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

Voici comment je l'ai fait ... ce n'est peut-être pas aussi pratique que d'avoir un `` argument facultatif '' contre votre paramètre défini, mais cela fait le travail:

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");
}

Remarquez que je peux invoquer le même nom de méthode avec juste une chaîne ou que je peux l'invoquer avec une chaîne et une valeur booléenne. Dans ce cas, définir wipeClean sur true remplacera tout le texte de mon TextArea par la chaîne fournie. Définir wipeClean sur false ou le laisser de côté tout simplement ajoute le texte fourni à TextArea.

Notez également que je ne répète pas le code dans les deux méthodes, j'ajoute simplement la fonctionnalité de pouvoir réinitialiser le TextArea en créant une nouvelle méthode avec le même nom uniquement avec le booléen ajouté.

En fait, je pense que c'est un peu plus propre que si Java fournissait un «argument facultatif» pour nos paramètres, car nous aurions alors besoin de coder pour les valeurs par défaut, etc. Dans cet exemple, je n'ai pas à me soucier de tout cela. Oui, j'ai ajouté une autre méthode à ma classe, mais c'est plus facile à lire à long terme à mon humble avis.

NON, mais nous avons une alternative sous la forme d'une surcharge de fonction.

appelé quand aucun paramètre n'est passé

void operation(){

int a = 0;
int b = 0;

} 

appelé lorsqu'un paramètre "a" a été transmis

void operation(int a){

int b = 0;
//code

} 

appelé lorsque le paramètre b est passé

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

Il y a une demi-douzaine ou mieux de problèmes comme celui-ci, finalement, vous arrivez au modèle d'usine statique ... consultez l'API crypto pour cela. Trier difficile à expliquer, mais pensez-y de cette façon: si vous avez un constructeur, par défaut ou autre, la seule façon de propager l'état au-delà des accolades est soit d'avoir un isValid booléen; (avec le null comme valeur par défaut v constructeur échoué) ou lève une exception qui n'est jamais informative lors du retour des utilisateurs sur le terrain.

Code correct, bon sang, j'écris des milliers de constructeurs de lignes et je fais ce dont j'ai besoin. Je trouve que l'utilisation d'isValid dans la construction d'objets - en d'autres termes, les constructeurs à deux lignes - mais pour une raison quelconque, je migre vers le modèle d'usine statique. Il me semble que vous pouvez faire beaucoup de choses si vous dans un appel de méthode, il y a toujours des problèmes de synchronisation () mais les valeurs par défaut peuvent être mieux "substituées" (plus sûres)

Je pense que ce que nous devons faire ici est de résoudre le problème de null comme valeur par défaut vis-à-vis de quelque chose String one = new String (""); en tant que variable membre, puis en vérifiant la valeur null avant d'attribuer la chaîne passée au constructeur.

Très remarquable la quantité d'informatique brute et stratosphérique réalisée à Java.

C ++ et ainsi de suite a des bibliothèques de fournisseurs, oui. Java peut les distancer sur des serveurs à grande échelle car il s'agit d'une énorme boîte à outils. Étudiez les blocs d'initialisation statiques, restez avec nous.

Il n'est pas pris en charge en java comme dans d'autres langues par exemple. Kotlin.

Vous pouvez utiliser les éléments suivants-

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