Dependency Injection Breaks Encapsulation

[TomB]

@tony_marston404

I have never claimed that my method of not implementing is better, just that the circumstances do not warrant the use of DI, which makes DI unnecessary.

“DI IS EVIL” “DI Breaks encapsulation”… try again.

@tony_marston404

My opinion on DI is held my many others, so my point is perfectly valid.

And we’re back at A) you keep making these claims but can never substantiate them with code examples or answer the question “Why?”

[tony_marston404]

@TomB

Because nowhere does it mention a scenario where DI is “inappropriate”.

Have you actually read that article? It quite clearly demonstrates a “copy” program which is used to copy a file from one device to another. In the original implementation there was only one input device and one output device, so the copy program had all that device code within its internals. This means that the “copy” program is restricted to only being able to function with those devices. If you had actually read the article you would have seen the following text:

One way to characterize the problem above is to notice that the module containing the high level policy, i.e. the Copy() module, is dependent upon the low level detailed modules that it controls. (i.e. WritePrinter() and ReadKeyboard()). If we could find a way to make the Copy() module independent of the details that it controls, then we could reuse it freely.We could produce other programs which used this module to copy characters from any input device to any output device. OOD gives us a mechanism for performing this dependency inversion.

The article then goes on to describe how it is possible to remove all the device code from the “copy” program and place it into a series of separate classes, one for each device. All that each of these classes requires is a read() method and a write() method. The “copy” program does not know or care about which device it is working with, it simply uses whatever objects have been injected into it. This also means that it is possible to create and use classes for new devices without having to amend the “copy” program.

Note here that two device objects have to be injected into the “copy” program - an input device and an output device, and each of these objects can be supplied from a number of alternative classes.

This tells me that DI is appropriate in those circumstances where a dependency can be supplied from a collection of possible candidates. The choice of candidates is made outside the program so the program does not have to make the choice itself.

So if DI is appropriate when there are several candidates for a single dependency, it is logical to state that where there is only a single choice for a dependency, and not any alternatives, then DI is not appropriate.

Has the penny dropped yet?

[tony_marston404]

@TomB

tony_marston404:
I cannot. There are three parts to that question, and I cannot give the same answer to all three parts.

And again an example of tony’s favourite “I refuse to answer direct questions” tactic.

There you go, misrepresenting the facts again. While I refused to supply a single answer to cover all three points, I did supply a separate answer to each point

[TomB]

@tony_marston404

So if DI is appropriate when there are several candidates for a single dependency, it is logical to state that where there is only a single choice for a dependency, and not any alternatives, then DI is not appropriate.

Negative conclusion from affirmative premises

This is so backwards I can’t do anything but laugh at you.

[tony_marston404]

@TomB

You cannot guarantee encapsulation without information hiding. If you don’t want to allow encapsulation to be broken you must use information hiding.

I disagree. Encapsulation was never meant to mean information hiding, so it is definitely possible to have encapsulation without information hiding. This also means that encapsulation is not broken if there is no information hiding.

[TomB]

@tony_marston404

I disagree. Encapsulation was never meant to mean information hiding, so it is definitely possible to have encapsulation without information hiding. This also means that encapsulation is not broken if there is no information hiding.

And you’re still missing the point. You cannot know whether encapsulation has been broken or not if you don’t have information hiding. With information hiding you know there is no way that encapsulation was broken.

I’m still not sure what point you’re even trying to make. Yes they’re separate concepts, yes, you don’t understand why Information Hiding is important (Although I’m guessing it’s because your code doesn’t already use it and/or it’s not supported in PHP4)… but what does it matter here?

[tony_marston404]

@RavenVelvet

Keep trying Tony. Never give up.

No, I won’t. My motto is “Nix Illegitimi Carborundum”

[tony_marston404]

@TomB

However, even if it weren’t, by that article DI is appropriate when:

• You have more than one object
• Those objects need to talk to one another

It is not about the number of objects, it is about dependencies, specifically when a single dependency can be supplied from multiple sources. In that “copy” program each of the input and output devices can be supplied from one of several candidates.

@TomB

Thirdly, that article does nothing to actually define “appropriateness” it highlights one of the advantages of DI and nothing else. There’s nothing that says “It shouldn’t be used when…” or “In other scenarios, [alterantive] is more beneficial”.

It clearly shows that where you have a single dependency which can be supplied from multiple sources then DI has definite advantages. Having a dependency which can only be supplied from a single source clearly does not fit this pattern

[TomB]

@tony_marston404

It clearly shows that where you have a single dependency which can be supplied from multiple sources then DI has definite advantages. Having a dependency which can only be supplied from a single source clearly does not fit this pattern

But it’s equally appropriate when you only use one specific class as the dependency.

If you disagree with that statement, please finish this sentence:

“When there is only one possible dependency implementation, DI is not appropriate because…”

and then

“and… [alternative] is more appropriate because…”

[tony_marston404]

@s_molinari

tony_marston404:
Modular, yes. Testable, yes. Decoupled? No.

Ok. Agreed, I meant to say loosely coupled, not decoupled.

You do realise that by agreeing with me, an OO heretic, in a public forum, then you are opening yourself up to the same levels of abuse and personal attacks that I am forced to endure?

[tony_marston404]

@TomB

tony_marston404:
I have never claimed that my method of not implementing is better, just that the circumstances do not warrant the use of DI, which makes DI unnecessary.

“DI IS EVIL” “DI Breaks encapsulation”… try again.

For you information I have recently come across a new article on the interweb thingy at http://davidscode.com/blog/2015/04/17/when-does-dependency-injection-become-an-anti-pattern/ this contains the following observation:

Just like any pattern it can become an anti-pattern when overused, and used incorrectly. If you are never going to be injecting a different dependency why are you using a dependency injector? If you say because it makes unit testing easier, think about it a little harder,

So he agrees with my notion that when DI is overused, or used incorrectly, it becomes an anti-pattern (which is OO-speak for “not good”).
He also agrees with my point about injecting a single dependency which never changes.

@TomB

you keep making these claims but can never substantiate them with code examples or answer the question “Why?”

Because I shouldn’t have to provided code samples for every point that I make.

[Jeff_Mott]

@tony_marston404

Have you actually read that article?

@tony_marston404

It quite clearly demonstrates a “copy” program…

It seems you looked at one example of an appropriate use of DI and concluded that this was the only appropriate use of DI. It isn’t.

[tony_marston404]

@TomB

This is so backwards I can’t do anything but laugh at you.

I’m glad you find it so amusing. If I can make at least one person laugh each day then it gives some meaning to my existence.

[TomB]

@tony_marston404

So he agrees with my notion that when DI is overused, or used incorrectly, it becomes an anti-pattern (which is OO-speak for “not good”).He also agrees with my point about injecting a single dependency which never changes.

Just because one person agrees with you doesn’t make you right… it just means his opinion is as wrong as yours. The author in question is very confused as well. You’re not supposed to use a DI container during unit tests and for their second point, if you’re injecting a service locator into a class being tested then you are also testing all the classes in the service locator (And the service locator as well). Imagine a service locator that had a database connection and was used by the class being tested. In this case, you’d have to have an active database connection with specific data to test the class. Most of the time this really is not what you want to do.

The problem with this approach, is that when a test fails you don’t know if it’s because of a bug in:

• The class you’re testing
• The service locator
• One of the classes being retrieved from the service locator

This is clearly not a “unit” test as you’re testing more than one unit and why we inject mocks during unit tests.

@tony_marston404

Because I shouldn’t have to provided code samples for every point that I make.

You never substantiate your claims with anything. Code examples would be the simplest way to do this which is why I ask for them.

[tony_marston404]

@TomB

And you’re still missing the point. You cannot know whether encapsulation has been broken or not if you don’t have information hiding. With information hiding you know there is no way that encapsulation was broken.

No, you are. Encapsulation has nothing to do with information hiding. This sentiment is echoed in the following articles:

Encapsulation is not information hiding

http://www.tonymarston.net/php-mysql/abstraction.txt
http://web.archive.org/web/20090505194203/http://homepage.mac.com/keithray/blog/2006/02/22/#EncapsulationHiding
http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding
http://stefanoricciardi.com/2009/12/06/encapsulation-and-information-hiding/
http://nat.truemesh.com/archives/000498.html

[TomB]

@tony_marston404

No, you are. Encapsulation has nothing to do with information hiding. This sentiment is echoed in the following articles:

Did you even read my post? I was agreeing with you they are separate concepts. However, in java, php and most other OO languages you must use information hiding to enforce encapsulation. Did you see my example code or was it too complicated to understand?

Without information hiding, I cannot guarantee this will not break:

class Player {
	public $weapon;

	public function __construct(Weapon $weapon) {
		$this->weapon = $weapon;
	}

	public function shoot() {
		$this->weapon->fire();
	}

}

Because elsewhere in the code this might have happened:

$player->weapon = null;

Information hiding is the only way to guarantee that this has not happened.

[tony_marston404]

@TomB

If you disagree with that statement, please finish this sentence:

“When there is only one possible dependency implementation, DI is not appropriate because…”

… it was designed for those circumstances where a dependency can be supplied from a number of alternative sources.

This means that if the number of possible sources is greater than one then DI is appropriate, but if the number of sources will never be greater than one then DI is not appropriate.

[TomB]

@tony_marston404

… it was designed for those circumstances where a dependency can be supplied from a number of alternative sources.

This means that if the number of possible sources is greater than one then DI is appropriate, but if the number of sources will never be greater than one then DI is not appropriate.

So “…because I said so”. What a fantastic non-answer.

But that’s not a reason because it’s factually incorrect DI is one of many methods that allows one object to be visible to another, that is all. it wasn’t “designed for those circumstances where a dependency can be supplied from a number of alternative sources.” at all!

You still didn’t answer why an alternative is “more appropriate”.

[tony_marston404]

@Jeff_Mott

It seems you looked at one example of an appropriate use of DI and concluded that this was the only appropriate use of DI. It isn’t.

Can you justify that statement? The original definition of DI carries more weight than the multiple redefinitions that have fallen out of the sky since then.

[tony_marston404]

@TomB

However, in java, php and most other OO languages you must use information hiding to enforce encapsulation.

I disagree. Encapsulation has absolutely nothing to do with information hiding.