[dog_meat]

#programowanie #java #spring

Spring jednak utrudnia pisanie poprawnego kodu obiektowego. Człowiek chce napisać normalną klasę, która posiada dane i bazujące na nich zachowania, ale nie da się w prosty sposób.
Jeśli chcemy dodać dane instancji, to najłatwiej to zrobić przez new, ale wtedy obiekt nie będzie zarządzany przez Springa i nie da się wstrzyknąć do niego zależności.
Jedyne rozwiązanie, jakie widzę, to wstrzyknąć pustego beana ze scope "prototype", a później przez setery poustawiać mu wszystkie dane, ale to bardzo zaśmieca kod i uniemożliwia tworzenie niemutowalnych klas, których jestem zwolennikiem.

[E.....e]

@dog_meat: Chcesz mi powiedzieć ze jak ktos zrobi konstruktor i doda nad nim adnotacje autowired to wszystko niszczy? xD

[P.....k]

Jeśli chcemy dodać dane instancji, to najłatwiej to zrobić przez new, ale wtedy obiekt nie będzie zarządzany przez Springa i nie da się wstrzyknąć do niego zależności.

@dog_meat: nie mam pojęcia w czym widzisz problem

[dog_meat]

@Ewentualnie: No jak dasz autowired na konstruktor, to wstrzyknie Ci wszystko, a ja potrzebuję stworzyć zgodnie z paradygmatem OOP klasę, która ma dane przypisane do każdej instancji a oprócz tego dostarczyć zależności (które właśnie chciałbym dać przez autowired), czyli część parametrów dostarczam, a część wstrzykuję

@PrzegrywWykopek: no właśnie w tym, co napisałem wyżej. Zgodnie z OOP klasa powinna mieć indywidualne dane i przypisane do nich zachowania. A tu się tak

[Bairei]

@dog_meat: Nie jestem pewien, czy chodzi tobie o coś takiego:
https://www.baeldung.com/spring-5-functional-beans
Nie wygląda to bardzo elegancko, ale powinno załatwić sprawę.
(klasa kontekstu kontenera oczywiście powinna być zmieniona)

[witajswiecie]

@dog_meat: a może tak ładować do kontekstu springa tylko klasy które tego potrzebują zamiast robić z niego kosz na wszystkie obiekty w programie ( ͡° ͜ʖ ͡° )つ──☆*:・ﾟ

https://www.youtube.com/watch?v=ILBX9fa9aJo

polecam się zapoznać

[dog_meat]

@witajswiecie: tak bym chciał, ale potrzebuję we wnętrzu tej klasy skorzystać z zależności zarządzanej przez Springa (jej też nie wywołam przez new, bo ona ma swoje zależności).

@witajswiecie: Nie do końca o to mi chodzi. Ja chciałbym tworzyć wiele instancji klasy, którea posiada indywidualne dane, wewnątrz której mogę wstrzyknąć zależnośc zarządzaną przez Springa.

Wrzuciłem prosty przykład na https://pastebin.com/pLMmEexa (to tylko kod wymyślony na potrzeby przykładu). <-- zawołam jeszcze @Ewentualnie i

[E.....e]

@dog_meat: nie bardzo wiem o co Ci chodzi mówiąc szczerze, nie rozumiem czemu chcesz wstrzykiwać część przez autowired, a część tworzyć przez new.

[witajswiecie]

@dog_meat: a nie możesz po prostu dodać springowego beana przez konstruktor do zwykłej klasy? #!$%@?ąc po co do dto wstrzykiwać cokolwiek, chyba że chcesz zrobić z tego active record, albo coś w tym guście ?

[E.....e]

@Ewentualnie: O kurde, nie rob tak xD, Swoja drogą jak bardzo chcesz korzystać z springowego injection to mozesz zarobic to przez ApplicationContext.getBean statyczna metodę, ale nienpolecam xD

[bohme]

@dog_meat: to zrób sobie factory/buildera który będzie komponentem i w nim twórz te swoje obiekty. A do nich wrzucaj referencję do obiektów stworzonych przez Springa i wstrzykniętych do buildera.

[dog_meat]

@Ewentualnie: no popatrze przykład, który wrzuciłem. Pola firstName, lastName, city i age są indywidualne dla instancji. Ale jest pole devicesService, które jest beanem springowym i które potrzebuję wstrzyknąć. Czy masz jakąś propozycję, jak utworzyć klasę, która będzie posiadała powiedzmy firstName=Jan, lastName=Kowalski, City=Bydgoszcz, age=38 oraz devicesService, który jest beansem springowym?

[bohme]

@dog_meat: aha, i jak potrzebujesz coś takiego robić to najprawdopodobniej masz coś źle zaprojektowane

[witajswiecie]

psst

@Component
class KlasaPodKontroląSpringa{

@Autowired
Service service;

void cosTam(){
new KlasaNiePodKontrolaSpringa(service);
}

}

[dog_meat]

@witajswiecie: to nie jest DTO, tylko właśnie typowa klasa, zgodna z OOP, która ma swoje dane i zachowania (w przykładzie nie dodawłem metod, bo stworzyłem go na szybko, ale powiedzmy, że będzie miał spory zestaw metod, które wyknują różne rzeczy, korzystając z serwisu)

@Ewentualnie: wiem, że są obejścia i mogę uzyskać kontekst, i pobrać beana. Ale chodziło mi o to, że Spring raczej zniechęca do pisania zgodnego z prawdziwym OOP

[dog_meat]

@bohme: Czemu źle? Jak dla mnie to jest właśnie rozwiązanie typowe dla OOP i DDD

[dog_meat]

@Component

class KlasaPodKontroląSpringa{

@Autowired

Service service;

void cosTam(){

new KlasaNiePodKontrolaSpringa(service);

}

}

@witajswiecie: To jest właśnie chyba najczystsze rozwiązanie. Średnio podoba mi się łączenie danych i zależności ale chyba tak jest najlepiej. Super jest to właśnie w Scali, gdzie może być wiele list argumentów. Jeśli te zależności są wykorzystywane przez pojedynczą metodę, to wtedy lepiej przekazać je a argumencie metody. Ale jeśli używa się ich w wielu metodach, trzeba wrzucić do

[witajswiecie]

@dog_meat:
to że łączysz dane i zależności jest winą przyjętej architektury a nie springa, scalowe implicit wcale nie rozwiązuje problemu w tej kwestii, nadal łączysz dane i logikę, tyle że to łączenie dokonuje się na poziomie kompilacji a nie przez kontener DI

[dog_meat]

to że łączysz dane i zależności jest winą przyjętej architektury a nie springa, scalowe implicit wcale nie rozwiązuje problemu w tej kwestii, nadal łączysz dane i logikę, tyle że to łączenie dokonuje się na poziomie kompilacji a nie DI

@witajswiecie: przecież łączenie logiki i danych jest główną podstawą programowania obiektowego (przeciwieństwem jest programowanie strukturalne, które udaje obiektowe, które rozdziela logikę i dane, opakowując to w klasy)

[diabel_z_piekla]

@dog_meat: Zrób klasę factory, wstrzyknij tam:

private @Autowired AutowireCapableBeanFactory beanFactory;

i później gdzieś w metodzie:

MyService create() {
 MyService service = new MyService();
beanFactory.autowireBean(service);
}

O coś takiego chodzi?

[witajswiecie]

@dog_meat: nie żeby coś ale przykład który podałeś na pastebin to właśnie takie udawanie ;)

po prostu osobiście nie widzę powodu dla którego przekazywanie niejawne parametrów rodem ze scali miałoby jakąś przewagę poza tym że ładniej wygląda, tylko dlatego że czegoś nie widzisz bezpośrednio w kodzie, mimo że nadal tam jest podczas kompilacji