Niezależnie od popularności, czy istnieją jakieś dowody empiryczne, które pokazują, że wstrzykiwanie zależności (i / lub użycie kontenera DI) pomaga, powiedzmy, w zmniejszeniu liczby błędów, poprawie łatwości konserwacji lub zwiększeniu prędkości opracowywania rzeczywistych projektów oprogramowania?
18
Odpowiedzi:
TLDR
Dane empiryczne są nieistotne. Narzędzia i praktyki (takie jak DI) rozwiązują określone problemy. Zrozum swoje problemy, naucz się korzystać z narzędzi, a stanie się oczywiste, kiedy narzędzie jest cenne - a będziesz w stanie wyjaśnić wyniki o wiele bardziej proroczo niż jakiekolwiek uogólnione, zagregowane dane empiryczne.
A teraz z dużo większą gadatliwością ...
Czy istnieją dowody empiryczne?
Pewnie, pewnie. A przynajmniej może. Ale kogo to obchodzi? To nie ma znaczenia.
Statystyczna analiza kosztów i korzyści DI może być interesująca z naukowego punktu widzenia, ale niekoniecznie przewiduje indywidualny sukces. Zagregowane wyniki ukrywają indywidualne sukcesy i porażki. I mogę argumentować, że dane dotyczące praktyk „ewangelicznych” są szczególnie trujące. Dyscypliny te mają tendencję do przyciągania zarówno fanatyków, jak i głupców, z których oba przesłaniają wpływ netto „czystej” implementacji, i którymkolwiek z nich możesz być!
Skąd więc wiemy, że Dependency Injection jest w ogóle cenny ?
Dobre pytanie! WIELKIE pytanie. I jestem z tobą - nie znoszę marnować czasu i wysiłku umysłowego na dogmatyczne „najlepsze praktyki”, których nikt nie może uzasadnić. Cieszę się, że o to pytałeś.
Uhh Ale tu jest kłopotliwy problem ... W ogólnym ujęciu, ty nie wiesz. A nawet bardziej zawstydzające, twój kod może nie poprawić się w żaden sposób poprzez wprowadzenie DI.
ŁAPANIE TCHU!
...
Może zastanawiasz się ...
Dlaczego miałbym zawracać sobie głowę sprawami, których nie udowodniono, prawda ?!
Po pierwsze, uspokójmy się - po każdej stronie debaty. Mogę was zapewnić, że między dogmatyzmem a sceptycyzmem leży piękny raj rozsądku i opanowania. (I od czasu do czasu ekscentryczny post SE.SE.) I, POAP może cię tam poprowadzić.
... Rozumiem przez to zasadę stosowania zasad :
(Powiedziałbym: „moje podkreślenie”, ale i tak pochodzi z mojego „bloga”. A więc to wszystko moje!)
Chciałbym powtórzyć główny punkt: musisz zrozumieć, dlaczego robisz to, co robisz.
Być może, aby to wyjaśnić, zazwyczaj nie ma sensu brać żadnego „czegoś” (takiego jak Dependency Injection) i używać go, nie wiedząc już, jaki problem rozwiązuje - dla ciebie. Jeśli zrozumiesz swoje problemy i sposób, w jaki działa „coś” (jak DI), będzie nieco „oczywiste”, jak pomocne jest „coś”, bardzo niezależnie od tego, co sugerują uogólnione, zagregowane dane empiryczne.
Jeśli uczynność DI lub un -helpfulness do ciebie nie jest oczywiste - przynajmniej poza swoje uprawnienia rozumowania - to albo nie rozumieją, DI, czy ty nie rozumiesz swoje własne problemy.
Rozważmy prawdziwą „przypowieść”.
Musimy zbudować pudełko. Mamy drewno. Mamy gwoździe. I mamy dwa narzędzia: standardowy młot pazurowy i śrubokręt .
Teraz możemy mieć pewne szerokie dane empiryczne, aby pokazać, że skrzynki zbudowane za pomocą śrubokrętów są ogólnie znacznie bardziej solidnymi skrzynkami niż te zbudowane z młotami. Ale jeśli spróbujesz wkręcić te gwoździe, w ogóle nie otrzymasz pudełka. A jeśli spróbujesz wbić je śrubokrętem, w końcu możesz je wsadzić; ale będzie to wymagało znacznie więcej czasu i wysiłku, a końcowy wynik będzie mniej precyzyjny (i solidny) niż po prostu przy użyciu młotka.
A jeśli kiedykolwiek widziałeś, jak ktoś używa któregoś z narzędzi, i jeśli rozumiesz, jak wygląda pudełko, decyzja jest oczywista.
Telekinezja!
Err ... hmm ...
Tak, więc jaki problem rozwiązuje Dependency Injection?
Działa w celu zapobiegania sztywnemu, nieskonfigurowanemu kodowi, który często dlatego nie jest testowalny .
Robi to, pozwalając na wywołanie kodu, aby zdecydować, z którymi obiektami działa moduł. Wiem, że o tym myślisz i masz rację: nie jest to nawet nowa koncepcja. Parametry metody / funkcji istniały od czasu algebry.
Zaczęliśmy ewangelizować przekazywanie podstawowych parametrów, nazywając je „wstrzykiwaniem zależności”, gdy tylko zgromadziliśmy i odziedziczyliśmy wystarczającą ilość kodu, aby zobaczyć nasze nierównowagi. Gór kodu, nad którymi siedzieliśmy, nie można łatwo zmienić, przetestować, a nawet ponownie wykorzystać , po prostu dlatego, że zależności są ukryte.
Stąd gorliwa krucjata dla Wstrzykiwania Zależności ...
K. Ale mogę przekazać argumenty w porządku. Dlaczego ramy ?
Jak rozumiem, frameworki DI przede wszystkim rozwiązują problem gromadzenia się płyt kotłowych (z powodu nadgorliwego DI, IMO) - szczególnie gdy istnieją standardowe „domyślne” zależności dla wszystkich modułów, które ich wymagają. Frameworki DI robią magiczne (potencjalnie nawet niegrzeczne!) Rzeczy, aby ukryć te domyślne zależności, gdy nie są one jawnie przekazywane w momencie wywołania. ( Pamiętaj, że taki sam efekt, jak Lokalizator usług, jeśli jest używany w ten sposób!)
Wstrzykiwanie zależności, jako „dyscyplina”, jest naprawdę bardzo trudne do osiągnięcia. To nie jest kwestia używania DI, czy nie; chodzi o to, aby wiedzieć, które zależności mogą się zmienić lub wymagać kpienia z nich . A potem decyduje, czy DI pasuje lepiej niż jakaś alternatywa, na przykład lokalizacja usługi ...
Ale, ja zachęcam do google , może zobaczyć to, więc odpowiedź , ewentualnie skonsultować się z super-doświadczonych i udane deweloper w swojej branży, a konkretne przykłady dodaj do CR.SE .
źródło
Przeszukałem Google, Google Scholar, ACM i IEEE Oto artykuły, które udało mi się znaleźć:
Ramy zależności wtrysku: poprawa testowalności? . Argumentuje, że „testowalność” można zdefiniować jako „niską spójność”. Stwierdza, że DI prowadzi do niższej kohezji, niższa kohezja jest skorelowana z wyższym pokryciem testowym i że wyższy zasięg testowy jest skorelowany z większą liczbą znalezionych błędów. Mówi, że na tej podstawie DI poprawia testowalność.
Nie podoba mi się to z kilku powodów. Przede wszystkim mówi, że „A jest skorelowane z B, B jest skorelowane z C, więc A powoduje C”, co jest kilkoma krokami w logice, której nie uważam za dobrze poparte przez artykuł. Po drugie, przyznaje, że mierzy tylko „części testowalności” i że „testowalność” ogólnie nie jest czymś łatwym do zdefiniowania. Wreszcie, ich miara testowalności jest zdefiniowana w kategoriach liczby wstrzykniętych zależności!
Wpływ wstrzykiwania zależności na łatwość konserwacji . Porównują projekty korzystające z DI z projektami nie wykorzystującymi DI, które znaleźli w SourceForge i sprawdzają, czy istnieją jakiekolwiek różnice w wskaźnikach spójności. Aby zmniejszyć stronniczość, połączyli projekty, aby były jak najbardziej podobne. W końcu zobaczyli sygnały, że projekty z dużą ilością DI były nieco mniej sprzężone niż projekty z niewielką ilością DI. Wydaje się jednak, że nie było znaczącej różnicy w spójności między projektami DI i ich parami innymi niż DI, więc może to być konsekwencja określonych domen. Podają „brak korelacji” jako główny wynik, a „może to trochę pomaga?” jako temat do dalszych badań.
Empiryczna ocena wpływu wstrzykiwania zależności na rozwój aplikacji usług sieciowych . Streszczenie tak naprawdę nie wyjaśnia, czego szukają. Odkopałem i przeczytałem przedruk i, o ile mogę stwierdzić, w rzeczywistości dotyczy to tego, jak dobrze zautomatyzowane narzędzia mogą wykrywać usługi. Usługi napisane w stylu DI można łatwiej znaleźć. Cytuje także poprzednie badanie, które wymieniłem jako zapewniające empiryczny dowód, że DI zmniejsza sprzężenie, co jest przeciwieństwem tego, co twierdził ten artykuł.
W przypadku tych trzech artykułów (i Analizy empirycznej nad wykorzystaniem wstrzykiwania zależności w Javie , która dotyczy wyłącznie wykrywania) śledziłem wszystkie cytowane artykuły, z których żaden nie dotyczył określenia skuteczności DI. Biorąc to wszystko pod uwagę, jestem pewien, że nie , nie mamy jeszcze empirycznych dowodów na to, czy DI poprawia jakość oprogramowania.
źródło