Czy Java obsługuje domyślne wartości parametrów?

Natknąłem się na kod Java, który miał następującą strukturę:

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

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

Wiem, że w C ++ mogę przypisać parametrowi wartość domyślną. Na przykład:

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

Czy Java obsługuje taką składnię? Czy są jakieś powody, dla których ta dwustopniowa składnia jest lepsza?

Nie, struktura, którą znalazłeś, to sposób, w jaki Java ją obsługuje (to znaczy z przeciążeniem zamiast parametrów domyślnych).

W przypadku konstruktorów zobacz Poradnik dla efektywnego języka Java: Podręcznik programowania w języku 1 (rozważ konstruktor statycznych metod fabrycznych zamiast konstruktorów), jeśli przeciążenie staje się skomplikowane. W przypadku innych metod pomocne może być zmiana nazwy niektórych przypadków lub użycie obiektu parametru. To wtedy masz wystarczająco złożoność, że odróżnienie jest trudne. Zdecydowanym przypadkiem jest rozróżnienie przy użyciu kolejności parametrów, a nie tylko liczby i typu.

Nie, ale możesz użyć Wzorca konstruktora , jak opisano w odpowiedzi na Przepełnienie stosu .

Jak opisano w połączonej odpowiedzi, wzorzec konstruktora umożliwia pisanie kodu podobnego

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

w których niektóre pola mogą mieć wartości domyślne lub być opcjonalne.

Istnieje kilka sposobów symulacji domyślnych parametrów w Javie:

1. Przeciążenie metody.

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

   Jednym z ograniczeń tego podejścia jest to, że nie działa, jeśli masz dwa opcjonalne parametry tego samego typu, a każdy z nich można pominąć.

2. Varargs.

   a) Wszystkie parametry opcjonalne są tego samego typu:

   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) Rodzaje parametrów opcjonalnych mogą być różne:

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

   Główną wadą tego podejścia jest to, że jeśli parametry opcjonalne są różnych typów, tracisz sprawdzanie typu statycznego. Ponadto, jeśli każdy parametr ma inne znaczenie, potrzebujesz sposobu na ich rozróżnienie.

3. Zero Aby rozwiązać ograniczenia poprzednich podejść, możesz zezwolić na wartości zerowe, a następnie przeanalizować każdy parametr w treści metody:

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

   Teraz należy podać wszystkie wartości argumentów, ale wartości domyślne mogą być zerowe.

4. Klasa fakultatywna To podejście jest podobne do wartości zerowych, ale wykorzystuje klasę opcjonalną Java 8 dla parametrów o wartości domyślnej:

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

   Opcjonalne sprawia, że ​​metoda dzwoniąca jest jawna dla osoby dzwoniącej, jednak taki podpis może okazać się zbyt szczegółowy.

5. Wzór konstruktora. Wzorzec konstruktora jest używany dla konstruktorów i jest implementowany przez wprowadzenie oddzielnej klasy konstruktora:

    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. Mapy Gdy liczba parametrów jest zbyt duża i dla większości z nich zwykle używane są wartości domyślne, możesz przekazać argumenty metody jako mapę ich nazw / wartości:

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

Pamiętaj, że możesz połączyć dowolne z tych podejść, aby osiągnąć pożądany rezultat.

Niestety nie.

Niestety tak.

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

można napisać w Javie 1.5 jako:

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

Ale czy powinieneś polegać na tym, jak się czujesz na temat generowania kompilatora

new Boolean[]{}

dla każdego połączenia.

W przypadku wielu parametrów domyślnych:

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

można napisać w Javie 1.5 jako:

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

Jest to zgodne ze składnią C ++, która dopuszcza parametry domyślne tylko na końcu listy parametrów.

Poza składnią istnieje różnica w tym, że ma to sprawdzanie typu w czasie wykonywania pod kątem parametrów domyślnych, a typ C ++ sprawdza je podczas kompilacji.

Nie, ale możesz bardzo łatwo je emulować. Co w C ++ było:

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

W Javie będzie to funkcja przeciążona:

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

Wcześniej wspomniano, że domyślne parametry powodowały niejednoznaczne przypadki przeciążenia funkcji. To po prostu nieprawda, widzimy w przypadku C ++: tak, może może tworzyć niejednoznaczne przypadki, ale problem ten można łatwo rozwiązać. Po prostu nie został opracowany w Javie, prawdopodobnie dlatego, że twórcy chcieli znacznie prostszego języka, jakim był C ++ - jeśli mieli rację, to kolejne pytanie. Ale większość z nas nie uważa, że ​​używa Javy ze względu na jej prostotę.

Możesz to zrobić w Scali, która działa na JVM i jest kompatybilna z programami Java. http://www.scala-lang.org/

to znaczy

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

Nie , ale najprostszym sposobem na wdrożenie tego jest:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

lub zamiast operatora trójskładnikowego możesz użyć if:

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

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

public myParameterizedFunction(String param1, int param2) {

    this(param1, param2, false);
}

Być może stwierdzam tu oczywistość, ale dlaczego po prostu nie wdrożyć parametru „domyślnego”?

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

domyślnie użyłbyś albo

func("my string");

a jeśli nie chcesz używać domyślnej, skorzystasz

func("my string", false);

Jak wspomniano Scalę, Kotlin również jest wart wspomnienia. W funkcji Kotlin parametry mogą mieć również wartości domyślne, a nawet mogą odnosić się do innych parametrów:

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

Podobnie jak Scala, Kotlin działa na JVM i może być łatwo zintegrowany z istniejącymi projektami Java.

Nie.

Możesz osiągnąć to samo zachowanie, przekazując obiekt, który ma inteligentne ustawienia domyślne. Ale znowu to zależy od tego, co masz pod ręką.

Nie. Ogólnie Java nie ma dużo (żadnego) cukru syntaktycznego, ponieważ próbowali stworzyć prosty język.

Zamiast używać:

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

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

Możesz skorzystać z opcjonalnej funkcjonalności java, mając jedną metodę:

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

Główną różnicą jest to, że musisz używać klas opakowań zamiast pierwotnych typów Java, aby umożliwić nullwprowadzanie danych. Booleanzamiast boolean, Integerzamiast inti tak dalej.

To nie jest obsługiwane, ale istnieje kilka opcji, takich jak użycie wzorca obiektu parametru z odrobiną cukru składniowego:

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

W tym przykładzie konstruujemy ParameterObjectwartości domyślne i zastępujemy je w sekcji inicjalizacji instancji klasy{ param1 = 10; param2 = "bar";}

Wypróbuj to rozwiązanie:

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

    return score;
}

Możesz użyć Java Method Invocation Builder, aby automatycznie wygenerować builder z wartościami domyślnymi.

Po prostu dodaj @GenerateMethodInvocationBuilder do klasy lub interfejsu, a @Default do parametrów w metodach, w których chcesz mieć wartości domyślne. Konstruktor zostanie wygenerowany w czasie kompilacji przy użyciu wartości domyślnych określonych w adnotacjach.

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

Następnie możesz wywołać metody.

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

Lub ustaw dowolną z wartości domyślnych na coś innego.

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

Podobne podejście do https://stackoverflow.com/a/13864910/2323964, które działa w Javie 8, polega na użyciu interfejsu z domyślnymi modułami pobierającymi. Będzie to bardziej szczegółowe białe znaki, ale można z niego wyśmiewać i jest to świetne, gdy masz kilka przypadków, w których naprawdę chcesz zwrócić uwagę na parametry.

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

Spędziłem teraz trochę czasu, aby dowiedzieć się, jak tego używać z metodami, które zwracają wartości, i jak dotąd nie widziałem żadnych przykładów, pomyślałem, że przydatne może być dodanie tego tutaj:

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

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

Tak to zrobiłem ... być może nie jest to tak wygodne jak „opcjonalny argument” przeciwko zdefiniowanemu parametrowi, ale wykonuje zadanie:

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

Zauważ, że mogę wywołać tę samą nazwę metody za pomocą tylko łańcucha lub mogę wywołać ją za pomocą łańcucha i wartości logicznej. W takim przypadku ustawienie wipeClean na true spowoduje zastąpienie całego tekstu w moim obiekcie TextArea podanym ciągiem. Ustawienie wipeClean na false lub pomijanie go razem powoduje dołączenie dostarczonego tekstu do TextArea.

Zauważ też, że nie powtarzam kodu w dwóch metodach, po prostu dodaję funkcję resetowania TextArea, tworząc nową metodę o tej samej nazwie tylko z dodaną wartością logiczną.

Myślę, że jest to trochę czystsze niż gdyby Java podała „opcjonalny argument” dla naszych parametrów, ponieważ musielibyśmy wtedy kodować wartości domyślne itp. W tym przykładzie nie muszę się tym martwić. Tak, dodałem jeszcze jedną metodę do mojej klasy, ale na dłuższą metę łatwiej jest ją czytać, moim skromnym zdaniem.

NIE, Ale mamy alternatywę w postaci przeciążenia funkcji.

wywoływany, gdy nie przekazano żadnego parametru

void operation(){

int a = 0;
int b = 0;

} 

wywoływane, gdy parametr „a” został przekazany

void operation(int a){

int b = 0;
//code

} 

wywoływane, gdy parametr b minie

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

Istnieje pół tuzina lub lepszych problemów, takich jak ten, w końcu dochodzisz do statycznego wzorca fabrycznego ... zobacz o tym API kryptograficzne. Sortuj trudne do wyjaśnienia, ale pomyśl o tym w ten sposób: Jeśli masz konstruktor, domyślny lub inny, jedynym sposobem propagowania stanu poza nawiasy klamrowe jest albo użycie logicznej wartości isValid; (wraz z wartością null jako wartością domyślną v nieudany konstruktor) lub zgłasza wyjątek, który nigdy nie jest pouczający, gdy odzyskuje go od użytkowników pola.

Kod Poprawnie, do diabła, piszę tysiące konstruktorów linii i robię to, czego potrzebuję. Używam isValid przy budowie obiektów - innymi słowy, konstruktory dwuwierszowe - ale z jakiegoś powodu migruję do statycznego wzorca fabrycznego. Wydaje mi się, że możesz wiele zdziałać, jeśli używasz metody, nadal występują problemy z synchronizacją (), ale wartości domyślne można lepiej zastąpić (bezpieczniej)

Myślę, że musimy tutaj zająć się kwestią zerową jako wartością domyślną względem czegoś String one = new String (""); jako zmienną składową, a następnie sprawdzanie wartości null przed przypisaniem ciągu przekazywanego do konstruktora.

Niezwykła ilość surowej, stratosferycznej informatyki wykonanej w Javie.

C ++ i tak dalej ma biblioteki dostawców, tak. Java może wyprzedzić je na dużych serwerach ze względu na ogromny zestaw narzędzi. Studiuj statyczne bloki inicjalizujące, zostań z nami.

Nie jest obsługiwany w Javie jak w innym języku np. Kotlin.

Możesz użyć następujących-

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