Talk:Dependency injection/Archives/2015/August

Disadvantages Section

The Disadvantages section claims that unit testing can mitigate incorrect dependency resolution. By definition unit tests test a unit in isolation, independent of their dependencies. Such a test is by definition an integration test even if achieved using jUnit or nUnit test harnesses. Galhalee (talk) 17:40, 15 March 2014 (UTC)

The line "Dependency injection typically requires more lines of code" is wrong. On the contrary, Dependency injection minimize the use of more code when reusing components and frameworks for complicated tasks as persistence or instantiation

63.128.77.30 (talk) 14:54, 16 January 2015 (UTC)

The line "Dependency injection diminishes encapsulation..." use Nat Pryce attack to DI frameworks to all sort of DI. Pryce himself use DI in his GOOS book, avoiding the access to private fields using reflection and similar mechanisms. The whole section must be preceded by a clear mention to the opinion of detractors. These called disadvantages or advantages carry detractors and promoters. They're not facts.

63.128.77.30 (talk) 18:42, 16 January 2015 (UTC)

User Galhalee, please stop destructively editing my changes to this section. You have repeatedly deleted the same data. The first time you complained that the cited resource was not primarily about the disadvantage listed. That a source happens to discuss points in addition to the one being used in a citation is a poor reason to remove either the source or the information from the wikipedia entry. Nonetheless I humored you and changed the citation to include the specific on topic quotation. There is no possible way you can legitimately consider a quotation that specifically raises a point not primarily about that point, but you deleted it again for the same reason. Further the disadvantage being raised is a very important one for the page and for users reading the page because it explains how DI achieves the opposite of one of its primary intents, loose coupling. I am going to re-add the section now. Kindly do not remove it. If you have a valid point you wish to raise, please do so here. Introw (talk) 19:00, 23 July 2015 (UTC)

Introw - Thank you for taking the time to talk. Over a year ago (on 1 April 2014 no less) your account introduced the claims that DI increases coupling and diminishes encapsulation. Here they are in their original form:

• Dependency injection diminishes encapsulation by requiring requires users of a system to know how it works and not merely what it does.

• Dependency injection increases coupling by requiring the user of a subsystem to provide for the needs of that subsystem.

They lasted less than two weeks before Danny.Smart removed them. Since then your account and IP accounts have repeatedly re-added them with mostly trivial changes. The most significant change is that now you've only added the coupling claim. Here's the relevant history:

19:03, 23 July 2015?     Introw         ? . . (+513)? . . (Undid revision 672715438 by Galhalee                  - See talk page for explanation. Please do not engage in Wikipedia:Edit_warring) (undo | thank)

11:10, 23 July 2015?     Galhalee       ? m . (-513)? . . (Undid revision 672700673 by 98.247.172.124                  This has already been edited into other entries. Stop offering this under different accounts.) (undo)

08:30, 23 July 2015?     98.247.172.124 ? . . (+513)? . . (Undid revision 672674467 by Galhalee                 ) (undo)

03:13, 23 July 2015?     Galhalee       ? . . (-513)? . . (Undid revision 672541062 by Introw                  misrepresents the point of DI and who provides for needs. Fails to define who caller and callee are. Use the talk page to make your case.) (undo)

06:39, 22 July 2015?     Introw         ? . . (+513)? . . (Disadvantage is increased coupling.) (undo | thank)

05:15, 11 July 2015?     Galhalee       ? . . (-725)? . . (Undid revision 670864578 by 216.113.160.82                 ) (undo)

18:30, 10 July 2015?     216.113.160.82 ? . . (+725)? . . (??Disadvantages) (undo)

03:47, 22 June 2015?     Galhalee       ? m . (+729)? . . (??Disadvantages: Identifying more disadvantages) (undo)

03:27, 22 June 2015?     Galhalee       ? . .  (-22)? . . (??Disadvantages: Encapsulation issue is not the point of cited material) (undo)

03:00, 22 June 2015?     Galhalee       ? m .  (-72)? . . (??Disadvantages: Coupling is not the point of the cited material. It's the ability to use modern mocking tools rather than DI.) (undo)

02:25, 22 June 2015?     Galhalee       ? m .  (+11)? . . (??Disadvantages: Withdrawing disputed claim) (undo)

01:56, 22 June 2015?     Galhalee       ? m .  (+23)? . . (Linking client. The service and client pages are bent towards networking but they cover the meaning of the terms) (undo)

04:56, 27 May 2015?      Introw         ? . . (+228)? . . (undo | thank)

13:38, 26 May 2015?      90.217.41.0    ? . . (-362)? . . (??Disadvantages: "Increases coupling" was listed as a disadvantage, whereas "Reduces coupling" was listed in the advantages. Which is it? The article shouldn't contradict itself) (undo)

12:21, 26 May 2015?      90.217.41.0    ? . . (+154)? . . (??Disadvantages) (undo)

18:12, 20 April 2015?    Introw         ? . . (+723)? . . (??Overview) (undo | thank)

03:36, 7 April 2015?     24.108.61.204  ? . . (-177)? . . (Deleted line is not cited and not clear. What is the difference between how a system works and what it does? How does this apply to the topic? I understand that not all points need to be cited, but they need to make sense.) (undo)

03:31, 7 April 2015?     24.108.61.204  ? . . (-202)? . . (Deleted line is in direct opposition to final point in "Advantages", and is not cited. The article shouldn't contradict itself unless the sources of opinion are cited.) (undo)

14:52, 2 February 2015?  78.10.227.44   ? . . (-156)? . . (-poor ref (with gems such as "It seems that some OO "purist" objected most strongly to my heretical viewpoint and had my comment removed. This I take as a form of censorship and a violation of my right to free speech. The OO Nazis may think that(...)")) (undo)

06:29, 27 January 2015?  50.27.39.102   ? . . (-130)? . . (undo)

05:43, 31 December 2014? 50.132.3.92    ? . . (+362)? . . (Undid revision 636564840 by 50.27.39.102                 ) (undo)

05:25, 4 December 2014?  50.27.39.102   ? . . (-362)? . . (DI reduces coupling, see http://msdn.microsoft.com/en-us/library/vstudio/hh323705%28v=vs.100%29.aspx) (undo) (Tag: HHVM)

01:37, 15 May 2014?      Introw         ? . . (+696)? . . (??Disadvantages: Putting some disadvantages back in that were mistakenly removed.)

10:41, 13 April 2014?    Danny.Smart    ? m . (-362)? . . (Removed inaccurate and opinionated disadvantage (cited article does not support the claim)) (undo | thank)

10:39, 13 April 2014?    Danny.Smart    ? m . (-334)? . . (Removed inaccurate and opinionated disadvantage (included broken citation link)) (undo | thank)

21:21, 1 April 2014?     Introw         ? . . (+405)? . . (??Disadvantages: coupling) (undo | thank)

21:09, 1 April 2014?     Introw         ? . . (+300)? . . (??Disadvantages: encapsulation) (undo | thank)

We are supposed to assume good faith so I'll treat this as a simple neutral point of view dispute.

This history shows at the very least that these entries have not been stable. What is most concerning is that no significant effort has been made to stabilize them. The most effort I've seen is the entry you made above on this talk page, which I do appreciate.

Well, there was one other effort. After trying to stay out of it and watching the entries come and go I finally decided to attempt to edit them into something more stable. While what was created was stable it didn't stop the old entries from coming back.

What I think we both need to realize is that you feel there is a point to be made here and others feel it's not being made well enough. So since I couldn't pull off making your point, I challenge you to do it. Please reword both of these entries (yes the encapsulation one too) into a form that will be stable.

I'll remove both our entries and let you have your say. However, if you continue to re-add this with it's current wording it should be obvious by now that it's simply going to be removed.

Since you've been kind enough to read this far I'll try to help by summarizing the issues I've identified.

• Dependency injection diminishes encapsulation by requiring requires users of a system to know how it works and not merely what it does.

• Dependency injection increases coupling by requiring the user of a subsystem to provide for the needs of that subsystem.

• Both statements are unqualified. Indicating that every use of DI will have these results. Fantastic claims require fantastic proof.
• Both statements are unscoped. Leaving readers wondering if you're referring to any use of DI frameworks, just ones that use configuration files, the discipline of separating use from construction, or even just a simple reference pass.
• Both statements have an undefined perspective. Who are you considering a user? A client using a dependency, the injector, an end user, or a system manager maintaining the system? Also, what exactly is a subsystem here?
• Both statements have questionable citations. While I personally feel quite liberal about non-book sources, you could certainly improve your case if you found more, and better, sources to cite.
• What form of coupling is being referred to? Is it possible that the real issue is with increasing arity? Hidden coupling is still coupling.
• encapsulation is being diminished in what case? Maybe that refers to this: "If you are allowing callers to construct the class directly, then you are most certainly breaking encapsulation as the callers must posses the knowledge of how to construct your class." This is certainly true, but also doesn't follow separating use from construction. If that was followed the "user" of a client would have no idea dependency injection had been used at all. It's the injector that the dependency breaks encapsulation with, since the injector must know how to construct the dependency.

What I hope I've made clear is that I do not want your point to simply be gone. I want it to be well made. I'll even give you a citation where a proponent of DI flat out admits that DI breaks encapsulation.

I am not trying to promote DI. I am studying it. So my problem with these disadvantages is not that they're disadvantages. It's that they're weak. The page needs some good disadvantages. So please make your entries critical, insightful, devastating, accurate, focused, and informative.

Do that and they might even hang around for a while. Galhalee (talk) 05:21, 27 July 2015 (UTC)

Thanks for getting back to me in the talk. I think I understand some of what your concerns are, but before trying to add something that addresses some of them, I'll try and discuss them here.

Introw I do appreciate the restraint and the effort. Galhalee (talk) 10:02, 5 August 2015 (UTC)

• Unqualified and unscoped. Well, yeah I suppose the statements are, but then again it's a generic list of disadvantages rather than a detailed exploration. Most decisions people make in programming involve tradeoffs; it's not a fantastic claim that dependency injection in general (meaning perhaps not every case but near enough) involves a particular tradeoff. In any case the answers to your question would be "almost every case" and "every type of use" since the drawbacks are attached to the technique itself rather than to any particular technology or implementation of the concept.

Introw, unqualified as in using words like "may" would help the claim be less extreme. "almost every case" would require a strong citation and a good explanation. Unscoped, as in, I still don't understand if you're really saying I'm increasing coupling and diminishing encapsulation every time I pass a reference around rather than build my own. Galhalee (talk) 10:02, 5 August 2015 (UTC)

• Undefined perspective. I agree with you. I was unclear here. Part of the problem is the difficulty of stepping out of one's own head, but more relevant here is that the terminology used in the article is in general quite confusing. In the lingo above the "user" would be, I think, the "injector", and "system" and "subsystem" would be the "client".

Introw a big part of the problem here is that the rest of the article has significantly changed while these two entries have not. If I'm decoding what you're saying correctly:

• Dependency injection diminishes encapsulation by requiring injectors of a client to know how it works and not merely what it does.

• Dependency injection increases coupling by requiring the injectors of a client provide for the needs of that client.

Not 100% sure that's what you mean to say but if so I strongly disagree with the first and agree with the second. DI doesn't require injectors know how a client works at all. It only requires that injectors know what implementations are needed. DI does result in a form of coupling between the client and the injector that didn't exist when the injector didn't exist. However, the argument is that this coupling is less than the coupling that would have resulted if the client made its dependencies itself. Any claims of advantage and disadvantage regarding coupling should be consistent. They should not directly contradict without distinguishing between what each really means by coupling and what is being coupled to what. Done this way it can be seen that both are in fact true and a choice is simply being made between forms of coupling. Either that or we give up on making the truth clear and report that DI's impact on coupling is debated.

It's true that A DI client is much less self sufficient then it would be if it built dependencies itself. However, a simple factory method that injects and produces the client can be very self sufficient. Once built, nothing that uses it need have any knowledge of what it takes to build it. Galhalee (talk) 10:02, 5 August 2015 (UTC)

That's really confusing though since the actual relationship is that the injector creates the service, then provides that service to the client, and then uses the client to do some work.

Introw the injector should not be using the client. Galhalee (talk) 10:02, 5 August 2015 (UTC)

In common programming terminology a client is a thing that is doing the using not the thing being used.

Introw Correct, though remember one can link together 3 objects in a line with the middle one taking on both the roles of client and dependency. Galhalee (talk) 10:02, 5 August 2015 (UTC)

In the article the perspective is the reverse of usual,

Introw I certainly don't think it is. Clients use. Dependencies get used. Injectors don't use. They construct and inject dependencies into clients and take a vacation before any using happens at all. Galhalee (talk) 10:02, 5 August 2015 (UTC)

probably because it's thinking of being a "client" of the injected service. Additionally calling the system that creates the dependency the "injector" could easily be confused as referring to a mechanical part of a framework (like a provider in Guice, for example) and emphasizes the wrong thing. It emphasizes its role in the creation of the dependent service rather than it's role as the creator and user of the "client".

Introw again, injectors should not use Galhalee (talk) 10:02, 5 August 2015 (UTC)

One final trouble with that emphasis and naming is that we're discussing the difference between with and without DI, and you want the terms to refer to both cases generically, but in the non-DI case there is nothing to inject and no injected service for the "client" to be client of. Honestly open to ideas here on how to be clear and in line with the other terminology in the article without being confusing.

Introw injected or not a dependency still gets used and a client still uses. Galhalee (talk) 10:02, 5 August 2015 (UTC)

• The citations are blog posts. I really have no issue with that since the posts back up and explain their claims to some degree. The one you provide looks good too, but then again it's also just a blog post. There's also http://stackoverflow.com/questions/18547909/what-would-be-the-most-powerful-argument-for-writing-solid-applications, but a forum post seems even less authoritative to me. It sounds like you don't have any real issue with the sources, though in your deletions you repeatedly mentioned that this is nor the point of the cited material. Can you explain your issue there? If a citation supports a piece of information in the Wikipedia article, what does it matter that the document being cited treats that as just a small or a supporting part of a larger or different point?

Introw if the claim were stated in a less inflammatory way the need for a strong citation would be less. That the citation is a blog post makes it weaker than a book (meh). That the blog isn't even mainly about this point makes it even weaker. This means less effort was put into this particular point. There's also the, rather subjective, issue that the blog doesn't make the point particularly well. This bothers me mostly because I truly believe there is a valid point to be made here and it should be made well. Please help me find some better sources and a better way to word these points. Galhalee (talk) 10:02, 5 August 2015 (UTC)

• According to that coupling article it would be either "content coupling" or "control coupling". In my experience those are not commonly used or well known terms, so I don't think adding them to the article makes it more understandable. I won't make a claim that arity and coupling are unrelated since passing in a service as a parameter (somehow) is the method by which DI increases coupling. But it's definitely a separate issue. Arity is something people also often try to lower, but it's usually not quite as troublesome as coupling. Still if you want to add arity to the list of disadvantages I won't argue against you. I agree in spirit with your sentiment that hidden coupling is still coupling, but I don't follow what you're getting at here.

Introw I see the main alternative to DI in this context as a class that builds it's own dependencies. A class that does this has hidden coupling and hidden dependencies. This class can have a nice clean no argument constructor (the best arity) but it is coupled to the concrete implementations of its dependencies in a way that can't change without refactoring the client. DI will let you make these changes and only the injector would need to change. This follows the open closed principle. I offer this as a demonstration of how to explain coupling. You're claiming that coupling increases in DI due to clients exposing their needs. I'm asking why that is worse coupling in this context. I'm asking if it isn't simply coupling in a different form. One that may or may not be prefered. Galhalee (talk) 10:02, 5 August 2015 (UTC)

• Alright here you're distinguishing between an "injector" and a "user" of a client. So maybe I guessed wrong on the terminology when I discussed it above. I suppose that supports my contention that it's confusing.

Introw ...an injector and user of a dependency. Yes it's confusing. If it wasn't it'd be easier to explain. Galhalee (talk) 10:02, 5 August 2015 (UTC)

• I disagree with you that the disadvantages listed should necessarily be "critical" or "devastating". If the advantages/disadvantages were a debate, that would make sense. But the article should not be making an argument. It should be informing. To that end being comprehensive is an important goal even if some points are of relatively smaller concern that others (not that I think these concerns are relatively smaller, the tension between information hiding/encapsulation/loose coupling and configurability/flexibility is important). As long as they are real, not overly use-case specific, and supported they belong.

Introw The advantages / disadvantages sections are a debate. Our job as wikipedia editors is to report on the debate (not have the debate). Film critics are critical and their reviews can be devastating and appear in wikipedia when noteable. Yes, it should be informing, comprehensive, and widely applicable Galhalee (talk) 10:02, 5 August 2015 (UTC)

• Finally, a note on edits. I must admit to feeling somewhat accused here. First, not all of those IPs are me. Some definitely are, likely when without my password handy. In particular I'm not going to Godwin a wikipedia article. I also think it's a bit disingenuous to complain about instability when so many of the edits are yours. But I do agree with you about one thing, I absolutely assume you are acting in good faith. I can only hope anyone reading this accepts my assurances that I was as well. Perhaps I took Wikipedia:Be_bold to much to heart here.

Introw (talk) 18:31, 29 July 2015 (UTC)

Introw I held a mirror up to the activity on the page to show you how things appeared to others. I stand by my statements. These two entries have not been stable and are in need of improvements to make them stable. When I removed or edited them I made sure I was signed in. I did attempt to stabilize them. Yes I'm making a lot of edits. I'm hoping to get the page past Start-Class. I've had much of my contributions removed. I didn't repeatedly bring them back in their previous form. I looked for ways to improve.

Look I need help. You're not the only one adding them. I'm not the only one removing them. I've already tried to fix them and failed. I'm asking you to please take a turn at it. Feel free to post versions in here if you like. I'm not adding anything to the advantages/disadvantages section `till we work this out.

I do apologize for the lateness of this response. Please get my attention in your next post by using

{{ping|Galhalee}}

@Introw: Please find my responses to your points above. Galhalee (talk) 10:02, 5 August 2015 (UTC)

@Introw: I'd like your opinion on this update of the Assembling examples section. I'm hoping it will clear up some of the injecting/using confusion.