[JAVA] Metoda ze zmienną ilością argumentów

Witam

Ostatnio dużo pisze w actionscripcie i o ile zawsze szanowałem jeżyk java za to, że bardzo dużo rzeczy zostało przewidzianych i nie trzeba samemu pisać, to teraz trafiłem na rzecz której (chyba) w javie brakuje.

W AS jest mozliwe wywołanie metody ze zmienną ilością parametrów tzn że metodę :

public function metdoa(i:int = 0, nazwa:String = null;flaga:Boolean = false)

mogę wywołać tak:

metoda(12,"bla",true);

Ale mogę też wwołać tak:
metoda(12); a pozostałe argumenty przyjmują wartości domyślne.

jest to potezne uproszczenie kiedy się pisze soft w grupie - ktoś napiszę klasę zastosuje ją, ja potem z niej korzystam, musze dodac własne argumenty do metod-ale w jego części sie nic nie zmienia. Wywołanie parametrów pozostaje takie same bo reszta jest wywoływana tak jakby jej nie było.

Czy powyższy mechanizm jest w Javie - jakaś nazwa, przykład?

EDIT: używałem kiedyś zmiennej liczby argumentów ale tego samego typu musiały byc więc to nie to samo.

Przeciążanie metod.
Robisz sobie dwie metody:

public void metoda(int i, String nazwa, boolean flaga);
public void metoda(int i) {
    metoda(i, null, false);
}

czy to nie to samo?

no oczywiście- przeciażanie. Ale teraz sobie wyobraź klase z metodami przyjmującymi do 14 parametrów ? Nie to nie to samo bo z klasy 600 linii robi Ci się 1600 i w końcu wszystko jest nieczytelne.

Po pierwsze można swobodnie przeciążać metody. Byle by się typ zwracany zgadzał. Po drugie w javie nie ma wartości domyślnych parametrów na poziomie sygnatury, ale można swobodnie robić sobie założenia w kodzie. Po trzecie duża ilość parametrów w metodzie na odległość pachnie złym kodem. Metoda robi za dużo rzeczy, staje się nieczytelna i generalnie późniejsza praca z nią to jakiś sajgon.
@lipkerson, rzuć okiem na interfejs ResultSet. Od cholery metod, ale moim skromnym zdaniem jeżeli klasa ma więcej niż 100-120 linii to jest niezłym kandydatem do zmiany i rozbicia na drobne.

Niestety ani nazwanych ani domyślnych parametrów nie ma w Javie. Musisz korzystać z przeciążania metod.

W Scali są w wersji od 2.8. W połączeniu z konwersjami i parametrami implicit miażdżą :)

ok upewniliście mnie dziękuje
@Koziołek

oczywiście masz racje - przesadziłem z metodami po 14 parametrów. Ale konstruktor taki to już wiele razy widziałem i musiałem swój dorabiać. Zerknąłem na to ResultSet - fakt skrolowałem i końca nie widać - ale pewnie wykorzystuje się 4-10 z nich. fakt jest jeden...domyślne wartosci argumentów oraz zmianna ich liczba w AS mi się spodobały:) Może w kolejnej odsłonie javy będzie kiedyś....bo w sumie koncepcji programistyczej to by nie zmieniło tylko zapis-chyba?

Moim zdaniem zmieniłoby trochę koncepcję. Domyślne argumenty są niczym innym niż "magic numbers", które są wręcz stworzone do złego programowania. Jeżeli ktoś zmieniłby implementację metody lub ją przeciążył, to za każdym razem trzeba by było zaglądać do kodu, a w najlepszym przypadku do dokumentacji. Utrudnianie przez Javę takiej techniki przez zmuszanie do tworzenia dużej ilości przeciążonych metod jest celowe i samo w sobie korzystne. Jeżeli mamy dużo danych "domyślnych", to powinny się one z automatu stawać zasobami aplikacji. A te łatwiej przechowywać w celowo stworzonych dla nich strukturach danych niż w czymś tak efemerycznym jak domyślne argumenty metody.

Ja jednak myślę, że posiadanie jednej metody z parametrami domyślnymi jest lepsze niż 2^n przeciążonych metod bez parametrów domyślnych.

Jest jeszcze jeden sposób obejścia tego problemu - opakowanie parametrów w obiekt.
Sam to czasami robię zamiast tworzyć metodę z 10 argumentami.

Mały przykład dla dodawania zdarzeń z wymaganiami:

1. Rodzaj zdarzenia jest wymagany
2. Jeżeli nie podano daty zdarzenia, to przyjmujemy, że zdarzyło się teraz
3. Jeżeli nie podano priorytetu, to przyjmowany jest domyślny

public void dodajZdarzenie(ParametryZdarzenia parametry) {
     if (parametry.getRodzajZdarzenia == null) {
         throw new IllegalArgumentException("Nie podano rodzaju zdarzenia");
     }

     if (parametry.getDataZdarzenia() == null) {
         parametry.setDataZdarzenia(new Date());
     }

     if (parametry.getPriorytet() == null) {
        parametry.setPriorytet(Priorytet.DOMYSLNY);
     }

     if (parametry.getKomentarz() == null) {
        parametry.setKomentarz("");
     }

     dodajZdarzenieImpl(parametry);
}

Dzięki temu nie ma problemu z kolejnością parametrów oraz nie trzeba tworzyć całej masy przeciążonych metod.
Głównym problem to sytuacje typu "jeżeli podano A i B to rób X, a jeżeli podano tylko A to Y". Jeżeli takich sytuacji jest dużo, to nie należy stosować tej metody, bo powstanie cała masa if'ów.

Ten sam przykład za pomocą przeciążania:

private static final String DOMYSLNY_KOMENTARZ = "";

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia) {
     dodajZdarzenieImpl(rodzajZdarzenia, new Date(), Priorytet.DOMYSLNY, DOMYSLNY_KOMENTARZ);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, Date dataZdarzenia) {
     dodajZdarzenieImpl(rodzajZdarzenia, dataZdarzenia, Priorytet.DOMYSLNY, DOMYSLNY_KOMENTARZ);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, Priorytet priorytet) {
     dodajZdarzenieImpl(rodzajZdarzenia, new Date(), priorytet, DOMYSLNY_KOMENTARZ);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, Date dataZdarzenia, Priorytet priorytet) {
     dodajZdarzenieImpl(rodzajZdarzenia, dataZdarzenia, priorytet, DOMYSLNY_KOMENTARZ);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, String komentarz) {
     dodajZdarzenieImpl(rodzajZdarzenia, new Date(), Priorytet.DOMYSLNY, komentarz);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, Date dataZdarzenia, String komentarz) {
     dodajZdarzenieImpl(rodzajZdarzenia, dataZdarzenia, Priorytet.DOMYSLNY, komentarz);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, Priorytet priorytet, String komentarz) {
     dodajZdarzenieImpl(rodzajZdarzenia, new Date(), priorytet, komentarz);
}

public void dodajZdarzenie(RodzajZdarzenia rodzajZdarzenia, Date dataZdarzenia, Priorytet priorytet, String komentarz) {
     dodajZdarzenieImpl(rodzajZdarzenia, dataZdarzenia, priorytet, komentarz);
}

Zawsze można domyślne parametry ustawić już w samym ParametryZdarzenia i tam sprawdzać, czy ustawiane pola nie są nullami. To zmniejszy ilość kodu w samej metodzie z dodawaniem.

iooi napisał(a)

Zawsze można domyślne parametry ustawić już w samym ParametryZdarzenia i tam sprawdzać, czy ustawiane pola nie są nullami. To zmniejszy ilość kodu w samej metodzie z dodawaniem.

Zgadzam się - o ile jest to możliwe, to lepiej ustawić to w klasie ParametryZdarzenia.
Czasami jednak, gdy używamy jakiejś biblioteki, która binduje pola, to może ona niekorzystnie zmienić ustawione wcześniej pole, np. jeżeli użytkownik nie wybierze daty zdarzenia, to zostanie automatycznie wykonane "setDataZdarzenia(null)" i wcześniejsze ustawienie tej wartości na "new Date()" w konstruktorze/na polu nic nie da.