10

I'm not able to figure out the difference between the Dependency Inversion Principle (one of the S.O.L.I.D principles) and the general 'Code to Interfaces' or Separated Interface pattern. All of them advocate creation of a layer of abstraction to decouple the lower level and the higher level modules.

The DI principle envisages creation of interfaces to interact between the higher and lower level modules, but also insists that the interfaces must be a part of the higher level package.
Why should this be a part of higher level and not lower level ? It's is the lower level that's exposing its behavior, so shouldn't the decoupling interfaces be a part of lower level? What if there are multiple higher level modules depending upon the same lower level?

Or else,
Why not make a separate package in which to place all the interface, which then can be used by both higher level and lower level? (This is envisaged by the Separated Interfaces pattern.)

My dilemma is, I am not able to figure out the relative use and benefits or each of them.

Please do not quote article by Derek Greer or Robert Martin. I have read those articles, but confusion still persists.

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
aknon
  • 1,408
  • 3
  • 18
  • 29
  • 1
    I've voted to close as "too broad". I think this question demands lengthy, possibly conflicting answers and isn't a good fit for this site. – Duncan Jones Dec 20 '13 at 09:27
  • My one sentence answer was too hasty, having not really studied the question properly. – Ross Drew Dec 20 '13 at 09:28
  • Specifically, are you comparing the [DIP from Uncle Bob](https://en.wikipedia.org/wiki/Dependency_inversion_principle) vs the [Separated Interface in Fowler's P of EAA](http://martinfowler.com/eaaCatalog/separatedInterface.html) – StuartLC Dec 20 '13 at 09:29
  • 1
    Yes it's uncle Bob's DIP and Separated Interface from 'Patterns of Enterprise Application Architecture'.
    Comparison between these also exist in the Dereck Greer http://aspiringcraftsman.com/2008/12/28/examining-dependency-inversion/     – aknon Dec 20 '13 at 09:36
  • not too broad i think – Oliver Watkins Dec 20 '13 at 09:40
  • I don't think it's too broad but there is more than one question in here. One of the difference between the two and the other on the reasoning behind package management. – Ross Drew Dec 20 '13 at 09:41
  • 1
    @Ross: true. The major dilemma is of the specific package management envisaged by DI principles – aknon Dec 20 '13 at 16:34

3 Answers3

4

Dependency Inversion is concept that is building block for Dependency Injection frameworks such as Spring, Guice, etc. What it says is that a component should not look up its dependency but should be injected its dependency from outside. A dependency for a component can be an interface or another class. When dependency is an interface, then the component is flexible to work with variety of implementations.

Let's take an example: Let's say someone is writing a component which needs to make some service calls. If the component developer thinks that the service calls has to be always made using HTTP, then, she will make a HTTP Client a dependency. Now, this restricts the components utility to only be able to call HTTP-based services. However, same developer could have created an interface, lets say - GenericExternalServiceInvoker, and have implemented two implementations - one which made use of HTTP and another that made use of some kind of queuing system like ActiveMQ. Use of interface enabled the component developer to create components that are useful in much broader way.

In the above example, we assumed that DI was in place. Because the dependency was being injected from outside. Component developer could have made another design choice and could have instantiated HTTP Client in the code, and thus making it difficult for users of the component to change its behavior, if need had arisen, to use something else other than HTTP.

So, in summary, one should use DI so that component does not depend on its dependency in hard-wired manner. By making component's dependency an interface, a further flexibility gets built into component. The second principle, Code to interfaces, is guiding factor for the developer to have picked an interface as dependency rather than a concrete class.

Wand Maker
  • 18,476
  • 8
  • 53
  • 87
  • When you say 'DI', do you mean Dependency Injection or Dependency Inversion? :) – fiskeben Dec 20 '13 at 09:34
  • By DI it meant Dependency Inversion Principle, proposed by Robert C. Martin ( not dependency injection ) – aknon Dec 20 '13 at 09:40
  • @Wand Maker: Plausible explanation. But please clarify, In your example, HTTP or QueueSystem are a part of higher level module and services ( to be consumed by http or queue system ) are a part of lower level module ? – aknon Dec 20 '13 at 09:53
  • The question still remains --> Why should the interfaces be packaged in the higher level module package ? – aknon Dec 20 '13 at 10:20
  • @aknon HTTP & QueueSystem are lower level systems, and the Component that is tasked to perform stuff by calling the external services is an higher level component. The "external services" itself are not really part of the picture here, you can ignore it for a bit. Alternative example could have been that assume you wanted to save data - either in file system or RDBMS - and by writing an abstraction for "saving content" in the form of interface and providing two implementations, you could achieve a dependency inversion. DI says that component should depend on abstracted lower level modules – Wand Maker Dec 20 '13 at 17:58
1

I suppose you meant what is the difference between Dependency Injection and programming to interfaces

Programming to Interfaces

Programming to interfaces is a practice in software development, where different objects interact with each other via public interfaces. This allows for a greater flexibility, as one may switch easily from one interface implementation to another, with minimal changes to the codebase, and may even avoid recompilation of the code.

Dependency Injection

Dependency injection is a mechanism that allows object instances to be created by the framework rather than the developer. In most cases, an object may require some additional objects (called dependencies) to already exist and be passed in the constructor of the current object, or to a property of that object, in order for it to be usable. Dependency injection is a mechanism that allows a framework to provide and set these when constructing the required object (injecting them). Usually, the framework knows what to do based on external configuration, or code inspection.
The dependency injection paradigm relies on the programming to interfaces practice (that is why I described it first), as the dependencies are usually exposed via their public interfaces. Thus, different implementations can be used based only on configuration changes. This would enable easily using a mock setup of objects when testing certain aspects of the application.

Usually, dependency injection is referred to an inversion of control mechanism, as it causes the framework (meaning the application code) to deal with object creation rather than manual instantiation (done by the developer).

as per aknon's comment:

Is dependency injection same as dependency inversion?

Not necessarily. Dependency inversion might also be called the refactoring process of inverting the dependencies between two objects. For instance class A may depend on class B prior refactoring, and after that you may have class B to depend on class A instead, thus inverting their dependencies. Dependency injection is a mechanism provide dependencies without writing code for that explicitly.

Update

For more information on the term dependency inversion I recommend you to read this article from Rich Newman. It is part of series of articles addressing the Microsoft Smart Client Software Factory technology (now an outdated one), but the article is neutral enough and can stand by itself.

See also:

Community
  • 1
  • 1
Ivaylo Slavov
  • 8,839
  • 12
  • 65
  • 108
0

Programming againts interfaces is usually required for complex dependency injection. I don't think that putting the APIs in a separate module, or just in a different package, or side-by-side the implementations can be right or wrong in principle. It depends: most projects I've seen bundle interfaces and implementations together, but there are times where the api binaries are even shipped in a different archive, like servlet-api.jar or logging-api.jar.

In fact I don't see any value in comparing the twos on such a detail. After some time I decided that common sense is the only principle that always applies, and when reading about a methodology/pattern/whatever one should take into account that it's author sells books, speaks in conferences and in general makes a business out of it. That's not to say these readings are useless, quite the opposite: they are a fundamental way of learning from others' successes and failures. But the arguments should be taken with a grain of salt, because maybe the solution doesn't fit well in a particular project.

The only "bible" in this field are things that can be somehow measured, like data structures and algorithms, and specifications. I wouldn't bother who is more right between uncle Bob and Martin Fowler about where to put your interfaces: put it wherever you are comfortable with and in a place where it works for you. After some time, if you made the wrong decision, you'll always be able to refactor and move things around.

Raffaele
  • 20,627
  • 6
  • 47
  • 86
  • Most part of this answer comprises of what you think about designs in general with no proper reference to the question being asked. There might be people like me who is waiting for some insight to the question asked by eagerly reading the answers might get disappointed – pratim_b Dec 20 '13 at 09:49
  • @rookieB I know. But if it can't be measured it doesn't exist. My answer is that you can adopt DI and programming against interfaces without bothering about where to put APIs. It doesn't matter at the application level. It's more of a deployment/code management thing – Raffaele Dec 20 '13 at 09:52