Innehållsförteckning
Detta är den fjärde delen av en serie självstudier som fokuserar på att granska de grundläggande ämnena i Java -språket för att förbereda läsaren i användningen av Spring Framework. Den första delen av denna handledningsserie kan erhållas här, den andra delen kan erhållas här och den tredje delen här. I denna handledning kommer vi att se 2 grundläggande begrepp som vi måste hantera om vi vill använda Spring korrekt: Inversion of Control and Dependency Injection.Först och främst vill jag förtydliga att dessa begrepp förklaras mycket bättre av Martin Fowler i den här artikeln och översätts till spanska på denna sida men min avsikt är att försöka sammanfatta konceptet för att göra det lätt att förstå och spara dig lite läsning av artikel (även om du är hjärtligt inbjuden att läsa den om du har fler frågor).
Termen är relativt ny, men det är ett programmeringsmönster som går tillbaka till de program som skapats med ren sekventiell programmering, där en enda programmerare (eller grupp av programmerare) satte sig ner för att skriva en serie steg eller beräkningsinstruktioner som ska utföras i perfekt skick från början till slut med avsikt att få ett sista resultat.
Vid den här tiden (tror inte att det var många år sedan) kom samtalen till metoderna och biblioteken alltid från en central källa som hade hand om att manipulera alla variabler i samma program. Senare utvecklades grafiska gränssnitt som var ansvariga för att hantera datainmatningarna till programmet, medan programmets huvudflöde ansvarade för att tillhandahålla hanterare för händelser som inträffade i det grafiska gränssnittet (aktiverar något när du klickar, trycker på den här knappen , flytta musen, etc.) medan gränssnittet är i en konstant slinga. På detta sätt är kontrollen av programmet omvänd, det grafiska gränssnittet ansvarar för att meddela huvudflödet om vad man ska göra och hur utan att behöva veta exakt HUR det görs.
Om du märker kan gränssnitt i Java hjälpa dig att överföra kontrollen över en applikation till externa agenter, men konceptet är tillämpligt på demonstrådar som väntar på att en händelse ska inträffa, en klass som är ansvarig för att initiera och leverera implementeringar av andra klasser till programmet (fabriksmönster) och i princip alla mönster som gör det möjligt att överföra kontroll av programmet till någon extern agent.
Det är en särskild typ av inversion av kontroll där en klass A inte vet vilket objekt den kommer att använda vid sammanställningen, utan bara vet vilka åtgärder den måste vidta med det objektet. Låt oss anta följande klass (som är baserad på klasserna som skapades i min tidigare handledning):
offentlig klass Tecknare {public Square square; offentlig tecknare () {square = new Square (); } public void MasterDraw () {square.Draw (); }} Som du kommer att se beror denna "Tecknare" -klass helt och hållet på "Kvadrat" -klassen eftersom den är ansvarig för livscykeln för det fyrkantiga objektet som den senare kommer att använda. Detta sätt att skapa en "Tecknare" -klass är mycket opraktiskt eftersom om vi senare ville att Tecknaren skulle rita rektanglar eller trianglar skulle vi behöva ändra grundkoden för att göra det.
Istället kan vi skapa en mer återanvändbar klass om vi implementerar gränssnittet "Drawable" som vi skapade i föregående självstudie:
public class Tecknare {public Drawable drawing; offentlig föredragande (ritbar d) {ritning = d; } public void MasterDrawing () {drawing.Drawing (); }} På detta sätt "styr" inte objekten i "Tecknaren" -objektet de måste rita utan vet bara att det implementerar Drawable -gränssnittet och senare dessa "Tecknare" -objekt som jag kommer att skapa i min applikation eller att någon annars går det att användas i ett program som har åtkomst till mitt objektbibliotek, de är perfekt kapabla att ta emot alla objekt som implementerar "Drawable" -gränssnittet.
I föregående exempel tillämpar vi det som kallas "Konstruktörinspektion" eftersom beroendet injiceras på konstruktornivå men du kan injicera beroendet också via "Setters" eller på andra programmeringsspråk kan du injicera parametrarna eller gränssnitten (I Java kan du inte ändra parametrarna eller gränssnitten som accepterar en metod vid körtid, men Python tillåter till exempel metoder att acceptera parametrar utan att ange parametrarnas typ.)
public class Tecknare {public Drawable drawing; public void setDrawing (Drawable d) {drawing = d; } public void MasterDrawing () {drawing.Drawing (); }} De beroendeinjektion tillåter i huvudsak en åtskillnad mellan programmets funktioner. Det självständigheten gör att du kan testa dina klasser utan att (värt att upprepa) din klass vara bunden till någonting. Denna oberoende är en av de viktigaste delarna att använda Vår, komponenterna beror på ramverket och inte på applikationen, du kan skapa objekt som finns utanför din applikation och bara använda dem när du behöver dem.
Från nästa handledning kommer vi att börja arbeta direkt med Spring och du kommer att se hur alla de koncept som vi har sett hittills är relaterade till dess drift och gör att du kan skaffa dig nödvändig expertis på kort tid.
Jag väntar på dina kommentarer, tills nästa gång!Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng
