Dependency Injection Breaks Encapsulation

[tony_marston404]

@myesain84

As my quote from Wikipedia shows, the goal of practicing Dependency Injection is to achieve IoC in your code. Can you comment on this?

Let me turn the question around - can you have Dependency Injection without Inversion of Control? Can you have Inversion of Control without Dependency Injection? What is the difference between DI and IoC? Until someone can come up with a description that these two concepts are completely different and not interchangeable I shall stick with my claim that this thread is about DI and not IoC.

@myesain84

tony_marston404:
What has the number of constructor arguments got to do with DI?

By specifying the number of constructor arguments your component classes will be instantiated with, you have defined the implementation of the construction of the object.

But I don’t use constructor arguments in my framework as I don’t need to configure an object an object before I can use it.

@myesain84

An injection is the passing of a dependency (a service) to a dependent object (a client). The service is made part of the client’s state. Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.

Your code has instantiated a variable ($table) that is used by your client code to build a it’s service based on the value of that variable. This is in direct opposition to the definition provided.

Your interpretation of that definition of DI is too tight, in my opinion. I AM passing a dependency (a service) to a client object which then becomes part of the client’s state. The fact that I am passing in the name of a class which has to be instantiated into an object instead of a pre-instantiated object is merely a minor technical detail. The client does not have to find or build the service, it simply executes the “new” function on whatever class name it has been given. Using “new” without any arguments is not the same as “building” an object by supplying a variety of constructor arguments which can vary according to the circumstances.

@myesain84

myesain84:
there are no circumstances that would not benefit from from being Dependency Injected

As I said, if nothing else, code that is properly Dependency Injected will likely be layer separated and testable. Given that implementing dependency injection will provide these two benefits, there is no situation where using DI will not provide any benefits.

I do not agree that code is not “more testable” because it is separated. By having code fragmented across several different places you are actually making it more difficult for a human to follow, and code that is easy for a human to understand should take priority.

I do not agree that using DI will always provide benefits, and you will never convince me otherwise. DI was designed to be used in particular circumstances, and I use it where those circumstances appear in my framework. Where those particular circumstances do not exist then there is no benefit in using DI, so where those circumstances do not exist in my framework I do not use DI.

@myesain84

By practicing Dependency Injection, your controller code will/must break encapsulation by instantiating the objects needed at execution time. This is a fact.

My opinion on this matter has two parts:

• when used in appropriate circumstances DI does not break encapsulation
• when used in inappropriate circumstances DI does break encapsulation.

My Controllers are designed to work with one of any number of possible alternative Model objects, so I need to inject the identity of that Model so that the Controller can work…

Where I have a Model which needs to access another Model I know which Model it is as there are no alternatives, no choices, so I don’t need, nor do I use, DI.