Czy dependency injection to już standard?

Z waszego doświadczenia: czy w projektach, w których braliście udział dependency injection (jako wstrzykiwanie klas np jak to jest w springu czy cdi) to już standard czy raczej bierzecie/braliscie udział w projektach w których się tego wzorca nie stosuje?

Wiem, że dla springowców to będzie coś normalnego, że "CO TO ZA PYTANIE! oczywiscie ze sie stosuje!", bo na tym sie spring opiera.. ale ciekawi mnie jak to jest z innym stackiem technologicznym

Wiem, że można jakiś tam Guice, PicoContainer, dagger(android?) czy nawet spring albo cdi (nie daj bóg HK2) zaprzęgać. Pytanie czy to się robi? Bo zaczynam mieć wątpliwości i chciałbym je rozwiać ;)

dzieki

Ze względu na modularyzację aplikacji to jest już standard.

@Koziołek pijesz do tej właśnie prezentacji, którą @Szczery wstawił wyżej czy do tego że teraz ogólnie jest moda na dzielenie aplikacji na moduły?
Jeśli o to drugie - gdzie w tym użyteczność DI? (jesli dobrze rozumiem modularyzacja = dzielenie aplikacji na moduły które są np odpowiedzialne za dana funkcjonalnosc)

Z mojego punktu widzenia wstrzykiwanie zależności służy do implementacji aspektów/interceptorów i zarządzania cyklem życia komponentów przez kontener (scopes). Jest też lepsze niż JNDI lookup bo nie trzeba wpisywać stringów.

Dla mnie standart na androidzie. Głównie ze względu na testy

Z różnego rodzaju mechanizmów DI korzysta się w:

• aplikacjach modułowych - bo każdy moduł może mieć osobną konfigurację
• aplikacjach webowych i desktopowych, praktycznie cały enterprise na tym stoi
• frameworkach do mockowania danych
  itp. itd.

To jest standard, ponieważ DI jest krokiem w stronę programowania deklaratywnego.

@azalut, trudno modą nazywać coś co robimy od 40 lat z okładem. Co zaś tyczy się miejsca DI w takim procesie to trzeba pamiętać, że jest to implementacja IoC. Tu kontrola tworzenia zależności pomiędzy modułami zostaje przeniesiona na poziom kontenera DI, który na podstawie deklaratywnej konfiguracji dokonuje odpowiedniego wiązania.
Mówiąc prościej rozbicie aplikacji na moduły wymusza użycie takiej czy innej formy DI.

No dobra, powiedzmy że w projektach stojących na Javie to juz standard

a jak to jest w innych jezykach? (teraz wypadaloby ten temat przeniesc do innego działu :P)
Scala, Python, Groovy, Ruby.. tam też DI w postaci wstrzykiwania klas do innych klas jest używane na taką skalę jak w Javie? Czy to taki typowo javowy pattern?

W C# też to już standard. Tylko trochę inaczej realizowany. W Scali masz też DI, ale w oparciu o tzw. Cake Pattern i traity (czasami wybucha).

IMO, wszędzie tam gdzie masz OOP to masz i rozwiązania DI, bo to jest wygodne rozwiązanie. Trochę jak z pytaniem o to co by było jak by nie było mavena ;) Po prostu ktoś dopisuje i tyle.

Piękno wzorców projektowych polega właśnie na tym, że są niezależne od języka (i czasami od rozumu).

Tak myślałem. Chciałem jednak wiedzieć czy to jest realizowane na tej samej zasadzie czy troche inaczej, tak jak wspominasz

Jeśli chodzi o języki obiektowe typu C#/Java to jest to realizowane tak samo:

1. Jakaś inicjalizacja (przez xml czy w kodzie).
2. Wstrzykiwanie przez konstruktor/adnotacje.

Jeśli chodzi o języki bardziej funkcyjne, to znaczy jak ktoś pisze funkcyjnie bo wszyscy wiemy, że np. w takiej scali się tego nie robi, to się używa tworu zwanego Reader, a w praktyce coś bardziej typu ReaderWriterStateTransformer, żeby dało się zapisywać/odczytywać z jakiegoś tam kontekstu i wszystko się dzieje bez inicjalizacji i sprawdzane jest na poziomie kompilacji, co ma w sumie większy sens bo nie masz błędów w runtime, że Foo nie zostało zarejestrowane.

W niektórych językach się w ogóle nie używa czegoś przypominającego standardowe wstrzykiwanie zależności, np. w JavaScriptcie (angular próbował, wyszło jak wyszło...), czy w ogólności w językach dynamicznie typowanych rzadko to się robi.

Czyli w np. pythonie pozostaje klasyczne podejscie tworzenia obiektów w kodzie zamiast brania ich z kontekstu jak np w springu? (przyznam bez bicia, ze nie guglałem o tym jeszcze.. :v)
Mnie to DI w angularze nawet podchodzi ;)

To scala w koncu nie ma typowego injection przez adnotacje, tylko jakies swoje podejście do tego patternu i finalnie dzieje się to samo, ale inaczej?

Pojęcie wstrzykiwania zależnosci istnieje i w pythonie (to pojęcie de facto znaczy "przyjmowanie argumentu"), ale nie są popularne kontenery takie jak w C#/Java, http://stackoverflow.com/questions/2461702/why-is-ioc-di-not-common-in-python

W Scali możesz używać:

1. Klasycznego kontenera (Spring, Guice), są wrappery do niektórych, działa to na tej samej zasadzie co w Javie.
2. Cake Pattern (który osobiście dla mnie jest kompletnie poronionym pomysłem, a jego autor powinien być publicznie nabity na pal).
3. Tych samych patternów co w Haskellu, czyli zamiast mieć funkcje przyjmująca zależność, zwracasz funkcję, która przyjmuje tą zależność, tj.
   Zamiast:

def doSomething(service: IService): SomeValue = ...

Robisz:

def doSomething(): IService => SomeValue = ...

Edit, prezentacja mi się przypomniała o tym:

Nie wiem czy dobrze rozumiem całą tą idee DI, ale jeżeli chodzi o to, żeby do bezstanowego serwisu wstrzyknac inny bezstanowy serwis, to czy to nadal jest OOP?

@tdudzik, tak to nadal jest OOP. DI jest realizacją wzorca IoC (inversion of Control) w ramach której przekazano odpowiedzialność za tworzenie obiektów do "kontenera". To czy serwis do którego coś wstrzykujesz ma stan czy go nie ma nie zależy od DI.

@tdudzik niekoniecznie. Faktycznie bardzo często realizuje się w ten sposób takie niby-soa, ale beany nie muszą być bezstanowe ani singletonowe. Bean może mieć też np. scope jednego requestu http czy też jednej sesji i może też przechowywać jakiś stan.
Idea DI/IoC jest taka że masz pewną namiastkę programowania deklaratywnego. Nie piszesz "jak" coś zrobić tylko "co" ma się stać.