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?

  • @Walfrat probably this
    – max630
    Oct 12, 2018 at 9:15

2 Answers 2


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.

  • That's a good answer (+1), but I guess the obvious follow-up question is here: isn't there a way to design the root class in a way it will follow the OCP?
    – Doc Brown
    Oct 12, 2018 at 9:41
  • 1
    Yeah, in theory I would agree. But let's talk reality: Say I have a class that is in production and now I want to add some kind of logging functionality. I would just change my constructor to have the additional dependency ILogger. That might already be registered, but let's say it isn't, I would then need to go to my root and do that. I see no way to have my class get that logging functionality without actually touching it?
    – selmaohneh
    Oct 12, 2018 at 10:46

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.

  • 1
    If the registration is controlled through a configuration file, one could exchange the old class by a new subclass in that configuration, without modfiyfing any code. However, OP wrote "I construct all objects of my application in the root class manually", and the question was if the OCP is violated in that root class, where the registration takes place, and even if an extension was possible "OCP style" by subclassing, the new subclass needs to be registered in the root class. IMHO your answer does not address this.
    – Doc Brown
    Oct 12, 2018 at 10:24
  • @DocBrown i will add a bit more although i do feel this is addressed
    – Ewan
    Oct 12, 2018 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.