Comments on: The Dependency Inversion Principle

By: Keshav Baweja

Keshav Baweja — Thu, 16 Aug 2012 04:47:00 +0000

Hi, the blog is easy to read but is a copy of Robert Martin’s post on Object Mentor.

By: recepd

recepd — Tue, 14 Dec 2010 11:50:44 +0000

Greate article about dependency..

Thanks.

By: anon

anon — Mon, 04 Oct 2010 18:34:08 +0000

The part of your example that confuses me is that I don’t think the EncryptionService class should even be concerned about reading or writing to/from streams. Wouldn’t you say that the whole problem would go away if you followed the Single Responsibility Principle and exposed the private method as public? Now the service would be as mobile as possible

I feel like this weakens your example as a whole.

By: Gabriel N. Schenker

Gabriel N. Schenker — Fri, 01 Oct 2010 17:20:37 +0000

@Netizen: you are using strong words here! You are accusing me of not contributing own stuff but stealing from others and just put my name on it…
If that is your opinion then I have nothing to say any more and just let other readers decide. But if this was not your intention then pay attention what words you use when criticizing others contributions.
Not everybody can be an inventor. We also need engineers to make things usable in every days life. Whenever I copy things from other sources I tend to give cross references. If I forgot one then I am sorry for that. It was not by intent.

By: Netizen

Netizen — Wed, 22 Sep 2010 23:28:40 +0000

Gabriel plagiarized this from Robert Martin. It’s ok to include others writing as long as the original author is given due credit. For example, the section “Why call it dependency inversion?” is copied literally word-for-word from Mr. Martin’s article: http://www.objectmentor.com/resources/articles/dip.pdf

By: Chuan Li

Chuan Li — Wed, 02 Dec 2009 13:44:04 +0000

Simple put, a compilation module, whether a class, a method, should know as little as outside scope as possible.

By: Yann Schwartz

Yann Schwartz — Mon, 02 Feb 2009 21:41:41 +0000

@Ryan

Oops. Sorry, I had actually read “Dependency Injection” instead of “Dependency inversion”. So, agreed, this example shows dependency inversion, in a way (even if you could get away with it with using Stream instead of your own home-cooked interfaces).

By: Ryan Martin

Ryan Martin — Mon, 02 Feb 2009 13:34:06 +0000

@Yann

I think he’s trying to illustrate a point using familiar concepts.
You can argue the usefulness of the example as an implementation but I think he illustrates the usefulness of DI quite nicely.

By: Yann Schwartz

Yann Schwartz — Mon, 02 Feb 2009 08:55:05 +0000

Hello. While I agree DI is a good thing, your example is not really telling, since plain old polymorphism would do nicely here, like another commenter said : there is a nice abstraction of something meant to write or read bytes, it’s called System.IO.Stream…

By: MrTea

MrTea — Mon, 02 Feb 2009 08:10:43 +0000

@Kim

Personally I would favour di in all cases, apart from anything else it’s more testable, and another key benefit is DI will make it easier for other developers to debug/work on your code.

Take an example where another developer comes in and needs to change your encryption mechanism, far better that they only have to focus on the encryption code itself than to have to wade through the unrelated logic to do with opening files etc.

If they do need to alter the file reading/writing part of the logic, again they can focus on just that (in isolation) and as long as it doesn’t break the contract as defined by the interface, then everything should continue to work fine afterwards.