4 ms·

>> There is a second form of Dependency Injection that uses setters instead of constructor injection. Do not use this form. Why? Personal preference I guess? C

by pan69 12y ago

>> There is a second form of Dependency Injection that uses setters instead of constructor injection. Do not use this form. Why? Personal preference I guess? Constructor injection works fine for low level objects that only take 1 or 2 dependencies, but for higher level business objects that might have a wider dependency reach, constructor injection can become a nightmare.

kasey_junk 12y ago
That's a section of the article I could have probably fleshed out more broadly, but the original audience was largely made up of developers who rejected the entirety of DI and IoC, largely due to their past negative experiences with setter based IoC containers. I've answered the problem with setter based DI elsewhere in these comments, but another way to say it is because you've now made the behavior of the system, not just the data, mutable state. Which is harder to reason about, harder to test, and harder to get right in concurrent contexts. > for higher level business objects that might have a wider dependency reach, constructor injection can become a nightmare. Again, I view this as a symptom of bad design. If you have a wide dependency reach, then using a DI container is only allowing you to increase the problem. Using setter DI, which normally compromises the design even more, to supposedly make the design better is suspect. I think you would be better served by fixing your high level business objects to not have a wider dependency reach, and the dependency inversion principle is one tool with which you can do that.
- pan69 12y ago
  Its normal for higher level business objects to have a wider dependency reach, these are the elements that facilitate the communication between lower level objects. The last thing you want to do is pass around a container as a dependency because you don't want your core business logic to have a dependency on a specific container (the container is a framework thing). Injecting a container would be a sign of bad design.
  - kasey_junk 12y ago
    I didn't intend to imply you should inject an IoC container. Offhand I cannot think of an example of when that would be appropriate. What I did intend to say is that having a wide dependency reach is a negative outcome, that is usually the result of bad design choices. That high level components have many low level dependencies is precise evidence that the dependency inversion principle has not been followed. The entire point of the principle is to decouple high level components from low level ones and to flatten that hierarchy so that the components become peers that each own their own abstractions around dependencies.
Danack 12y ago
>> There is a second form of Dependency Injection that uses setters instead of constructor injection. Do not use this form. >Why? Not using setter injection eliminates a huge class of bugs that occur when people try to use objects that haven't had all of their dependencies injected yet: $user = new RegisteredUser(); // Any code that touches $user here will be bad $user->setEmail($email); > constructor injection can become a nightmare. Which is why people use library to do it for them - an example for PHP https://github.com/rdlowrey/auryn https://github.com/rdlowrey/auryn.

by pan69 12y ago

kasey_junk 12y ago

That's a section of the article I could have probably fleshed out more broadly, but the original audience was largely made up of developers who rejected the entirety of DI and IoC, largely due to their past negative experiences with setter based IoC containers. I've answered the problem with setter based DI elsewhere in these comments, but another way to say it is because you've now made the behavior of the system, not just the data, mutable state. Which is harder to reason about, harder to test, and harder to get right in concurrent contexts. > for higher level business objects that might have a wider dependency reach, constructor injection can become a nightmare. Again, I view this as a symptom of bad design. If you have a wide dependency reach, then using a DI container is only allowing you to increase the problem. Using setter DI, which normally compromises the design even more, to supposedly make the design better is suspect. I think you would be better served by fixing your high level business objects to not have a wider dependency reach, and the dependency inversion principle is one tool with which you can do that.

pan69 12y ago
Its normal for higher level business objects to have a wider dependency reach, these are the elements that facilitate the communication between lower level objects. The last thing you want to do is pass around a container as a dependency because you don't want your core business logic to have a dependency on a specific container (the container is a framework thing). Injecting a container would be a sign of bad design.
- kasey_junk 12y ago
  I didn't intend to imply you should inject an IoC container. Offhand I cannot think of an example of when that would be appropriate. What I did intend to say is that having a wide dependency reach is a negative outcome, that is usually the result of bad design choices. That high level components have many low level dependencies is precise evidence that the dependency inversion principle has not been followed. The entire point of the principle is to decouple high level components from low level ones and to flatten that hierarchy so that the components become peers that each own their own abstractions around dependencies.

Danack 12y ago

>> There is a second form of Dependency Injection that uses setters instead of constructor injection. Do not use this form. >Why? Not using setter injection eliminates a huge class of bugs that occur when people try to use objects that haven't had all of their dependencies injected yet: $user = new RegisteredUser(); // Any code that touches $user here will be bad $user->setEmail($email); > constructor injection can become a nightmare. Which is why people use library to do it for them - an example for PHP https://github.com/rdlowrey/auryn https://github.com/rdlowrey/auryn.