Jag har utvecklat i Spring Boot i drygt ett år men har ännu inte förstått fördelarna med att använda en Autowired-konstruktör och jag undrade om någon kunde förklara detta för mig och vad som skulle anses vara bästa praxis.
Låt oss säga att jag har en böna enligt följande
@Component public class MyBean { void doSomeStuff() { } } Och jag har en tjänst som har ett beroende av den bönan
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } För mig är det enklaste sättet att injicera beroendet i den här klassen att helt enkelt kommentera variabeln med @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Men det finns andra platser online (och även andra utvecklare i mitt team) som gillar något liknande detta tillvägagångssätt:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } För mig är det bara redundant att använda en konstruktör som den. Autokoppling av bönan är mycket enklare och okomplicerat än vad som förefaller mig vara en pannkodskod.
Kommentarer
Svar
Du använder en verklig konstruktör av samma skäl som att du använder offentliga getters och setter istället för att göra privata variabler offentliga.
Några exempel från verkliga livet: mobiltelefoner är inte tillåtna på säkra, informationskänsliga fysiska platser. All kommunikation med den säkra platsen måste ske via ett säkert etablerat, kontrollerat och krypterat kommunikationsprotokoll, inte hemligt av en oövervakad och okontrollerad oseriös kommunikationskanal.
Vid en konsert tillåter du inte människor att kasta saker över staketet till någon som redan är på arenan. Allt som kommer in eller ut måste gå genom en grind.
Om det är allt som finns i ditt kodexempel, så verkar det som onödigt ordentligt panna. Men ofta gör vi andra saker i konstruktören förutom att ställa in privata variabler, som validering. I många programmeringsspråk är det en binär brytningsändring, att ändra sättet du gör detta på. så att tillhandahålla konstruktören framåt kan vara ett förnuftigt steg.
Slutligen bör klassen kunna fungera oberoende av beroendeinjektionen. Om du lägger till en kommentar till en privat medlem men inte kan inkludera en konstruktör , du ”har väsentligen bundit den klassen till DI-behållaren, och klassen kommer inte att fungera utan den.
Kommentarer
- " På en konsert tillåter du ' t tillåter människor att kasta saker över staketet till någon som ' s redan på stadion m. Allt som kommer in eller ut måste gå igenom en grind. " Men jag ser inte ' hur en konstruktör gör autokabeln säkrare? Om det inte fanns några konstruktorkrav (som validering), skulle det vara till nytta att använda en konstruktör?
- Du gör det möjligt att lägga till validering senare utan att bryta binär kompatibilitet.
- Också , notera att privata medlemmar verkligen borde förbli privata. Att ' är ganska hela poängen med att ha privata medlemmar.
- Hela poängen är att tillåta god praxis för design som är kompatibel med @Autowire. Att ha konstruktörer är det mest naturliga i OOP. Tvärtom, (vad du kallar enkelt och enklare) är ganska läskigt. Det finns inga verkliga fördelar med att ta bort konstruktörer, det finns ingen ' alls. Konstruktörer är bland de enklaste metoderna i OOP.I sig har de vanligtvis väldigt lite komplexitet som är värda att implementera magin i Spring IoC
- För vad det ' är, tenderar Java att vara en väldigt detaljerat språk ändå. Om du ' försöker tämja en del av det ordet, kommer det troligtvis inte att göra något för att eliminera konstruktörer.
To me, using a constructor like that is simply redundant code. Autowiring the bean is much simpler and straightforward than what appears to me to be boilerplate code.och är du inte orolig för magin med att injicera en böna i en instace-variabel som är privat och har ingen setter? Är du inte orolig för den enorma tekniska skulden som detta genererar dig, dina kollegor? Är du inte orolig för att vidarebefordra för mycket på vårens ' magiska paradigm istället för att utforma god praxis?