[Warszawa-pm] Dependency Injection

[Zbigniew Lukasiak]

2011/1/8 Roszatycki, Piotr <piotr.roszatycki w gmail.com>:
> W dniu 5 stycznia 2011 19:44 użytkownik Zbigniew Lukasiak <zzbbyy w gmail.com>
> napisał:
>>
>> Przy okazji jestem bardzo zadowolony z mojego ostatniego artykulu na
>> blogu:
>> http://perlalchemy.blogspot.com/2011/01/dependency-injection-or-removing.html
>> .  Liczę na komentarze.
>
> Czekaj, czekaj...
> Czy to chodzi o to, aby nie tworzyć obiektów w danej klasie tylko
> przekazywać je za pomocą parametru konstruktora tej klasy albo settera?
> Rany... Ta prosta reguła ma swoją nazwę, dziesiątki publikacji oraz nawet
> dedykowane biblioteki
> (http://components.symfony-project.org/dependency-injection/)? Myślę, że
> kogoś pogięło, bo to typowy przerost formy nad treścią ;)

Tak - to o to chodzi, jednak nie uważam, że to jest przerost formy nad
treścią - bo jednak "prosta reguła, by nie tworzyć obiektów w danej
klasie tylko  przekazywać je za pomocą parametru konstruktora tej
klasy albo settera" jest nieco za długie, a trzeba to jakoś nazwać.  A
trzeba to jakoś nazwać, bo chociaż jest to dość naturalne - to jenak
jest mnóstwo kodu który tą regułę łamie.  To jest trochę tak jak ze
zmiennymi globalnymi.  Niby prosta sprawa, ale jednak trochę trwało,
żeby zostało ogólnie zaakceptowane, że to jest niedobre.  A co jakby
to jeszcze nie miało nazwy?

Oczywiście nazwa jest raczej kiepska bo rzeczywiście sugeruje
niewiadomo co - podczas gdy sprawa jest prosta.  Chociaż nie znaczy
to, że wokół niej nie ma ciekawych problemów.


> Nota bene, w Perlu jest ciekawa tego
> implementacja: http://search.cpan.org/perldoc?Bread::Board
> Wydaje mi się, że całość tego tematu sprowadza się do wyboru, czy
> hardkodowane parametry zapisujemy w pliku konfiguracyjnym (XML, jak to się
> chyba odbywa w Java Spring), czy w natywnym języku (wszystkie obiekty
> tworzone w głównej funkcji) lub też skorzystanie z jakiegoś specjalizowanego
> języka (Bread::Board).

No i właśnie - wbrew temu co sugerujesz nie jest to wcale prosty wybór
- dobry język tutaj to jest wszystko.  Poza tym to co robi
Bread::Board i inne 'container'y to jest nie tylko specjalizowany
język (na przykład XML) - ale też 'rozwiązywanie grafu' zależności -
jeśli z 'containera' wyciągasz jakiś objekt to on już sam tworzy
wszystkie jego zależności - nie musisz tego kodować sam.  Ale do
samego DI nie musisz tego używać i sobie kodować to ręcznie.

Poza tym dochodzi jeszcze sprawa tego ile takich 'factories' czy
'containers' masz w aplikacji - to wcale nie jest prosta sprawa.
Wydaje mi się, że jest potrzebna jedna na każdy 'scope'.

Czasem proste reguły generują ciekawe problemy.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/