Castle Windsor est une inversion de l'outil de contrôle. Il y en a d'autres comme ça.
Il peut vous donner des objets avec des dépendances pré-construites et pré-câblées directement là-dedans. Un graphe d'objets entier créé par réflexion et configuration plutôt que par l'opérateur "nouveau".
Commencez ici: http://tech.groups.yahoo.com/group/altdotnet/message/10434
Imaginez que vous ayez une classe d'envoi d'e-mails. EmailSender. Imaginez que vous avez une autre classe WorkflowStepper. Dans WorkflowStepper, vous devez utiliser EmailSender.
Tu pourrais toujours dire new EmailSender().Send(emailMessage);
mais cela - l'utilisation de new
- crée un COUPLAGE ÉTROIT qui est difficile à changer. (c'est un petit exemple artificiel après tout)
Alors que se passe-t-il si, au lieu de créer ce mauvais garçon dans WorkflowStepper, vous le passiez simplement au constructeur?
Donc, celui qui l'appelait devait renouveler EmailSender.
new WorkflowStepper(emailSender).Step()
Imaginez que vous ayez des centaines de ces petites classes qui n'ont qu'une seule responsabilité (google SRP) ... et que vous en utilisez quelques-unes dans WorkflowStepper:
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Imaginez ne pas vous soucier des détails du EmailSender
moment où vous écrivez WorkflowStepper
ouAlertRegistry
Vous vous inquiétez simplement du problème avec lequel vous travaillez.
Imaginez que tout ce graphique (arbre) d'objets et de dépendances soit câblé au TEMPS D'EXÉCUTION, de sorte que lorsque vous faites cela:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
vous obtenez une vraie affaire WorkflowStepper
avec toutes les dépendances remplies automatiquement là où vous en avez besoin.
Il n'y a pas new
Cela arrive simplement - parce qu'il sait ce qui a besoin de quoi.
Et vous pouvez écrire moins de défauts avec un code DRY mieux conçu de manière testable et répétable.