Czym dokładnie jest Field Injection i jak tego uniknąć?

Czytałem w niektórych postach o Spring MVC i Portletach, że iniekcja pola nie jest zalecana. Jak rozumiem, wstrzyknięcie pola ma miejsce, gdy wstrzykujesz Fasolę w @Autowirednastępujący sposób:

@Component
public class MyComponent {
    @Autowired
    private Cart cart;
}

W trakcie moich badań czytałem również o iniekcji konstruktora :

@Component
public class MyComponent {
    private final Cart cart;

    @Autowired
    public MyComponent(Cart cart){
       this.cart = cart;
    }
}

Jakie są zalety i wady obu tych typów zastrzyków?

EDYCJA 1: Ponieważ to pytanie jest oznaczone jako duplikat tego pytania, sprawdziłem je. Ponieważ nie ma żadnych przykładów kodu ani w pytaniu, ani w odpowiedziach, nie jest dla mnie jasne, czy zgaduję, jakiego typu wtrysku używam.

Rodzaje wtrysku

Istnieją trzy opcje wstrzykiwania zależności do fasoli:

1. Przez konstruktora
2. Poprzez setery lub inne metody
3. Poprzez refleksję bezpośrednio w pola

Używasz opcji 3. To właśnie się dzieje, gdy używasz @Autowiredbezpośrednio na swoim polu.

Wytyczne dotyczące wtrysku

Ogólne wytyczne, które są zalecane przez Spring (zobacz sekcje dotyczące DI opartego na konstruktorze lub DI opartego na seterze ) są następujące:

• W przypadku obowiązkowych zależności lub w przypadku dążenia do niezmienności należy użyć iniekcji konstruktora
• W przypadku zależności opcjonalnych lub zmiennych użyj iniekcji ustawiającej
• W większości przypadków należy unikać iniekcji w terenie

Wady iniekcji w terenie

Powody, dla których iniekcja w terenie jest niezadowolona, ​​są następujące:

• Nie można tworzyć niezmiennych obiektów, tak jak w przypadku iniekcji konstruktora
• Twoje zajęcia są ściśle powiązane z kontenerem DI i nie mogą być używane poza nim
• Nie można utworzyć wystąpienia klas (na przykład w testach jednostkowych) bez odbicia. Potrzebujesz kontenera DI, aby je utworzyć, co sprawia, że ​​testy bardziej przypominają testy integracji
• Twoje rzeczywiste zależności są ukryte z zewnątrz i nie są odzwierciedlone w interfejsie (ani konstruktorach, ani metodach)
• Naprawdę łatwo jest mieć około dziesięciu zależności. Gdybyś używał iniekcji konstruktora, miałbyś konstruktora z dziesięcioma argumentami, które sygnalizowałyby, że coś jest podejrzane. Ale możesz dodawać wstrzykiwane pola za pomocą wstrzykiwania pola przez czas nieokreślony. Posiadanie zbyt wielu zależności jest czerwoną flagą, że klasa zwykle robi więcej niż jedną rzecz i że może to naruszać zasadę pojedynczej odpowiedzialności.

Wniosek

W zależności od potrzeb należy przede wszystkim używać iniekcji konstruktora lub mieszanki iniekcji konstruktora i ustawiacza. Wstrzyknięcie w terenie ma wiele wad i należy go unikać. Jedyną zaletą wtrysku polowego jest to, że wygodniej jest pisać, co nie przeważa nad wszystkimi wadami.

Dalsza lektura

Napisałem artykuł na blogu o tym, dlaczego wstrzyknięcie pola zwykle nie jest zalecane: Wstrzyknięcie pola z zależnością uważane za szkodliwe .

Jest to jedna z niekończących się dyskusji na temat tworzenia oprogramowania, ale główni wpływowi w branży są coraz bardziej opiniowani na ten temat i zaczęli sugerować wstrzyknięcie konstruktora jako lepszą opcję.

Wstrzyknięcie konstruktora

Plusy:

• Lepsza testowalność . W testach jednostkowych nie potrzebujesz żadnej biblioteki symulującej ani kontekstu Spring. Możesz utworzyć obiekt, który chcesz przetestować za pomocą nowego słowa kluczowego. Takie testy są zawsze szybsze, ponieważ nie polegają na mechanizmie odbicia. ( To pytanie zostało zadane 30 minut później. Gdyby autor użył iniekcji konstruktora, to by się nie pojawiło).
• Niezmienność . Po ustawieniu zależności nie można ich zmienić.
• Bezpieczniejszy kod . Po wykonaniu konstruktora Twój obiekt jest gotowy do użycia, ponieważ możesz zweryfikować wszystko, co zostało przekazane jako parametr. Obiekt może być gotowy lub nie, nie ma stanu pomiędzy. W przypadku iniekcji w terenie wprowadzasz etap pośredni, gdy obiekt jest kruchy.
• Czystsze wyrażenie obowiązkowych zależności . Wstrzyknięcie polowe jest w tej kwestii niejednoznaczne.
• Sprawia, że ​​programiści myślą o projekcie . dit napisał o konstruktorze z 8 parametrami, co w rzeczywistości jest oznaką złego projektu i anty-wzorcem obiektu Boga . Nie ma znaczenia, czy klasa ma 8 zależności w swoim konstruktorze czy w polach, zawsze jest źle. Ludzie są bardziej niechętni do dodawania większej ilości zależności do konstruktora niż poprzez pola. Działa jako sygnał dla twojego mózgu, że powinieneś zatrzymać się na chwilę i pomyśleć o strukturze kodu.

Cons:

• Więcej kodu (ale nowoczesne IDE łagodzą ból).

Zasadniczo iniekcja w terenie jest odwrotna.

Kwestia gustu. To Twoja decyzja.

Ale mogę wyjaśnić, dlaczego nigdy nie używam wtrysku konstruktora .

1. Nie chcę, aby zaimplementować konstruktor dla wszystkich moich @Service, @Repositoryi @Controllerfasoli. To znaczy, jest około 40-50 ziaren lub więcej. Za każdym razem, gdybym dodawał nowe pole, musiałbym rozbudowywać konstruktora. Nie. Nie chcę tego i nie muszę.

2. A jeśli twoja fasola (usługa lub kontroler) wymaga wstrzyknięcia dużej ilości innych ziaren? Konstruktor z parametrami 4+ jest bardzo brzydki.

3. Jeśli używam CDI, konstruktor mnie nie dotyczy.

EDYCJA nr 1 : Vojtech Ruzicka powiedział:

class ma zbyt wiele zależności i prawdopodobnie narusza zasadę pojedynczej odpowiedzialności i powinien zostać zmieniony

Tak. Teoria i rzeczywistość. Oto przykład: DashboardControllermapowany do pojedynczej ścieżki *:8080/dashboard.

My DashboardControllerzbiera wiele informacji z innych usług, aby wyświetlić je na pulpicie nawigacyjnym / stronie przeglądu systemu. Potrzebuję tego pojedynczego kontrolera. Muszę więc zabezpieczyć tylko tę jedną ścieżkę (podstawowa autoryzacja lub filtr roli użytkownika).

EDYCJA nr 2 : Ponieważ wszyscy koncentrują się na 8 parametrach w konstruktorze ... To był przykład z prawdziwego świata - stary kod klienta. Zmieniłem to. Ta sama argumentacja dotyczy mnie dla parametrów 4+.

Chodzi o wstrzyknięcie kodu, a nie o budowę instancji.

Jeszcze jedna uwaga - Vojtech Ruzicka stwierdził, że Wiosna wstrzykuje fasolę na trzy sposoby (odpowiedź z największą liczbą punktów):

1. Przez konstruktora
2. Poprzez setery lub inne metody
3. Poprzez refleksję bezpośrednio w pola

Ta odpowiedź jest ZŁA - ponieważ DLA KAŻDEGO RODZAJU SPRĘŻYNY WTRYSKU WYKORZYSTUJE ODBLASK! Użyj środowiska IDE, ustaw punkt przerwania w programie ustawiającym / konstruktorze i sprawdź.

Może to być kwestia gustu, ale może to być również kwestia przypadku. @dieter zapewnił doskonały przypadek, gdy wtrysk w terenie jest lepszy. Jeśli używasz iniekcji pola w testach integracyjnych, które konfigurują kontekst Springa - argument z testowalnością klasy również jest niepoprawny - chyba że chcesz później pisać o testach do swoich testów integracyjnych;)