Spisie treści
Jest to czwarta część serii samouczków skoncentrowanych na omówieniu podstawowych tematów języka Java, aby przygotować czytelnika do korzystania ze Spring Framework. Pierwszą część tej serii samouczków można uzyskać tutaj, drugą część tutaj, a trzecią część tutaj. W tym samouczku zobaczymy 2 podstawowe pojęcia, z którymi musimy się uporać, jeśli chcemy poprawnie używać Springa: Inversion of Control i Dependency Injection.Przede wszystkim chcę wyjaśnić, że te koncepcje są znacznie lepiej wyjaśnione przez Martina Fowlera w tym artykule i przetłumaczone na język hiszpański na tej stronie, ale moim zamiarem jest próba podsumowania koncepcji, aby była łatwo zrozumiała i oszczędziła ci trochę czytania artykuł (choć serdecznie zapraszam do lektury, jeśli masz więcej pytań).
Termin jest stosunkowo nowy, ale jest to wzorzec programowania, który sięga tych programów stworzonych przy użyciu czystego programowania sekwencyjnego, w których pojedynczy programista (lub grupa programistów) usiadł, aby napisać serię kroków lub instrukcji obliczeniowych, które należy wykonać w idealnym sekwencja od początku do końca z zamiarem uzyskania ostatniego wyniku.
W tym czasie (nie myśl, że to było wiele lat temu) wywołania metod i bibliotek zawsze pochodziły z centralnego źródła, które było odpowiedzialne za manipulowanie wszystkimi zmiennymi w tym samym programie. Później opracowano interfejsy graficzne, które były odpowiedzialne za zarządzanie danymi wejściowymi do programu, podczas gdy główny przepływ programu był odpowiedzialny za zapewnienie obsługi zdarzeń, które wystąpiły w interfejsie graficznym (aktywuje coś po kliknięciu, naciśnięciu tego klawisza , poruszanie myszą itp.), gdy interfejs jest w ciągłej pętli. W ten sposób kontrola nad programem jest odwrócona, interfejs graficzny jest odpowiedzialny za powiadamianie głównego przepływu o tym, co i jak robić, bez konieczności dokładnego poznania JAK to się robi.
Jeśli zauważysz, interfejsy w Javie mogą pomóc w przekazaniu kontroli nad aplikacją do agentów zewnętrznych, ale koncepcja ta ma zastosowanie do wątków demonów, które czekają na uruchomienie zdarzenia, klasy, która jest odpowiedzialna za tworzenie instancji i dostarczanie implementacji innych klas do program (wzorzec fabryczny) i zasadniczo każdy wzorzec, który umożliwia przekazanie kontroli nad programem do jakiegoś agenta zewnętrznego.
Jest to szczególny rodzaj Inversion of Control, w którym klasa A nie wie, jakiego obiektu będzie używać w momencie kompilacji, a jedynie wie, jakie działania musi wykonać z tym obiektem. Załóżmy następującą klasę (która bazuje na klasach utworzonych w moim poprzednim tutorialu):
klasa publiczna Rysownik {public Square Square; publiczny rysownik () {kwadrat = nowy kwadrat (); } public void MasterDraw () {square.Draw (); }} Jak zobaczysz, ta klasa „Rysownika” zależy całkowicie od klasy „Kwadrat”, ponieważ odpowiada za cykl życia obiektu kwadratowego, którego będzie później używał. Ten sposób tworzenia klasy „Drafsman” jest bardzo niepraktyczny, ponieważ jeśli później chcielibyśmy, aby rysownik rysował prostokąty lub trójkąty, musielibyśmy w tym celu zmodyfikować kod bazowy.
Zamiast tego możemy stworzyć klasę, którą można ponownie wykorzystać, jeśli zaimplementujemy interfejs „Drawable”, który stworzyliśmy w poprzednim samouczku:
public class Rysownik {publiczny rysunek do rysowania; publiczny rysownik (drawable d) {rysunek = d; } public void MasterDrawing () {rysunek.Rysunek (); }} W ten sposób obiekty klasy „Drafsman” nie „kontrolują” obiektu, który mają narysować, a jedynie wiedzą, że implementuje interfejs Drawable, a później te obiekty „Drafsman”, które stworzę w swojej aplikacji lub że ktoś w przeciwnym razie zostaną użyte w aplikacji, która uzyskuje dostęp do mojej biblioteki obiektów, są one doskonale zdolne do odbierania dowolnego obiektu, który implementuje interfejs „Drawable”.
W poprzednim przykładzie stosujemy to, co jest znane jako „Iniekcja Konstruktorów” ponieważ zależność jest wstrzykiwana na poziomie konstruktora, ale można również wstrzykiwać zależność poprzez "Setters" lub, w innych językach programowania, można wstrzykiwać parametry lub interfejsy (w Javie nie można modyfikować parametrów ani interfejsów, które akceptują metoda w czasie wykonywania, ale na przykład Python pozwala metodom akceptować parametry bez określania typu parametrów.)
public class Rysownik {publiczny rysunek do rysowania; public void setDrawing (Drawable d) {rysunek = d; } public void MasterDrawing () {rysunek.Rysunek (); }} ten wstrzykiwanie zależności zasadniczo pozwala na oddzielenie funkcjonalności Twojego programu. Ta niezależność pozwala ci testować twoje klasy bez (warto powtarzać) twojej klasy z czymkolwiek. Ta niezależność jest jednym z kluczowych elementów do wykorzystania Wiosna, komponenty zależą od frameworka, a nie od aplikacji, możesz tworzyć obiekty, które istnieją poza Twoją aplikacją i używać ich tylko wtedy, gdy ich potrzebujesz.
Od następnego samouczka zaczniemy bezpośrednio pracować z Springiem, a zobaczysz, jak wszystkie koncepcje, które do tej pory widzieliśmy, są powiązane z jego działaniem i pozwolą Ci w krótkim czasie zdobyć niezbędną wiedzę.
Czekam na Wasze komentarze, do następnego razu!Podobał Ci się i pomógł ten samouczek?Możesz nagrodzić autora, naciskając ten przycisk, aby dać mu pozytywny punkt
