Inhoudsopgave
Dit is het vierde deel van een reeks tutorials die gericht zijn op het herzien van de basisonderwerpen van de Java-taal om de lezer voor te bereiden op het gebruik van het Spring Framework. Het eerste deel van deze tutorialserie is hier te verkrijgen, het tweede deel hier en het derde deel hier. In deze tutorial zullen we 2 basisconcepten zien waarmee we moeten omgaan als we Spring correct willen gebruiken: Inversion of Control en Dependency Injection.Allereerst wil ik verduidelijken dat deze concepten veel beter zijn uitgelegd door Martin Fowler in dit artikel en op deze pagina in het Spaans zijn vertaald, maar het is mijn bedoeling om te proberen het concept samen te vatten om het gemakkelijk begrijpelijk te maken en u een beetje lezen te besparen. artikel (hoewel u van harte wordt uitgenodigd om het te lezen als u meer vragen heeft).
De term is relatief recent, maar het is een programmeerpatroon dat teruggaat naar die programma's die zijn gemaakt met behulp van pure sequentiële programmering, waarbij een enkele programmeur (of een groep programmeurs) ging zitten om een reeks stappen of computationele instructies te schrijven die perfect moesten worden uitgevoerd. volgorde van begin tot eind met de bedoeling een laatste resultaat te behalen.
Op dit moment (denk niet dat het vele jaren geleden is) kwamen de oproepen naar de methoden en bibliotheken altijd van een centrale bron die verantwoordelijk was voor het manipuleren van alle variabelen in hetzelfde programma. Later werden grafische interfaces ontwikkeld die verantwoordelijk waren voor het beheer van de gegevensinvoer naar het programma, terwijl de hoofdstroom van het programma verantwoordelijk was voor het leveren van handlers voor de gebeurtenissen die plaatsvonden in de grafische interface (activeert iets bij het klikken, drukken op deze toets , het bewegen van de muis, enz.) terwijl de interface zich in een constante lus bevindt. Op deze manier wordt de besturing van het programma omgekeerd, de grafische interface is verantwoordelijk voor het informeren van de hoofdstroom over wat te doen en hoe zonder precies te hoeven weten HOE het wordt gedaan.
Als u merkt dat interfaces in Java u kunnen helpen de controle over een toepassing over te dragen aan externe agenten, is het concept van toepassing op daemon-threads die wachten tot een gebeurtenis wordt geactiveerd, een klasse die verantwoordelijk is voor het starten en leveren van implementaties van andere klassen aan het programma (fabriekspatroon) en in wezen elk patroon waarmee de controle over het programma naar een externe agent kan worden overgedragen.
Het is een bepaald type Inversion of Control waarbij een klasse A op het moment van compileren niet weet welk object het gaat gebruiken, maar alleen de acties weet die het met dat object moet ondernemen. Laten we de volgende klasse aannemen (die is gebaseerd op de klassen die in mijn vorige zelfstudie zijn gemaakt):
openbare klasse Tekenaar {plein plein; openbare Cartoonist () {vierkant = nieuw vierkant (); } public void MasterDraw () {square.Draw (); }} Zoals u zult zien, hangt deze klasse "Draftsman" volledig af van de klasse "Square", aangezien deze verantwoordelijk is voor de levenscyclus van het vierkante object dat het later zal gebruiken. Deze manier om een "Draftsman"-klasse te maken is erg onpraktisch, want als we later wilden dat de Draftsman rechthoeken of driehoeken zou tekenen, zouden we de basiscode moeten aanpassen om dit te doen.
In plaats daarvan kunnen we een meer herbruikbare klasse maken als we de "Tekenbare" interface implementeren die we in de vorige zelfstudie hebben gemaakt:
openbare klasse Tekenaar {openbare Tekenbare tekening; openbaar Tekenaar (Tekenbaar d) {tekening = d; } public void MasterDrawing () {drawing.Drawing (); }} Op deze manier "controleren" de objecten van de klasse "Draftsman" niet het object dat ze moeten tekenen, maar weten ze alleen dat het de Drawable-interface implementeert en, later, deze "Draftsman" -objecten die ik in mijn toepassing zal maken of die iemand anders gaat worden gebruikt in een toepassing die toegang heeft tot mijn objectbibliotheek, ze zijn perfect in staat om elk object te ontvangen dat de "Tekenbare" interface implementeert.
In het vorige voorbeeld passen we toe wat bekend staat als "Constructor Inyection" aangezien de afhankelijkheid op constructorniveau wordt geïnjecteerd, maar u kunt de afhankelijkheid ook injecteren via de "Setters" of, in andere programmeertalen, u kunt de parameters of de interfaces injecteren (in Java kunt u de parameters of de interfaces die een methode tijdens runtime, maar Python staat bijvoorbeeld toe dat methoden parameters accepteren zonder het type parameters op te geven.)
openbare klasse Tekenaar {openbare Tekenbare tekening; public void setDrawing (tekenbare d) {tekening = d; } public void MasterDrawing () {drawing.Drawing (); }} De afhankelijkheid injectie maakt in wezen een scheiding van de functionaliteiten van uw programma mogelijk. Die onafhankelijkheid stelt je in staat om je lessen te testen zonder (voor herhaling vatbaar) dat je klas ergens aan gebonden is. Deze onafhankelijkheid is een van de belangrijkste onderdelen om te gebruiken De lente, de componenten zijn afhankelijk van het framework en niet van de applicatie, u kunt objecten maken die buiten uw applicatie bestaan en deze alleen gebruiken wanneer u ze nodig hebt.
Vanaf de volgende tutorial gaan we direct met Spring aan de slag en je zult zien hoe alle concepten die we tot nu toe hebben gezien, verband houden met de werking ervan en je in staat stellen om in korte tijd de nodige expertise op te doen.
Ik wacht op uw opmerkingen, tot de volgende keer!Vond je deze Tutorial leuk en heb je eraan geholpen?Je kunt de auteur belonen door op deze knop te drukken om hem een positief punt te geven
