Do głowy przychodzi mi jeszcze opcja stworzenia metody, która przyjmowałaby maksymalną ilość argumentów, a wywołując ją w argumencie ccList przekazywałbym null, a w metodzie sprawdzałbym jak poniżej czy przekazany argument jest nullem i według tego wywoływał odpowiednią metodę.
Wydaje mi się to jednak kompletnie "niepoprawne", aby null świadomie przekazywać jako argument.
W java to jest bardzo niepoprawne podejście. Sygnatura metody powinna jasno wskazywać które parametry są wymagane, a które opcjonalne. W Java nie ma takiej możliwości, więc należy unikać. W językach, które mają parametry nazwane + null safety IMO jest to dopuszczalny pomysł:
fun sendMessage(subject:String, to: List<String>, cc: List?<String>)
W Java zrobiłbym przeciążenie "teleskopowe", czyli implementujesz jedną metodę, tę z największą liczbą parametrów, do niej dorabiasz metody z domyślnymi wartościami tych parametrów jak w przykładzie @obscurity
Jeżeli pojawi się potrzeba dodania kolejnego parametru, masz o tyle prosto, że dodajesz ten parametr + dodajesz kolejne przeciążenie tej metody, czyli zmiany będą ograniczone do jednego miejsca.
public void sendMessage(String messageText, String subject, String recipientsList, String ccList) {
//jakaś tam implementacja
}
public void sendMessage(String messageText, String subject, String recipientsList) {
sendMessage(messageText, subject, recipientsList, "");
}
i po refaktoryzacji z dodaniem parametru z załącznikami:
public void sendMessage(String messageText, String subject, String recipientsList, String ccList, Attachement attachment) {
//jakaś tam implementacja
}
public void sendMessage(String messageText, String subject, String recipientsList, String ccList) {
sendMessage(messageText, subject, recipientsList, ccList, null);
}
public void sendMessage(String messageText, String subject, String recipientsList) {
sendMessage(messageText, subject, recipientsList, "");
}
