Olen lukenut paljon selityksiä riippuvuuden injektiosta tai DI: stä (tunnettiin aiemmin nimellä Inversion of Control) ja siihen liittyvästä Hollywoodin periaatteesta ("Älä soita meille, soitamme sinulle".). Ne kaikki ovat yleensä epäselviä, joko siksi, että he syventyvät välittömästi erittäin yksityiskohtaisiin selityksiin, tai sitovat selityksen nimenomaan yhteen tiettyyn tekniikkaan. Sellainen, että joko kuvio menetetään tai sen yksinkertaisuus on. Tässä on selvin selitys, jonka löysin - hieman muokattu lyhyyden vuoksi (erittäin hyvältä Spring in Action, 2. toim., Craig Walls):
"Mikä tahansa ei-triviaalinen sovellus koostuu kahdesta tai useammasta luokasta, jotka tekevät yhteistyötä toistensa kanssa jonkin liiketoimintalogiikan suorittamiseksi. Perinteisesti kukin objekti on vastuussa omien viitteiden hankkimisesta kohteisiin, joiden kanssa hän tekee yhteistyötä (riippuvuuksista). kohteille annetaan riippuvuudet luomisajankohtana joku ulkoinen yksikkö, joka koordinoi kutakin järjestelmän objektia. Toisin sanoen riippuvuudet injektoidaan esineisiin. "
Minusta se on hyvin selvää.
Riippuvuusinjektiota kutsuttiin alun perin ohjausinversioksi (IoC), koska normaali säätösekvenssi olisi objekti, joka löytää itsestään riippuvat objektit ja kutsuu ne sitten. Tässä tämä päinvastainen: riippuvuudet luovutetaan objektille, kun se luodaan. Tämä havainnollistaa myös Hollywoodin periaatetta työssä: Älä ota yhteyttä riippuvuuksiisi, annamme ne sinulle, kun tarvitsemme sinua.
Jos et käytä DI: tä, mietit todennäköisesti miksi se on iso juttu. Se tarjoaa tärkeän edun: löysä kytkentä. Objektit voidaan lisätä ja testata muista objekteista riippumatta, koska ne eivät ole riippuvaisia mistään muusta kuin siitä, minkä ohitat ne. Kun käytät perinteisiä riippuvuuksia, objektin testaamiseksi sinun on luotava ympäristö, jossa kaikki sen riippuvuudet ovat olemassa ja tavoitettavissa, ennen kuin voit testata sitä. DI: n avulla on mahdollista testata kohdetta erillään, jolloin se pilkkaa esineitä niistä, joita et halua tai joita sinun ei tarvitse luoda. Samoin luokan lisääminen projektiin helpottuu, koska luokka on itsenäinen, joten näin vältetään "iso hiuspallo", josta suuret projektit usein kehittyvät.
DI: n haaste on koko sovelluksen kirjoittaminen sitä käyttäen. Muutama luokka ei ole iso juttu, mutta koko sovellus on paljon vaikeampaa. Koko sovelluksille haluat usein kehyksen riippuvuuksien ja objektien välisen vuorovaikutuksen hallitsemiseksi. DI-kehyksiä ohjaavat usein XML-tiedostot, jotka auttavat määrittämään, mitä kenelle ja milloin välitetään. Kevät on täyden palvelun Java DI -kehys; muita kevyempiä DI-kehyksiä ovat NanoContainer ja vielä kevyempi PicoContainer.
Suurimmalla osalla näistä kehyksistä on hyvät opetusohjelmat, jotka auttavat aloittelijoita löytämään tiensä.
Tämän tarinan "Erinomainen riippuvuuden injektion selitys (hallinnan kääntäminen)" julkaisi alun perin JavaWorld.
