Инверсия на контрол и инжектиране на зависимости в Java / Spring

Съдържание
Това е четвъртата част от поредицата уроци, насочени към преглед на основните теми на езика Java, за да подготвят читателя за използването на Spring Framework. Първата част от тази серия уроци може да бъде получена тук, втората част можете да намерите тук, а третата част тук. В този урок ще видим 2 основни концепции, с които трябва да се справим, ако искаме да използваме Spring правилно: Инверсия на контрола и инжектиране на зависимости.
Първо, искам да поясня, че тези понятия са много по -добре обяснени от Мартин Фаулър в тази статия и преведени на испански на тази страница, но намерението ми е да се опитам да обобщя концепцията, за да я направя лесно разбираема и да ви спести малко четене на статия (въпреки че сте сърдечно поканени да я прочетете, ако имате още въпроси).
Терминът е сравнително скорошен, но това е модел на програмиране, който се връща към онези програми, създадени с чисто последователно програмиране, където един програмист (или група програмисти) седна да напише поредица от стъпки или изчислителни инструкции, които да бъдат изпълнени перфектно от началото до края с намерението да се получи последен резултат.
По това време (не мислете, че беше преди много години) извикванията към методите и библиотеките винаги идваха от централен източник, който отговаряше за манипулирането на всички променливи в една и съща програма. По -късно бяха разработени графични интерфейси, които отговаряха за управлението на входовете на данни в програмата, докато основният поток на програмата беше отговорен за предоставянето на манипулатори за събитията, настъпили в графичния интерфейс (активира нещо при щракване, натискане на този клавиш , преместване на мишката и т.н.), докато интерфейсът е в постоянен цикъл. По този начин управлението на програмата се обръща, графичният интерфейс отговаря за уведомяването на основния поток какво да се прави и как, без да е необходимо да се знае как точно се прави.
Ако забележите, интерфейсите в Java могат да ви помогнат да прехвърлите контрола върху дадено приложение към външни агенти, но концепцията е приложима за демонови нишки, които чакат да се случи събитие, клас, който е отговорен за създаването и предоставянето на реализации на други класове на програмата (фабричен модел) и по същество всеки модел, който позволява предаване на контрол на програмата към някакъв външен агент.
Това е определен тип инверсия на управление, при който клас А не знае кой обект ще използва в момента на компилиране, а знае само действията, които трябва да предприеме с този обект. Да приемем следния клас (който се основава на класовете, създадени в предишния ми урок):
 чертожник на публична класа {площад на обществения площад; обществен карикатурист () {квадрат = нов квадрат (); } public void MasterDraw () {square.Draw (); }} 

Както ще видите, този клас "Draftsman" зависи изцяло от класа "Square", тъй като той отговаря за жизнения цикъл на квадратния обект, който по -късно ще използва. Този начин на създаване на клас "Draftsman" е много непрактичен, защото ако по -късно искахме Draftsman да нарисува правоъгълници или триъгълници, ще трябва да променим базовия код, за да го направим.
Вместо това можем да създадем клас за многократна употреба, ако внедрим интерфейса "Drawable", който създадохме в предишния урок:
 чертеж на публична класа {public Drawable drawing; публичен чертожник (Drawable d) {чертеж = d; } публична невалидна MasterDrawing () {drawing.Drawing (); }} 

По този начин обектите от класа "Draftsman" не "контролират" обекта, който трябва да нарисуват, а знаят само, че той реализира Drawable интерфейса и по -късно тези "Draftsman" обекти, които ще създам в моето приложение или че някой else ще се използва в приложение, което има достъп до моята библиотека с обекти, те са напълно способни да приемат всеки обект, който реализира интерфейса "Drawable".
В предишния пример ние прилагаме това, което е известно като "Конструктор Inyection" тъй като зависимостта се инжектира на ниво конструктор, но можете да инжектирате зависимостта и чрез "Setters" или, на други езици за програмиране, можете да инжектирате параметрите или интерфейсите (В Java не можете да променяте параметрите или интерфейсите, които приемат метод по време на изпълнение, но Python например позволява на методите да приемат параметри, без да посочват типа на параметрите.)
 чертеж на публична класа {public Drawable drawing; public void setDrawing (Drawable d) {draw = d; } публична невалидна MasterDrawing () {drawing.Drawing (); }} 

The инжектиране на зависимост по същество позволява разделяне на функционалностите на вашата програма. Тази независимост ви позволява да тествате вашите класове, без (струва си да се повтаря), че вашият клас е обвързан с нищо. Тази независимост е една от ключовите части, които трябва да се използват Пролет, компонентите зависят от рамката, а не от приложението, можете да създавате обекти, които съществуват извън приложението ви и да ги използвате само когато имате нужда от тях.
От следващия урок ще започнем да работим директно с Spring и ще видите как всички концепции, които видяхме досега, са свързани с работата му и ще ви позволят да придобиете необходимия опит за кратко време.
Очаквам вашите коментари, до следващия път!Хареса ли ви и помогнахте на този урок?Можете да възнаградите автора, като натиснете този бутон, за да му дадете положителна точка

Така ще помогнете за развитието на сайта, сподели с приятелите си

wave wave wave wave wave