Замок Віндзор - це інверсія інструменту управління. Є й інші подібні.
Він може давати вам об’єкти із заздалегідь побудованими та попередньо провідними залежностями. Цілий графік об'єкта, створений за допомогою відображення та конфігурації, а не "нового" оператора.
Почніть тут: http://tech.groups.yahoo.com/group/altdotnet/message/10434
Уявіть, що у вас є клас надсилання електронної пошти. EmailSender. Уявіть, що у вас є ще один клас WorkflowStepper. Всередині WorkflowStepper потрібно використовувати EmailSender.
Ви завжди можете сказати new EmailSender().Send(emailMessage);
але це - використання new- створює ТУГИЙ СКЛАД, який важко змінити. (адже це крихітний надуманий приклад)
Що робити, якщо замість того, щоб випустити цього поганого хлопчика всередині WorkflowStepper, ви просто передали його в конструктор?
Тоді той, хто його закликав, повинен був створити EmailSender.
new WorkflowStepper(emailSender).Step()
Уявіть, що у вас є сотні цих маленьких класів, на які покладено лише одну відповідальність (google SRP) .. і ви використовуєте декілька з них у WorkflowStepper:
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Уявіть, що не турбуєтесь про деталі, EmailSenderколи ви пишете WorkflowStepperчиAlertRegistry
Ви просто переймаєтесь турботою, з якою працюєте.
Уявіть, що весь цей графік (дерево) об'єктів і залежностей з'єднується під час запуску, і коли ви це зробите:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
ви отримуєте реальну угоду WorkflowStepperз усіма залежностями, автоматично заповненими там, де вам це потрібно.
Немає new
Це просто відбувається - тому що він знає, що потрібно для чого.
І ви можете записати менше дефектів за допомогою кращого дизайну DRY-коду перевіряючим та повторюваним способом.