Castle Windsor ist eine Umkehrung des Steuerungswerkzeugs. Es gibt andere wie es.
Es kann Ihnen Objekte mit vorgefertigten und vorverdrahteten Abhängigkeiten direkt dort geben. Ein gesamtes Objektdiagramm, das über Reflexion und Konfiguration erstellt wurde und nicht über den "neuen" Operator.
Beginnen Sie hier: http://tech.groups.yahoo.com/group/altdotnet/message/10434
Stellen Sie sich vor, Sie haben eine E-Mail-Sendeklasse. EmailSender. Stellen Sie sich vor, Sie haben eine andere Klasse WorkflowStepper. In WorkflowStepper müssen Sie EmailSender verwenden.
Das könnte man immer sagen new EmailSender().Send(emailMessage);
Aber das - die Verwendung von new- schafft eine enge Kupplung, die schwer zu ändern ist. (Dies ist schließlich ein winziges erfundenes Beispiel)
Was ist, wenn Sie diesen bösen Jungen nicht in WorkflowStepper neu geschrieben, sondern nur an den Konstruktor übergeben haben?
Wer auch immer es anrief, musste den EmailSender neu einrichten.
new WorkflowStepper(emailSender).Step()
Stellen Sie sich vor, Sie haben Hunderte dieser kleinen Klassen, die nur eine Verantwortung haben (Google SRP). Sie verwenden einige davon in WorkflowStepper:
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Stellen EmailSenderSie sich vor, Sie machen sich keine Gedanken über die Details, wenn Sie schreiben WorkflowStepperoderAlertRegistry
Sie sorgen sich nur um die Bedenken, mit denen Sie arbeiten.
Stellen Sie sich vor, dieser gesamte Graph (Baum) von Objekten und Abhängigkeiten wird zur LAUFZEIT verkabelt, sodass Sie Folgendes tun:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
Sie erhalten ein echtes Geschäft WorkflowSteppermit allen Abhängigkeiten, die automatisch dort ausgefüllt werden, wo Sie sie benötigen.
Es gibt kein new
Es passiert einfach - weil es weiß, was was braucht.
Und Sie können mit besser entworfenem DRY-Code auf fehlerhafte und wiederholbare Weise weniger Fehler schreiben.