0

Why does the modifier access for the properties need to be public with Unity?

I'm very interested in a detailed explanation for my question. I read about tips to do it in other ways, but not a detailed explanation about why this can't be declared explicitly in my code.

Improve this question
0

1 Answer 1

Reset to default
5

Why would you need to inject private properties? That's not what DI is for. Injecting private properties would violate encapsulation.

One of the constructor overloads on your class should specify everything the class needs to instantiate. If the class can't specify what it needs in it's public API, then it doesn't need it.

From http://natpryce.com/articles/000783.html (emphasis mine):

There are two aspects to Dependency Injection. Firstly, an object's interface should define the services that the object requires as well as those it provides. Secondly, the code that satisfies the requirements of an object by giving it a reference to the services of is collaborators is external to both the object and its collaborators. For this reason, the pattern also used to be called "third-party binding" or "third-party connect": some third party is responsible for connecting and satisfying the service requirements of a component (the party of the first part) with those provided by another component (the party of the second part).

The name "Dependency Injection" only relates to the second aspect. And worse, makes it sound like dependencies are "injected" through the object's encapsulation boundary rather than explicitly defined as part of the object's API. And so we get "dependency injection" APIs, like that in JavaEE 5, which use reflection to poke dependencies into an object's private fields, bypassing the constructor, adding a great deal of complexity to client & test code while not providing the benefits that the Dependency Injection pattern should deliver.

Improve this answer
11
  • Enh, I've done this quite a bit when it would be improper for the dependency to be exposed publically on an object - which tends to be all the time.
    – Telastyn
    Nov 15, 2013 at 17:01
  • 1
    If it's not a public dependency, then it doesn't need to be provided from the outside. Private dependencies should be furnished by the class itself. I'd love to see an example of what you're describing, because it pretty much flies in the face of everything I've learned about OOP.
    – Robert Harvey
    Nov 15, 2013 at 17:02
  • And how do you suggest furfilling private dependencies that need to be controlled by the application but would be laborous to wire in via constructors (like happens with plug-ins). I'm not trying to argue, but am curious. In my scenario, the class doesn't know what concrete implementation of... say a strategy to use so it can't make it itself.
    – Telastyn
    Nov 15, 2013 at 17:06
  • 1
    I don't know. But I would have though of some other way... any other way... than manipulating private variables from the outside. Down that path lies Reflection and other hackery madness. stackoverflow.com/q/934930 I am intrigued, however, at the very idea.
    – Robert Harvey
    Nov 15, 2013 at 17:07
  • 1
    If your DI container is injecting dependencies into private fields using reflection trickery, how are you injecting mocks into your unit tests? Having dependencies in the public interface is perfectly consistent with Tell Don't Ask, and I'm not even sure what anyone would hope to gain by violating encapsulation to avoid doing it.
    – Mr Cochese
    Nov 16, 2013 at 13:21

Your Answer

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

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