Must Dependency Injection come at the expense of Encapsulation?

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 clas

Answer 1

Encapsulation is only broken if a class has both the responsibility to create the object (which requires knowledge of implementation details) and then uses the class (which does not require knowledge of these details). I'll explain why, but first a quick car anaology:

When I was driving my old 1971 Kombi, I could press the accelerator and it went (slightly) quicker. I did not need to know why, but the guys who built the Kombi at the factory knew exactly why.

But back to the coding. Encapsulation is "hiding an implementation detail from something using that implementation." Encapsulation is a good thing because the implementation details can change without the user of the class knowing.

When using dependency injection, constructor injection is used to construct service type objects (as opposed to entity/value objects which model state). Any member variables in service type object represent implementation details that should not leak out. e.g. socket port number, database credentials, another class to call to perform encryption, a cache, etc.

The constructor is relevant when the class is being initially created. This happens during the construction-phase while your DI container (or factory) wires together all the service objects. The DI container only knows about implementation details. It knows all about implementation details like the guys at the Kombi factory know about spark plugs.

At run-time, the service object that was created is called apon to do some real work. At this time, the caller of the object knows nothing of the implementation details.

That's me driving my Kombi to the beach.

Now, back to encapsulation. If implementation details change, then the class using that implementation at run-time does not need to change. Encapsulation is not broken.

I can drive my new car to the beach too. Encapsulation is not broken.

If implementation details change, the DI container (or factory) does need to change. You were never trying to hide implementation details from the factory in the first place.

Answer 2

I struggled with this notion as well. At first, the 'requirement' to use the DI container (like Spring) to instantiate an object felt like jumping thru hoops. But in reality, it's really not a hoop - it's just another 'published' way to create objects I need. Sure, encapsulation is 'broken' becuase someone 'outside the class' knows what it needs, but it really isn't the rest of the system that knows that - it's the DI container. Nothing magical happens differently because DI 'knows' one object needs another.

In fact it gets even better - by focusing on Factories and Repositories I don't even have to know DI is involved at all! That to me puts the lid back on encapsulation. Whew!

Answer 3

PS. By providing Dependency Injection you do not necessarily break Encapsulation. Example:

obj.inject_dependency(  factory.get_instance_of_unknown_class(x)  );

Client code does not know implementation details still.