Hej, przy projektowaniu serwisu dla aplikacji, zacząłem się zastanawiać jak rozwiązać poniższy problem.
Załóżmy że mamy serwis odpowiedzialny za dodanie użytkownika do bazy (klasyk :) ) który w konstruktorze przyjmuję:
Co gdybym chciał skorzystać w user service z innego repo czy serwisu? Mam go po prostu wstrzyknąć przez konstruktor jako czwartą zależność?
Jak by to najlepiej ugryźć ?
o_O ty tak poważnie? Chciałbym zobaczyć jak przekazujesz taki serwis przez pół aplikacji...
Jan Ko napisał(a):
Co gdybym chciał skorzystać w user service z innego repo czy serwisu? Mam go po prostu wstrzyknąć przez konstruktor jako czwartą zależność?
Tak, tylko czemu chcesz korzystać z serwisu w repozytorium.
Shalom napisał(a):
o_O ty tak poważnie? Chciałbym zobaczyć jak przekazujesz taki serwis przez pół aplikacji...
- Kontener IoC
- Service Locator
- Singleton
W tejże kolejności.
Czyli po prostu korzystać z kontenera w serwisie zamiast wstrzykiwania pojedynczych klas?
Chodzi o jave, javascript, php, python czy np c++?
Wstrzykiwanie przez konstruktor ma krotkie nozki i przestaje byc przyjemne przy 4 argumentach.
Mozna przedluzyc meki przez Factory, Buildera lub Singleton.
Jesli masz mozliwosc, uzyj kontenera IoC.
Jesli nie - service locator (gdzie locator nie jest przywiazany do konkretnej klasy).
DretwyRoman napisał(a):
Chodzi o jave, javascript, php, python czy np c++?
Wstrzykiwanie przez konstruktor ma krotkie nozki i przestaje byc przyjemne przy 4 argumentach.
Mozna przedluzyc meki przez Factory, Buildera lub Singleton.
Jesli masz mozliwosc, uzyj kontenera IoC.
Jesli nie - service locator (gdzie locator nie jest przywiazany do konkretnej klasy).
php symfony2
Chyba przez konstruktor wstrzyknę kontener jednak.
DretwyRoman napisał(a):
Wstrzykiwanie przez konstruktor ma krotkie nozki i przestaje byc przyjemne przy 4 argumentach.
A jakąż to różnicę kontenerowi robi liczba argumentów?
Wstrzykiwanie przez konstruktor ma krotkie nozki i przestaje byc przyjemne przy 4 argumentach.
Wstrzykiwanie przez konstruktor to bez watpienia jedna z najsensowniejszych opcji...
@n0name_l chyba żartujesz ;] Przecież to by czasem oznaczało przekazywanie jakiegoś obiektu przez pół systemu o_O
Kontener IoC to jedyne sensowne rozwiązanie. Nie wiem jak to wygląda w PHP. W javie frameworki radzą sobie ze wstrzykiwaniem bez konieczności posiadania zależności w konstruktorze albo setterów. Więc generalnie masz zwykłą klasę która ma pola z dodanym @Inject i automagicznie przy starcie systemu zarządzane obiekty tej klasy mają ustawione te zależności. Nie trzeba się martwić skad je wziąć ani jak przekazać.
Ale po co chcesz obiekt gdziekolwiek recznie przekazywac, przeciez to bez sensu.
Jesli klasa X ma zaleznosc w postaci obiektu klasy Y i bez niego nie moze funkcjonowac, to jedyne logiczne wyjscie to jest wrzucenie tego jako parametr konstruktora, koniec kropka. A uzywanie jakichs magicznych adnotacji tylko robi zaleznosc od tych adnotacji w klasach, w ktorych jest to zupelnie niepotrzebne, skracajac kod o ile? 3 czy 5 linijek?
Adnotacje są częścią standardu języka więc nic nie wprowadzasz ;) Ciekawi mnie trochę co zrobisz jak zależność będzie krzyżowa... :D
Zresztą przecież kontener nie działa tylko dla obiektów singletonowych, o których ty tu mówisz. Działa tak samo dla obiektów o zasięgu session czy request. Nie wiem jak w PHP ale w Javie zwykle w ogóle nie musisz nawet o tym myśleć bo kontener sam będzie te obiekty tworzył ;]
Adnotacje w PHP to pomyłka bo nie są w standardzie ;/
Dzięki Panowie, rozbiłem to wszystko na mniejsze części. Zauważyłem, że tyle zależności może jednak wprowadzać patologie ;/
Kontenerów do IoC do PHP jest nawet chyba więcej niż do Javy, w tym w tych największych frameworkach, więc nie ma co się zastanawiać.
Kilka przykładów:
http://www.sitepoint.com/php-dependency-injection-container-performance-benchmarks/
http://www.slideshare.net/neraath/ioc-with-php-8833643
Shalom napisał(a):
Adnotacje są częścią standardu języka więc nic nie wprowadzasz ;) Ciekawi mnie trochę co zrobisz jak zależność będzie krzyżowa... :D
Jeśli zależność jest krzyżowa, to znaczy, że projekt jest zwalony, więc równie dobrze można porzucić IoC, wszystko tworzyć ręcznie, przejść na zmienne globalne i przemieszczać się po kodzie za pomocą goto.
Natomiast jeśli obiekt X korzysta z obiektów A, B i C, to naturalne jest przekazywanie ich przez konstruktor. Wówczas od razu widać, od czego dany obiekt zależy i czego do życia potrzebuje. Adnotowane pola ustawiane magicznie z zewnątrz, są po pierwsze nieczytelne - wyszukanie pól z adnotacją w kodzie trwa dłużej niż przeczytanie nagłówka konstruktora, a poza tym śmierdzą bardzo zmiennością, a obiekty powinny być tak niezmienne jak to możliwe. Poza tym, w razie potrzeby można taki obiekt zawsze utworzyć z palca, łatwo go też mockować w testach bez potrzeby korzystania z IoC.
No, ale zapewne w Javie bardziej się przyjęły adnotacje, bo to po pierwsze nowość w języku, a po drugie zapewne można do tego dopisać dużo konfiguracji w XML, a nie męczyć się z 10 linijkami IoC na cały projekt jak w konkurencyjnych technologiach.
@somekind: w Javie jest wiele mozliwosci, a ta ktora promuje @Shalom uznawana za najbrudniejsza. Wiecej w tym (aktualnym) temacie.