Wypełnianie mapy - refactoring kodu

Witajcie,

Mam kawałek kodu, który chcę poprawić. Jest to jedna duża metoda, wypełniająca mapę parametrami. Planowałem wydzielić z niej wiele metod prywatnych odpowiedzialnych za poszczególne parametry. Całość wyglądała by mniej więcej tak:

public Map<String, Integer> fillMap() {
   Map<String, Integer> params = new HashMap<>();
   addGravityParams(params);
   addTemperatureParams(params);
   addRadiationParams(params);
   // i tak dalej
}

Zastanawiam się czy jest lepszy (alternatywny) sposób, żeby to zrefaktorować. Trochę nie podoba mi się to przekazywanie w każdej funkcji prywatnej mapy do wypełnienia. Może da się to zrobić lepiej?

mógłbyś się pokusić o coś takiego:

Map<String, Integer> params = merge(gravityParams(), temperatureParams(), radiationParams());

ew jakieś fajne params = sources.forEach((src) -> params.addAll(src))

Pierwsze pytanie to dlaczego właściwie jest tam ta mapa?

Poza tym:
Podobnie jak wyżej zaproponowano niech każda metoda zwraca własną niemutowalną mapę, a potem putAll

jarekr000000 napisał(a):

Pierwsze pytanie to dlaczego właściwie jest tam ta mapa?

To jest dobre pytanie. Prześledziłem kod i widzę, że zewnętrzna biblioteka wystawia API, które wymaga mapy <String, Intger>

Poza tym:
Podobnie jak wyżej zaproponowano niech każda metoda zwraca własną niemutowalną mapę, a potem putAll

Rozwiązanie z mergem mniej mi się podoba, ze względu na to, że tych parametrów jest dużo, więc merge musiałby przyjąć ok 9,10 parametrów. Spróbuję więc rozwiązania zaproponowanego przez Jarka. Wyglądałoby to tak:

params.putAll(gravityParams());
params.putAll(temperatureParams());
params.putAll(radiationParams());
// i tak dalej

W zasadzie to by mnie to zadowalało. Aczkolwiek szczegóły techniczne zaciemniają tu czytelność algorytmu. Osoba czytająca ten kod widzi w pierwszej kolejności te wszystkie wywołania:

params.putAll

@xLatency varargs/przekazanie kontenera, słyszałeś o czymś takim?
Plus pytanie, doczytałeś mój post? Bo na jego dole znajduje się taka sugestia:

List<Map<String, Integer>> sources = Arrays.asList(
    gravityParams(),
    temperatureParams(),
    radiationParams()
);

sources.forEach((src) -> params.putAll(src));

ew

Stream.of(
    gravityParams(),
    temperatureParams(),
    radiationParams()
).forEach((p) -> params.putAll(p));

spartanPAGE napisał(a):

@xLatency varargs/przekazanie kontenera, słyszałeś o czymś takim?

Złośliwość? naprawdę?

Plus pytanie, doczytałeś mój post? Bo na jego dole znajduje się taka sugestia:

List<Map<String, Integer>> sources = Arrays.asList(
    gravityParams(),
    temperatureParams(),
    radiationParams()
);

sources.forEach((src) -> params.putAll(src));

Rozwiązanie dobre, ale wydaje się przekombinowane i mniej czytelne.

ew

Stream.of(
    gravityParams(),
    temperatureParams(),
    radiationParams()
).forEach((p) -> params.putAll(p));

Również wydaje się mniej czytelne. Jednak z chęcią posłucham o przewagach tego rozwiązania nad:

params.putAll(gravityParams());
params.putAll(temperatureParams());
params.putAll(radiationParams());

Nie strzępisz palców na kolejne params.putAll(...).