¿Java admite valores de parámetros predeterminados?

Encontré un código Java que tenía la siguiente estructura:

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

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

Sé que en C ++ puedo asignar a un parámetro un valor predeterminado. Por ejemplo:

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

¿Java admite este tipo de sintaxis? ¿Hay alguna razón por la cual esta sintaxis de dos pasos es preferible?

No, la estructura que encontró es cómo Java lo maneja (es decir, con sobrecarga en lugar de parámetros predeterminados).

Para los constructores, consulte Sugerencia del artículo 1 de Java eficaz: Guía del lenguaje de programación (considere métodos de fábrica estáticos en lugar de constructores) si la sobrecarga se complica. Para otros métodos, puede ser útil cambiar el nombre de algunos casos o usar un objeto de parámetro. Esto es cuando tienes suficiente complejidad que diferenciar es difícil. Un caso definitivo es donde debe diferenciarse utilizando el orden de los parámetros, no solo el número y el tipo.

No, pero puede usar el Patrón del generador , como se describe en esta respuesta de Desbordamiento de pila .

Como se describe en la respuesta vinculada, el Patrón del generador le permite escribir código como

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

en el que algunos campos pueden tener valores predeterminados o ser opcionales.

Hay varias formas de simular parámetros predeterminados en Java:

1. Método de sobrecarga.

   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 de las limitaciones de este enfoque es que no funciona si tiene dos parámetros opcionales del mismo tipo y cualquiera de ellos puede omitirse.

2. Varargs

   a) Todos los parámetros opcionales son del mismo 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) Los tipos de parámetros opcionales pueden ser diferentes:

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

   El principal inconveniente de este enfoque es que si los parámetros opcionales son de diferentes tipos, pierde la comprobación de tipo estático. Además, si cada parámetro tiene un significado diferente, necesita alguna forma de distinguirlos.

3. Nulos Para abordar las limitaciones de los enfoques anteriores, puede permitir valores nulos y luego analizar cada parámetro en un cuerpo de método:

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

   Ahora se deben proporcionar todos los valores de argumentos, pero los valores predeterminados pueden ser nulos.

4. Clase opcional Este enfoque es similar a los nulos, pero usa la clase Java 8 Opcional para parámetros que tienen un valor predeterminado:

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

   Opcional hace que un contrato de método sea explícito para una persona que llama, sin embargo, uno puede encontrar esa firma demasiado detallada.

5. Patrón de constructor. El patrón de constructor se utiliza para constructores y se implementa mediante la introducción de una clase de constructor separada:

    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. Mapas Cuando el número de parámetros es demasiado grande y para la mayoría de ellos se usan valores predeterminados, puede pasar argumentos de método como un mapa de sus nombres / valores:

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

Tenga en cuenta que puede combinar cualquiera de estos enfoques para lograr un resultado deseable.

Tristemente no.

Por desgracia sí.

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

podría escribirse en Java 1.5 como:

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

Pero si debe o no depender de cómo se siente acerca del compilador que genera un

new Boolean[]{}

para cada llamada

Para múltiples parámetros predeterminados:

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

podría escribirse en Java 1.5 como:

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

Esto coincide con la sintaxis de C ++, que solo permite parámetros predeterminados al final de la lista de parámetros.

Más allá de la sintaxis, existe una diferencia en la que esto ha llevado a cabo la comprobación del tipo de tiempo para los parámetros predeterminados pasados ​​y el tipo C ++ los verifica durante la compilación.

No, pero puedes emularlos muy fácilmente. Lo que en C ++ fue:

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

En Java, será una función sobrecargada:

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

Anteriormente se mencionó que los parámetros predeterminados causaron casos ambiguos en la sobrecarga de funciones. Eso simplemente no es cierto, podemos ver en el caso de C ++: sí, tal vez pueda crear casos ambiguos, pero estos problemas pueden manejarse fácilmente. Simplemente no se desarrolló en Java, probablemente porque los creadores querían un lenguaje mucho más simple como lo era C ++; si tenían razón, es otra pregunta. Pero la mayoría de nosotros no cree que use Java debido a su simplicidad.

Puede hacerlo en Scala, que se ejecuta en la JVM y es compatible con los programas Java. http://www.scala-lang.org/

es decir

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

No , pero la forma más sencilla de implementar esto es:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

o en lugar del operador ternario , puede usar if:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

Podría estar diciendo lo obvio aquí, pero ¿por qué no simplemente implementar el parámetro "predeterminado" usted mismo?

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

por defecto, usted usaría

func("my string");

y si no desea usar el predeterminado, usaría

func("my string", false);

Como se mencionó a Scala, Kotlin también vale la pena mencionar. En la función Kotlin, los parámetros también pueden tener valores predeterminados e incluso pueden referirse a otros parámetros:

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

Al igual que Scala, Kotlin se ejecuta en la JVM y puede integrarse fácilmente en proyectos Java existentes.

No.

Puede lograr el mismo comportamiento al pasar un objeto que tiene valores predeterminados inteligentes. Pero, de nuevo, depende de cuál sea su caso.

No. En general, Java no tiene mucho (ningún) azúcar sintáctico, ya que intentaron crear un lenguaje simple.

En lugar de usar:

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

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

Puede utilizar la funcionalidad opcional de Java al tener un único método:

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

La principal diferencia es que debe usar clases de envoltura en lugar de tipos Java primitivos para permitir la nullentrada. Booleanen lugar de boolean, en Integerlugar de inty así sucesivamente.

No es compatible, pero hay varias opciones, como usar el patrón de objeto de parámetro con algo de azúcar de sintaxis:

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

En este ejemplo construimos ParameterObjectcon valores predeterminados y los anulamos en la sección de inicialización de instancia de clase{ param1 = 10; param2 = "bar";}

Prueba esta solución:

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

    return score;
}

Puede usar Java Method Invocation Builder para generar automáticamente el generador con valores predeterminados.

Simplemente agregue @GenerateMethodInvocationBuilder a la clase o interfaz, y @Default a los parámetros en los métodos donde desea valores predeterminados. Se generará un generador en tiempo de compilación, utilizando los valores predeterminados que especificó con sus anotaciones.

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

Y luego puedes invocar los métodos.

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

O establezca cualquiera de los valores predeterminados en otra cosa.

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

Un enfoque similar a https://stackoverflow.com/a/13864910/2323964 que funciona en Java 8 es utilizar una interfaz con captadores predeterminados. Esto será más detallado en espacios en blanco, pero se puede burlar, y es ideal para cuando tienes un montón de instancias en las que realmente quieres llamar la atención sobre los parámetros.

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

Ahora he pasado bastante tiempo para descubrir cómo usar esto con métodos que devuelven valores, y hasta ahora no he visto ningún ejemplo, pensé que podría ser útil agregar esto aquí:

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

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

Así es como lo hice ... no es tan conveniente tal vez como tener un 'argumento opcional' contra su parámetro definido, pero hace el trabajo:

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

Observe que puedo invocar el mismo nombre de método con solo una cadena o puedo invocarlo con una cadena y un valor booleano. En este caso, establecer wipeClean en verdadero reemplazará todo el texto en mi TextArea con la cadena provista. Establecer wipeClean en falso o dejarlo todo junto simplemente agrega el texto proporcionado al TextArea.

También tenga en cuenta que no estoy repitiendo código en los dos métodos, simplemente estoy agregando la funcionalidad de poder restablecer TextArea creando un nuevo método con el mismo nombre solo con el booleano agregado.

De hecho, creo que esto es un poco más limpio que si Java proporcionara un 'argumento opcional' para nuestros parámetros, ya que tendríamos que codificar los valores predeterminados, etc. En este ejemplo, no necesito preocuparme por nada de eso. Sí, he agregado otro método a mi clase, pero a la larga es más fácil de leer en mi humilde opinión.

NO, pero tenemos una alternativa en forma de sobrecarga de funciones.

llamado cuando no pasó ningún parámetro

void operation(){

int a = 0;
int b = 0;

} 

llamado cuando se pasó el parámetro "a"

void operation(int a){

int b = 0;
//code

} 

llamado cuando pasa el parámetro b

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

Hay media docena o más problemas como este, eventualmente, llega al patrón de fábrica estático ... vea la API de cifrado para eso. Es difícil de explicar, pero piénselo de esta manera: si tiene un constructor, predeterminado o no, la única forma de propagar el estado más allá de las llaves es tener un Boolean isValid; (junto con el nulo como valor predeterminado v constructor fallido) o arroje una excepción que nunca sea informativa al recuperarlo de los usuarios de campo.

Código Correcto, maldita sea, escribo mil constructores de líneas y hago lo que necesito. Encuentro usar isValid en la construcción de objetos, en otras palabras, constructores de dos líneas, pero por alguna razón, estoy migrando al patrón estático de fábrica. Parece que puede hacer mucho si en una llamada al método, todavía hay problemas de sync (), pero los valores predeterminados se pueden 'sustituir' mejor (más seguro)

Creo que lo que tenemos que hacer aquí es abordar el problema de nulo como valor predeterminado frente a algo String one = new String (""); como una variable miembro, luego realiza una comprobación de nulo antes de asignar la cadena pasada al constructor.

Muy notable la cantidad de informática en bruto estratosférica realizada en Java.

C ++ y demás tiene librerías de proveedores, sí. Java puede superarlos en servidores a gran escala debido a que es una caja de herramientas masiva. Estudie los bloques de inicializador estático, quédese con nosotros.

No es compatible en Java como en otro idioma para ex. Kotlin

Puedes usar lo siguiente:

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