Como injeção de dependências funciona no Spring, e por que você prefere injeção por construtor?

O container constrói os beans e fornece seus colaboradores, então as classes declaram o que precisam em vez de construir. Injeção por construtor é preferível porque as dependências são obrigatórias e visíveis, os campos podem ser final para o objeto ficar imutável e totalmente inicializado, a classe é testável com um new puro e sem reflexão, e uma dependência circular falha alto no startup em vez de se esconder atrás de injeção preguiçosa em campo.

O container é dono da criação de objetos, então minha classe pede o que precisa no construtor e o Spring resolve e injeta. Eu uso injeção por construtor porque ela torna o contrato óbvio: se uma classe recebe cinco colaboradores, isso agora está visível na assinatura em vez de escondido em cinco campos anotados, e normalmente isso me diz que a classe está fazendo demais. Os campos podem ser final, então o objeto fica totalmente construído e seguro para publicar entre threads, e eu consigo instanciá lo num teste com argumentos de construtor puros e nenhum contexto Spring, o que mantém os testes unitários rápidos. Dependências circulares também aparecem no startup como falha em vez de serem varridas para debaixo do tapete. Sobre escopo, beans são singletons por padrão, então eu os mantenho sem estado; um campo mutável num serviço singleton é uma condição de corrida esperando por requisições concorrentes. Quando eu preciso de estado por requisição eu passo como parâmetro de método em vez de apelar para um bean com escopo de requisição. Injeção em campo eu evito ativamente, já que ela esconde dependências e precisa de reflexão para ser montada num teste.