Przekazywanie klasom obiektów i konfiguracji

Mając takie coś

class ExampleClass {

   final String port;
   final Service1 service1;
   final Service2 service2;
   final Service3 service3;
   final Object obj;
   final Object obj2;

    // ...
}

robiłem np. tak:

class ExampleClass {

   final Config config;
   final Components components;

    // ...
}
class Config {
   final String port;
// ...
}
class Components {
   final Service1 service1;
   final Service2 service2;
   final Service3 service3;
   final Object obj;
   final Object obj2;
// ...
}

Dzisiaj spotkałem się z takim rozwiązaniem by ładować wszystko do Mapy i udostępnić słownik kluczy tej mapy.

class ExampleClass {
    final ConfigHolder configHolder;
// ...
    Service2 service2 = (Service2) configHolder.get(ConfigKeysDictionary.SERVICE2);
// ...
}
class ConfigHolder {
    Map<String, Object> map;
// ...
}
class ConfigKeysDictionary {
    final static String HOST = "host";
    final static String SERVICE1 = "service1";
    final static String SERVICE2 = "service2";
    final static String SERVICE3 = "service3";
    final static String OBJECT = "object";
    final static String OBJECT1 = "object1";
}

Drugi sposób ma sens? W jakich przypadkach?

Podaj kontekst, bo nie wiem o co chodzi. Generalnie lepiej używać statycznego typowania, jeśli tylko wspiera to język :)

Charles_Ray napisał(a):

Podaj kontekst, bo nie wiem o co chodzi. Generalnie lepiej używać statycznego typowania, jeśli tylko wspiera to język :)

OK.

Ale kontrprzykład łatwo podać: poszerzenie konfiguracji o pola, co do których potrzeba okazała się na wdrożeniu: mają się cofnąć do kodowania, kompilacji i całej procedury, czy da się na wdrożeniu (i Map może mieć sens, ale już mocno inny Map)

@Julian_ Twój drugi przykład łączy wady, i nie wnosi (w mojej opinii) żadnych zalet. Poszerzenie nadal wymaga cofnięcia się do kodu, kompilacji, itd NADAL n ie jest podatny na runtime,... nie jest type-safe. Jest głęboko nieestetyczny, nieelegancki.

Ale kontrprzykład łatwo podać: poszerzenie konfiguracji o pola, co do których potrzeba okazała się na wdrożeniu: mają się cofnąć do kodowania, kompilacji i całej procedury, czy da się na wdrożeniu (i Map może mieć sens, ale już mocno inny Map)

Nie jestem wcale przekonany, że to jest dobry kierunek. Jeśli potrzeba nowego propertasa, to znaczy, że ktoś musi tego propertasa przeczytać i coś z nim zrobić. A to już wypadałoby otestować, a więc wdrożyć zwyczajną procedurą. Grzebanie w warach i podgrywanie klasek też było mega elastyczne :)

Charles_Ray napisał(a):

Ale kontrprzykład łatwo podać: poszerzenie konfiguracji o pola, co do których potrzeba okazała się na wdrożeniu: mają się cofnąć do kodowania, kompilacji i całej procedury, czy da się na wdrożeniu (i Map może mieć sens, ale już mocno inny Map)

Nie jestem wcale przekonany, że to jest dobry kierunek. Jeśli potrzeba nowego propertasa, to znaczy, że ktoś musi tego propertasa przeczytać i coś z nim zrobić. A to już wypadałoby otestować, a więc wdrożyć zwyczajną procedurą.

Masz rację, ale propertas może przelecieć przez cały kompilowany kod "od producenta" (i ten kod przekazuje, a się nie wtrąca) wziąć udział w jakimś skrypcie lub raporcie, lokalnym dla wdrożenia. Fakt, mogłem podać wcześniej tego rodzaju scenariusz za moją tezą, prawdopodobnie jedyny.

UPDATE:
generalnie lubię kompilowane klasy konfiguracji. Pola / propertusie okraszone minimum adnotacji / atrybutów C#, zakładki edycyjne się same budują / częściowo walidują itd... można zaimplementować wyłączenie grup zależnie od bool'i/enumów
Więc jestem przeciw, a nawet za.

Charles_Ray napisał(a):

Podaj kontekst

https://github.com/julian4programmers/websockte/tree/master/websocket-training-0-client/src/main/java/com/julian/consumer

przy okazji coś nie działają te websockety, nie wiem czemu

Coś mi się zdaje, że masz to Properties, bo pogwałciłeś dependency inversion principle. Chyba, że robisz PR do Kafki.