Estou desenvolvendo no Spring Boot há pouco mais de um ano, mas ainda não entendi os benefícios de usar um construtor Autowired e queria saber se alguém poderia explique isso para mim e o que seria considerado a prática recomendada.
Digamos que eu tenha um bean da seguinte maneira
@Component public class MyBean { void doSomeStuff() { } } E eu tenho um serviço que tem uma dependência desse bean
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Para mim, a maneira mais simples de injetar a dependência nesta classe seria simplesmente anotar a variável com @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Mas há outros lugares online (e também outros desenvolvedores em minha equipe) que favorecem algo como esta abordagem:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Para mim, usar um construtor como esse é simplesmente código redundante. Autowiring o bean é muito mais simples e direto do que o que me parece ser um código clichê.
Comentários
Resposta
Você usa um construtor real pelos mesmos motivos que você usa getters e setters públicos em vez de tornar as variáveis privadas públicas.
Alguns exemplos da vida real: telefones celulares não são permitidos em locais físicos seguros e sensíveis a informações. Qualquer comunicação com esse local seguro deve ocorrer por meio de um protocolo de comunicação estabelecido com segurança, controlado e criptografado, não sub-repticiamente por um canal de comunicação desonesto não monitorado e não controlado.
Em um show, você não permite que as pessoas jogar coisas por cima do muro para alguém que já está no estádio. Qualquer coisa que entra ou sai deve passar por um portão.
Se isso é tudo que há no seu exemplo de código, então ele parece um texto clichê desnecessariamente prolixo. Mas frequentemente fazemos outras coisas no construtor além de definir variáveis privadas, como validação. Em muitas linguagens de programação, mudar a maneira como você faz isso após o fato é uma alteração de quebra binária, portanto, fornecer o construtor antecipadamente pode ser uma etapa sensata.
Finalmente, a classe deve ser capaz de funcionar independentemente da injeção de dependência. Se você colocar uma anotação em um membro privado, mas não incluir um construtor , você essencialmente vinculou essa classe ao contêiner de DI e a classe não funcionará sem ela.
Comentários
- " Em um show, você não ' permite que as pessoas joguem coisas pela cerca para alguém que ' s já está no stadiu m. Qualquer coisa que entrar ou sair deve passar por um portão. " Mas eu não ' não vejo como usar um construtor torna o autowiring mais seguro? Se não houvesse requisitos de construtor (como validação), então seria vantajoso usar um construtor?
- Você torna possível adicionar validação posteriormente sem quebrar a compatibilidade binária.
- Também , observe que membros privados devem realmente permanecer privados. Isso ' é a razão de ter membros privados.
- A questão toda é permitir boas práticas de design compatíveis com @Autowire. Ter construtores é a coisa MAIS natural em OOP. O contrário (o que você chama de direto e simples) é um pouco assustador. Não há benefícios reais na remoção de construtores, ' há nenhuma simplicidade nisso. Construtores estão entre os métodos mais simples em OOP.Por si só, eles geralmente têm muito pouca complexidade que valha a pena implementar a magia do Spring IoC
- Por que vale ', Java tende a ser um linguagem muito prolixa de qualquer maneira. Se você ' está procurando domar parte dessa verbosidade, é improvável que a eliminação de construtores prejudique muito.
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.e você não está preocupado com a mágica de injetar um bean em uma variável instace que é privada e não tem setter? Vocês não estão preocupados com a enorme dívida técnica que isso está gerando para vocês, seus colegas de trabalho? Você não está preocupado em retransmitir muito no paradigma mágico do ' do Spring em vez de boas práticas de design?