I'm reading a book right now call Dependency Injection in .NET. I know the basics of dependency injection and I've always just seen it as a means to be able to unit test methods. This book explains how this is just one of the many benefits and I'm trying to fully comprehend how late binding is beneficial.
The author gives a Hello World example where he passes a dependency into a Salutation class like this...
IMessageWriter writer = new ConsoleMessageWriter();
var salutation = new Salutation(writer);
salutation.exclaim("Hello DI");
Console.ReadLine();
Okay, I'm with him. The Salutation class no longer depends on ConsoleMessageWriter and could be swapped with other classes without changing Salutation. Then the author does this to show you could using the Configuration Manager to pull the dependency using reflection like this...
var typeName = ConfigurationManager.AppSettings["messageWriter"];
var type = Type.GetType(typeName, true);
IMessageWriter writer = (IMessageWriter)Activator.CreateInstance(type);
var salutation = new Salutation(writer);
salutation.exclaim("Hello DI");
Console.ReadLine();
The second example uses late binding because you don't know which instance at compile time will be used to pass to Salutation. Theoretically you don't have to deploy again because you could just change the app.config to choose your new dependency. However, this only works if you already have the other class you want passed already belongs to the deployed project, correct?
They talk about not having to redeploy, but if you want a new dependency passed, you would still need to modify the project by adding a new class and then rebuilding/redeploying the solution. I'm just not seeing the benefit here since how often are you just going to hop in the app config and change your dependency... usually if it changes you'll want to add a new class anyway, correct? What am I missing?
Benefits of dependency injection and late binding?