Ik ontwikkel nu iets meer dan een jaar in Spring Boot, maar ik moet de voordelen van het gebruik van een Autowired-constructor nog niet begrijpen en ik vroeg me af of iemand dat zou kunnen leg me dit uit en wat als best practice wordt beschouwd.
Laten we zeggen dat ik als volgt een boon heb
@Component public class MyBean { void doSomeStuff() { } } En ik heb een service die afhankelijk is van die bean
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Voor mij zou de eenvoudigste manier om de afhankelijkheid in deze klasse te injecteren, zijn om de variabele simpelweg te annoteren met @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Maar er zijn andere plaatsen online (en ook andere ontwikkelaars in mijn team) die zoiets als deze benadering prefereren:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Voor mij is het gebruik van zon constructor gewoon overtollige code. Het automatisch bedraden van de boon is veel eenvoudiger en duidelijker dan wat mij de standaardcode lijkt.
Opmerkingen
Antwoord
Je gebruikt een echte constructeur om dezelfde redenen dat u openbare getters en setters gebruikt in plaats van privévariabelen openbaar te maken.
Enkele praktijkvoorbeelden: gsms zijn niet toegestaan op veilige, informatiegevoelige fysieke locaties. Elke communicatie met die beveiligde locatie moet plaatsvinden via een veilig ingesteld, gecontroleerd en gecodeerd communicatieprotocol, niet stiekem via een niet-gecontroleerd en ongecontroleerd frauduleus communicatiekanaal.
Bij een concert mag je mensen niet toestaan om gooi dingen over het hek naar iemand die al in het stadion is. Alles wat binnenkomt of eruit komt, moet door een poort gaan.
Als dat alles is wat er is met uw codevoorbeeld, dan ziet het eruit als een onnodig uitgebreide boilerplate. Maar vaak doen we andere dingen in de constructor dan het instellen privévariabelen, zoals validatie. In veel programmeertalen is het veranderen van de manier waarop u dit achteraf doet een binaire wijziging, dus het vooraf verstrekken van de constructor kan een verstandige stap zijn.
Ten slotte zou de klasse onafhankelijk van de afhankelijkheidsinjectie moeten kunnen functioneren. Als je een annotatie op een privélid plaatst, maar geen constructor opneemt , je “hebt die klasse in wezen nauw verbonden met de DI-container, en de klasse zal” niet werken zonder.
Opmerkingen
- ” Bij een concert mag je ‘ niet toestaan dat mensen dingen over het hek gooien naar iemand die ‘ s al in de stadiu m. Alles wat binnenkomt of eruit komt, moet door een poort gaan. ” Maar ik kan ‘ niet zien hoe het gebruik van een constructor de automatische bedrading veiliger maakt? Als er geen constructorvereisten waren (zoals validatie), zou het dan van voordeel zijn om een constructor te gebruiken?
- Je maakt het mogelijk om later validatie toe te voegen zonder de binaire compatibiliteit te verbreken.
- Ook , merk op dat privé-leden eigenlijk privé moeten blijven. Dat ‘ is eigenlijk het hele punt van het hebben van privé-leden.
- Het hele punt is het toestaan van goede ontwerppraktijken die compatibel zijn met @Autowire. Het hebben van constructeurs is de meest natuurlijke zaak in OOP. Het tegendeel, (wat je eenvoudig en eenvoudiger noemt) is een beetje eng. Er zijn geen echte voordelen bij het verwijderen van constructors, er is geen enkele eenvoud van ‘. Constructors behoren tot de meest eenvoudige methoden in OOP.Op zich hebben ze meestal weinig complexiteit die de moeite waard is om de magie van Spring IoC te implementeren.
- Voor wat het ‘ waard is, is Java meestal een hoe dan ook zeer uitgebreide taal. Als je ‘ op zoek bent om iets van die breedsprakigheid te temmen, zal het elimineren van constructeurs waarschijnlijk niet veel uitmaken.
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.en maak je je geen zorgen over de magie van het injecteren van een boon in een instace-variabele die privé is en geen setter heeft? Maakt u zich geen zorgen over de enorme technische schuld die dit bij u, uw collegas, veroorzaakt? Maakt u zich geen zorgen over het doorgeven van teveel over het magische paradigma van Spring ‘ in plaats van goede ontwerppraktijken?