Отлично обяснение на инжектирането на зависимост (инверсия на контрола)

Прочетох много обяснения за Dependency Injection или DI (по-рано известен като Inversion of Control) и свързания с тях Холивудски принцип („Не ни се обаждайте, ние ще ви се обаждаме“.) Всички те са склонни да бъдат неясни, или защото незабавно се задълбочават в много подробни обяснения, или обвързват обяснението конкретно с определена технология. Така, че или шаблонът се губи, или простотата му е. Ето най-ясното обяснение, което намерих - леко редактирано за краткост (от много добрата Spring in Action, 2nd. Ed. От Craig Walls):

"Всяко нетривиално приложение се състои от два или повече класа, които си сътрудничат помежду си, за да изпълняват някаква бизнес логика. Традиционно всеки обект е отговорен за получаване на собствени препратки към обектите, с които си сътрудничи (неговите зависимости). обектите получават своите зависимости по време на създаването от някакъв външен обект, който координира всеки обект в системата. С други думи, зависимостите се инжектират в обекти. "

Намирам това за много ясно.

Injection на зависимостите първоначално се нарича Inversion of Control (IoC), тъй като нормалната контролна последователност би била обектът сам да открива обектите, от които зависи и след това да ги извиква. Тук това е обърнато: зависимостите се предават на обекта, когато е създаден. Това също илюстрира холивудския принцип в работата: Не се обаждайте за вашите зависимости, ние ще ви ги дадем, когато имате нужда от вас.

Ако не използвате DI, вероятно се чудите защо е голяма работа. Той осигурява ключово предимство: хлабав съединител. Обектите могат да се добавят и тестват независимо от други обекти, защото те не зависят от нищо друго освен от това, което им подавате. Когато използвате традиционни зависимости, за да тествате обект, трябва да създадете среда, където всички негови зависимости съществуват и са достъпни, преди да можете да го тествате. С DI е възможно да тествате обекта изолирано, предавайки му фалшиви обекти за тези, които не искате или трябва да създадете. По същия начин добавянето на клас към проект се улеснява, тъй като класът е самостоятелен, така че това избягва „голямата космена топка“, в която често се развиват големите проекти.

Предизвикателството на DI е да напише цяло приложение, използвайки го. Няколко класове не са голяма работа, но цялото приложение е много по-трудно. За цели приложения често искате рамка за управление на зависимостите и взаимодействията между обектите. DI рамките често се управляват от XML файлове, които помагат да се определи какво да се предава на кого и кога. Spring е Java DI рамка с пълен набор от услуги; други по-леки DI рамки включват NanoContainer и още по-лекия PicoContainer.

Повечето от тези рамки имат добри уроци, които да помогнат на начинаещите да намерят своя път.

Тази история „Отлично обяснение на инжектирането на зависимост (инверсия на контрола)“ първоначално е публикувана от JavaWorld.