Wstrzykiwanie zależności - Spring

Jest taki przykład bez wstrzykiwania zależności:

class Car {
    //Concrete class
    private WinterTire tire = new WinterTire(195);

    void drive() {
        tire.turn();
    }

}

Jest taki przykład realizujący wstrzykiwanie zależności:

class Car {

    private Tire tire;

    Car(Tire tire) {
        this.tire = tire;
    }

    void drive() {
        tire.turn();
    }

}

Jak będzie wyglądał ten sam przykład, ale z wstrzykiwaniem zależności z użyciem springa i @Autowried?

Pewnie coś w tym stylu:

@Component
class Car {
 
    private Tire tire;
 
    @Autowired
    Car(Tire tire) {
        this.tire = tire;
    }
 
    void drive() {
        tire.turn();
    }
 
}

Edit: Z tym że zupełnie nie pamiętam, czy konstruktor musi być publiczny, czy może być tak jak masz w przykładzie o zasięgu paczki.

Jaki jest zatem tego sens? Niewielka różnica pod względem chociażby ilości kodu. Niewielkie zastosowanie czy podany przykład jest dość średni? Posiada ktoś może przykład, w którym widać będzie ewidentną korzyść z wstrzykiwania zależności w springu w stosunku do zwykłego?

@Warmix: generalnie jest to sprawa kontrowersyjna nieco, ale pod względem DI to Spring ma taką zalete ze jest łatwiej przy większym projekcie niż kilka czy kilkanaście klas. Aplikacje biznesowe mają przynajmniej kilkadziesiąt klas, a często dużo więcej i ławiej tak nimi zarządzac niż przez ręczne tworzenie modułów przez new. No i Spring umożliwia korzystanie z AOP.
Oczywiście nie twierdze że Springa nalezy zawsze używac bo Spring nie jest lekarstwem na wszysto :D

Zaletą jest to ze nie potrzebujesz trzeciej klasy która tworzy i łączy te obiekty. (Chociaż nie każdy uzna to za zaletę)

Jeden z talków na ten temat

1. Przykład jest bez sensu, bo nie wtrzykuje sie kontenerem obiektów w takim przypadku
2. Jeśli w ogóle to składa się w ten sposób infrastrukturę aplikacji, więc repozytoria, serwisy, kontrolery itd. Nie obiekty domenowe. Jeśli ktoś tworzy kontenerem jakiś obiekt Car i Tire a potem to sobie wstrzykuje, to jest obłąkany :D
3. Zaleta jest taka, że możesz sobie wygodnie wstrzyknąć choćby wszystkie implementacje jakiegoś interfejsu, nawet takie które dopiero ktoś dołożył do twojej aplikacji w postaci jakiegoś jara przed chwilą. Nie musisz też bawić się w takie rzeczy jak ręczne bawienie się w injectowanie properties, bo te też Spring sobie automagicznie znajdzie.

Cześć,

mój pierwszy post więc wpierw chciałbym przywitać Was wszystkich.

Jestem obecnie na etapie szukania nowego miejsca pracy i jest taka sytuacja że kolega mnie polecił do pewnej firmy i dał mi parę wskazówek co do rozmowy kwalifikacyjnej. No i tam wymienił parę tematów które trzeba umieć na blachę i w tym również Dependency Injection w Springu i trzeba zaznaczyć że wstrzykiwanie przez konstruktor to jedyne słuszne (albo minimum zalecane) podejście.

No i w tym miejscu przypomniało mi się że byłem kiedyś na szkoleniu zewnętrznym ze springa gdzie prowadzący wspomniał aby nigdy nie używać @Autowired na polach w kodzie produkcyjnym z wyjątkiem testów. Było to ze 2 lata temu, po 2 dniach szkolenia człowiek wrócił do rzeczywistości gdzie w projekcie @Autowired jest używane na potęgę na polach i w sumie ciekawa wiedza ze szkolenia wyparowała.

No ale teraz kiedy na nowo pojawił się ten temat to się zastanawiam jak wstrzykiwanie poprzez konstruktor współdziała ze Springiem. Dla mnie dotychczas Spring dawał tę wygodę że deklaruję pola odnosząc się do interfejsów, Spring mi ładnie wstrzykuje implementację i cyk fajnie, bez zapychania konstruktorów parametrami dla zależności, działa sobie automatycznie.

No ale teraz kiedy ja na rozmowach śpiewam o tym DI poprzez konstruktor to sam się zastanawiam czy oni na prawdę używają tego rodzaju wstrzykiwania w projekcie czy to może jest taka troche ściema i pytają o to aby wiedzieć że przynajmniej kandydat ma świadomość różnych sposobów DI w Springu (ze na polach, konstruktorach i setterach) i że przynajmniej w teorii to powinno się używać poprzez konstruktor.

Próbując sobie wyobrazić jak miałoby to wyglądać w większym projekcie to ciężko jest mi to ogarnąć, powiedzmy że mamy wiele klas, każda po kilka zależności, wszędzie wymóg przez konstruktor. I jak wtedy mamy dostarczyć tę instancję? Tworzyć za każdym razem nowa, poprzez jakąś Fabrykę? Zapewnić w ramach fabryki aby to była jedna instancja na sesje (od tego chyba jest Spring właśnie)?

Czy wy, zaczynając nowy projekt w Springu i mając za zadanie zdecydować, jaki rodzaj DI użyć to co bralibyście pod uwagę i dlaczego podjęlibyście taką a nie inną decyzję? Może stosować różne zależnie od problemu w danym fragmencie kodu?

Ogólnie mam wrażenie że jakbym trafił do tej firmy to by się okazało że używają @Autowired na polach i rozmowa rozmową ale rzeczywistość jest taka sama wszędzie, @Autowired się przyjęło na polach, działa, więc nie komplikujemy skoro spełniamy wymagania klienta.

@jarekr000000 film który podałeś oglądnę wieczorem, jeśli znajdę tam odp na moje pytania to super. Nie ukrywam że mimo tego chciałem trochę jeszcze rozruszać dyskusję i poznać wasze zdania na ten temat.

Nie znoszę żadnego Autowireda. Ale nawet wśród najgorszych Springowców od dawna (na pewno ze dwa lata) nie muszę się kłócić o to, że nie używamy field injection. W starych systemach są powoli przepisywane na konstruktory, albo Spring jest całkiem wywalany (paradoksalnie wygląda to prawie zupełnie tak samo w kodzie).