Are “Dependency Inversion” and “Design to Interfaces” the same principles?

0 votes
asked Mar 3, 2009 by eljenso

Do the "Dependency Inversion Principle" (DIP) and "Design to Interfaces Principle" express the same principle? If not, what would be the difference?


To clarify and narrow down the context a bit: by interface I mean a programmatic interface, like a Java interface or a pure abstract base class in C++. No other 'contracts' are involved.

4 Answers

0 votes
answered Jan 3, 2009 by troelskn

"design by contract" and "dependency injection" are very closely related, but have different levels of abstraction. "design by contract" is a very general design principle, which can be supported by various techniques; In a language that has a Java-like class system, you one technique is to use interfaces to avoid concrete class dependencies. "dependency injection" is another technique, that often relies on the existence of interfaces to function (but need not always do that - It depends on the language). I would say "dependency injection" supports the principle of "design by contract".

0 votes
answered Jan 3, 2009 by pontus-gagge

Design to interfaces (as a variant of design by contract) supports dependency inversion. Both reduce coupling. However:

  • Design to interfaces and DBC says nothing about how objects are created (e.g. DIP, abstract factories, factory methods).
  • Dependency inversion (dependency injection) generally relies on interfaces, but focuses on the object lifecycle rather than class design. You can use DIP with abstract base classes if you wish, so you aren't really committed to pure interfaces.

The approaches tend to complement each other.

0 votes
answered Mar 3, 2011 by gr7

I just wanted to pitch in and quote Derek Greer on another question very similar to this one, since it does answer this question nicely, in my opinion.

"What the Dependency Inversion Principle does not refer to is the simple practice of abstracting dependencies through the use of interfaces (e.g. MyService → [ILogger ⇐ Logger])."

While this decouples a component from the specific implementation detail of the dependency, it does not invert the relationship between the consumer and dependency (e.g. [MyService → IMyServiceLogger] ⇐ Logger)."

0 votes
answered Mar 14, 2013 by adam-davies

Dependency inversion is ensuring your higher level modules do not depend on lower level modules. So your application logic does not depend on your business model or business logic. There is a clear separation of concerns.

The principle states that your application defines and owns an interface that your business tier must implement. This way your business tier depends on your application's defined interface. Thus the dependencies are inverted.

Expanding this out, if you now have three applications, each with their own interfaces implemented by the business tier your business tier can change, and as long as they implement the interfaces as they must then your applications are none the wiser.

A good java example of this principle and how such a project would be structured can be found here, on my website:

Dependency inversion is not so much about design to interface, although that is what is happening, it's more about implementing to a service. In other words a kind of service oriented design pattern.

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter