Does an IoC-Container violate the Open/Closed-Principle?

Question

Right now I construct all objects of my application in the root class manually. Since it is getting ugly now, I want to switch to an IoC-Container like Autofac. Now I have to register each interface with its corresponding implementation manually. Looks great, works great, but:

Say I have to modify one of my classes' constructor. I need to add another dependency. Now I have to remember to go back to my root and register that interface/implementation. Doesn't that violate the Open/Closed-principle?

Answer 1

Say I have to modify one of my classes' constructor...

To my mind, this is the point where you are violating the Open/Closed (O/C) principle. If you change a constructor, that class is no longer closed to modification. Even with your current pure/poor-man's DI approach, you'd have to modify other code to accommodate the change. The fact that you're considering using an IoC container instead would not change this, though using a container risks not being detected at compile time, only when the app is run, but this is a small risk.

Since the code is all contained in a single app, the O/C principle isn't particularly important here. It only really comes into play if you change the public API of a library or module upon which many apps or other libraries depend. Then you need to think carefully about such changes, and eg use semantic versioning to highlight breaking changes due to needing to modify a closed class.

Answer 2

No, IoC containers and constructors don't violate the Open/Closed Principle.

If you need to add a new dependency to your class the Open/Closed way to do it would be to create a new class which inherits from the old one and has a new constructor with the new dependency, overriding methods where required.

If you orgional class is "Open" for extension then this should be possible.

Your IoC Container in your app meanwhile requires no extension of its functionality in order to register the new class rather than the old. So the Open Closed principle does not apply at all

Your app itself presumably can happily consume the new class as its a sub class of the original and injected via IoC so again the principle doesn't apply.

If you find that you are unable to subclass your original class and add the dependency and required functionality, and that you need to change its code to make that extra functionality work. Then your original class has failed the open/closed test.

However, these days I imagine everyone is using Interfaces rather than base classes. So you avoid a lot of these issues.

Edit. re: what about the root class in the app?

Technically you have the same option with your app's main class, ie sub class and alter the internal registration. Just because you are using an IoC Container, doesn't mean you can't override your setup function, remove and add registrations or make your class open to extension in other ways.

But at this level it would make no sense to do so. Unless you app is a plugin or some such, no other code will consume it, there isn't any downside to simply changing the code in the root class.