O Java suporta valores de parâmetro padrão?

Me deparei com algum código Java que tinha a seguinte estrutura:

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

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

Eu sei que em C ++ posso atribuir um parâmetro a um valor padrão. Por exemplo:

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

O Java suporta esse tipo de sintaxe? Existem razões pelas quais essa sintaxe de duas etapas é preferível?

Não, a estrutura que você encontrou é como o Java lida com isso (ou seja, com sobrecarga em vez de parâmetros padrão).

Para construtores, consulte Dica do Item 1 do Java Efetivo: Guia da Linguagem de Programação (Considere métodos estáticos de fábrica em vez de construtores) se a sobrecarga estiver ficando complicada. Para outros métodos, renomear alguns casos ou usar um objeto de parâmetro pode ajudar. É quando você tem complexidade suficiente que diferenciar é difícil. Um caso definido é onde você deve diferenciar usando a ordem dos parâmetros, não apenas o número e o tipo.

Não, mas você pode usar o Padrão do Construtor , conforme descrito nesta resposta do estouro de pilha .

Conforme descrito na resposta vinculada, o Builder Pattern permite escrever código como

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

em que alguns campos podem ter valores padrão ou serem opcionais.

Existem várias maneiras de simular parâmetros padrão em Java:

1. Sobrecarga de método.

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

   Uma das limitações dessa abordagem é que ela não funcionará se você tiver dois parâmetros opcionais do mesmo tipo e qualquer um deles puder ser omitido.

2. Varargs.

   a) Todos os parâmetros opcionais são do mesmo 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) Os tipos de parâmetros opcionais podem 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");

   A principal desvantagem dessa abordagem é que, se os parâmetros opcionais forem de tipos diferentes, você perderá a verificação de tipo estático. Além disso, se cada parâmetro tiver um significado diferente, você precisará de alguma maneira de distingui-lo.

3. Nulos. Para abordar as limitações das abordagens anteriores, você pode permitir valores nulos e, em seguida, analisar cada parâmetro em um corpo 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);

   Agora todos os valores dos argumentos devem ser fornecidos, mas os padrão podem ser nulos.

4. Classe opcional. Essa abordagem é semelhante a nulos, mas usa a classe Java 8 Optional para parâmetros que possuem um valor padrão:

   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 torna um contrato de método explícito para um chamador, no entanto, pode-se achar essa assinatura muito detalhada.

5. Padrão do construtor. O padrão do construtor é usado para construtores e é implementado através da introdução de uma classe Builder 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. Maps. Quando o número de parâmetros é muito grande e, para a maioria deles, os valores padrão geralmente são usados, você pode passar argumentos de método como um mapa de seus nomes / 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")); 

Observe que você pode combinar qualquer uma dessas abordagens para obter um resultado desejável.

Infelizmente não.

Infelizmente sim.

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

pode ser escrito em 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;
}

Mas se você deve ou não depender de como se sente sobre o compilador gerar um

new Boolean[]{}

para cada chamada.

Para vários parâmetros padrão:

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

pode ser escrito em 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;
}

Isso corresponde à sintaxe do C ++, que permite apenas parâmetros padrão no final da lista de parâmetros.

Além da sintaxe, há uma diferença em que isso verifica o tipo de tempo de execução para parâmetros padrão passados ​​e o tipo C ++ os verifica durante a compilação.

Não, mas você pode facilmente imitá-los. O que em C ++ foi:

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

Em Java, será uma função sobrecarregada:

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

Mencionado anteriormente, os parâmetros padrão causaram casos ambíguos na sobrecarga de funções. Isso simplesmente não é verdade, podemos ver no caso do C ++: sim, talvez ele possa criar casos ambíguos, mas esses problemas podem ser facilmente tratados. Simplesmente não foi desenvolvido em Java, provavelmente porque os criadores queriam uma linguagem muito mais simples como o C ++ - se eles tivessem razão, é outra questão. Mas a maioria de nós não acha que ele usa Java devido à sua simplicidade.

Você pode fazer isso no Scala, que é executado na JVM e é compatível com os programas Java. http://www.scala-lang.org/

ie

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

Não , mas a maneira mais simples de implementar isso é:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

ou em vez do operador ternário , você pode 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);
}

Eu posso estar afirmando o óbvio aqui, mas por que não simplesmente implementar você mesmo o parâmetro "padrão"?

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

para o padrão, você usaria

func("my string");

e se você não gostaria de usar o padrão, usaria

func("my string", false);

Como Scala foi mencionado, Kotlin também merece ser mencionado. Na função Kotlin, os parâmetros também podem ter valores padrão e podem até se referir a outros parâmetros:

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

Como o Scala, o Kotlin é executado na JVM e pode ser facilmente integrado aos projetos Java existentes.

Não.

Você pode obter o mesmo comportamento passando um objeto com padrões inteligentes. Mas, novamente, depende de qual é o seu caso.

Não. Em geral, o Java não possui muito (nenhum) açúcar sintático, pois eles tentaram criar uma linguagem simples.

Ao invés 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
}

Você pode utilizar a funcionalidade opcional do java tendo um único método:

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

A principal diferença é que você deve usar classes de wrapper em vez de tipos Java primitivos para permitir nullentrada. Booleanem vez de boolean, em Integervez de inte assim por diante.

Não é suportado, mas existem várias opções, como o uso de padrão de objeto de parâmetro com algum açúcar de sintaxe:

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

Nesta amostra, construímos ParameterObjectcom valores padrão e os substituímos na seção de inicialização da instância de classe{ param1 = 10; param2 = "bar";}

Experimente esta solução:

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

    return score;
}

Você pode usar o Java Method Invocation Builder para gerar automaticamente o construtor com valores padrão.

Basta adicionar @GenerateMethodInvocationBuilder à classe ou interface e o @Default aos parâmetros nos métodos em que você deseja valores padrão. Um construtor será gerado em tempo de compilação, usando os valores padrão que você especificou com suas anotações.

@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 então você pode invocar os métodos.

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

Ou defina qualquer um dos valores padrão para outra coisa.

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

Uma abordagem semelhante a https://stackoverflow.com/a/13864910/2323964 que funciona no Java 8 é usar uma interface com getters padrão. Isso será mais amplo em branco, mas é ridículo, e é ótimo para quando você tem várias instâncias em que deseja chamar a atenção para os 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; }
        });
    }
}

Agora dediquei algum tempo para descobrir como usá-lo com métodos que retornam valores, e ainda não vi nenhum exemplo até agora, achei que seria útil adicionar isso aqui:

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

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

Foi assim que eu fiz ... não é tão conveniente, talvez, ter um 'argumento opcional' contra o seu parâmetro definido, mas ele faz o trabalho:

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 eu posso invocar o mesmo nome de método com apenas uma string ou com uma string e um valor booleano. Nesse caso, definir wipeClean como true substituirá todo o texto em minha TextArea pela string fornecida. Definir o wipeClean como false ou deixar de fora todos juntos simplesmente anexa o texto fornecido à TextArea.

Observe também que não estou repetindo o código nos dois métodos, apenas adicionando a funcionalidade de poder redefinir a TextArea criando um novo método com o mesmo nome apenas com o booleano adicionado.

Na verdade, acho que isso é um pouco mais limpo do que se o Java fornecesse um 'argumento opcional' para nossos parâmetros, já que precisaríamos codificar valores padrão etc. Nesse exemplo, não preciso me preocupar com nada disso. Sim, adicionei outro método à minha turma, mas é mais fácil ler a longo prazo na minha humilde opinião.

NÃO, mas temos alternativas na forma de sobrecarga de função.

chamado quando nenhum parâmetro passou

void operation(){

int a = 0;
int b = 0;

} 

chamado quando "a" parâmetro foi passado

void operation(int a){

int b = 0;
//code

} 

chamado quando o parâmetro b passou

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

Existem meia dúzia ou mais de problemas como esse; eventualmente, você chega ao padrão estático de fábrica ... veja a API de criptografia para isso. É difícil explicar, mas pense da seguinte maneira: se você tem um construtor, padrão ou não, a única maneira de propagar o estado além dos chavetas é ter um Boolean isValid; (junto com o valor nulo como padrão v com falha no construtor) ou lança uma exceção que nunca é informativa ao recuperá-la dos usuários de campo.

Código correto, caramba, escrevo milhares de construtores de linha e faço o que preciso. Acho que usando isValid na construção de objetos - em outras palavras, construtores de duas linhas - mas, por algum motivo, estou migrando para o padrão de fábrica estático. Parece que você pode fazer muito se estiver em uma chamada de método, ainda há problemas de sync (), mas os padrões podem ser 'substituídos' melhor (mais seguro)

Eu acho que o que precisamos fazer aqui é resolver a questão de nulo como valor padrão em relação a algo String one = new String (""); como uma variável membro, em seguida, verifique nulo antes de atribuir a sequência passada ao construtor.

Muito notável a quantidade de ciência da computação estratosférica bruta feita em Java.

C ++ e assim por diante tem bibliotecas de fornecedores, sim. O Java pode superá-los em servidores de grande escala devido à sua enorme caixa de ferramentas. Estude os blocos estáticos do inicializador, fique conosco.

Não é suportado em java como em outro idioma para ex. Kotlin.

Você pode usar o seguinte-

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