Question

If I understand correctly, the typical mechanism for Dependency Injection is to inject either through a class’ constructor or through a public property (member) of the class.

This exposes the dependency being injected and violates the OOP principle of encapsulation.

Am I correct in identifying this tradeoff? How do you deal with this issue?

Please also see my answer to my own question below.

Answer 1

There is another way of looking at this issue that you might find interesting.

When we use IoC/dependency injection, we’re not using OOP concepts. Admittedly we’re using an OO language as the ‘host’, but the ideas behind IoC come from component-oriented software engineering, not OO.

Component software is all about managing dependencies – an example in common use is .NET’s Assembly mechanism. Each assembly publishes the list of assemblies that it references, and this makes it much easier to pull together (and validate) the pieces needed for a running application.

By applying similar techniques in our OO programs via IoC, we aim to make programs easier to configure and maintain. Publishing dependencies (as constructor parameters or whatever) is a key part of this. Encapsulation doesn’t really apply, as in the component/service oriented world, there is no ‘implementation type’ for details to leak from.

Unfortunately our languages don’t currently segregate the fine-grained, object-oriented concepts from the coarser-grained component-oriented ones, so this is a distinction that you have to hold in your mind only 🙂