Castle Windsor é uma inversão da ferramenta de controle. Existem outros assim.
Ele pode fornecer objetos com dependências pré-construídas e pré-cabeadas. Um gráfico de objeto inteiro criado via reflexão e configuração, e não pelo operador "novo".
Comece aqui: http://tech.groups.yahoo.com/group/altdotnet/message/10434
Imagine que você tem uma classe de envio de e-mail. EmailSender. Imagine que você tem outra classe WorkflowStepper. Dentro do WorkflowStepper, você precisa usar o EmailSender.
Você sempre pode dizer new EmailSender().Send(emailMessage);
mas isso - o uso de new
- cria um ACOPLAMENTO apertado que é difícil de mudar. (este é um pequeno exemplo artificial, afinal)
E daí que, em vez de lançar esse garoto mau no WorkflowStepper, você o passasse para o construtor?
Então, quem quer que tenha telefonado precisa atualizar o EmailSender.
new WorkflowStepper(emailSender).Step()
Imagine que você tem centenas dessas pequenas classes que têm apenas uma responsabilidade (google SRP). E você usa algumas delas no WorkflowStepper:
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Imagine não se preocupar com os detalhes de EmailSender
quando você está escrevendo WorkflowStepper
ouAlertRegistry
Você só se preocupa com a preocupação com a qual está trabalhando.
Imagine que todo esse gráfico (árvore) de objetos e dependências seja conectado em RUN TIME, para que, ao fazer isso:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
você consegue um acordo real WorkflowStepper
com todas as dependências preenchidas automaticamente onde você precisar.
Não há new
Apenas acontece - porque sabe o que precisa de quê.
E você pode escrever menos defeitos com um código DRY melhor projetado, de maneira testável e repetível.