7

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

EDIT

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.

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
eljenso
  • 16,789
  • 6
  • 57
  • 63

4 Answers4

3

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)."

sepehr
  • 17,110
  • 7
  • 81
  • 119
GR7
  • 5,083
  • 8
  • 48
  • 66
2

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: http://www.jeenisoftware.com/maven-dip-principle-example/

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.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
Adam Davies
  • 2,742
  • 4
  • 33
  • 52
0

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.

Community
  • 1
  • 1
Pontus Gagge
  • 17,166
  • 1
  • 38
  • 51
  • A (pure) abstract base class = interface. – eljenso Mar 03 '09 at 12:32
  • 1
    And where does the DIP talk about object creation/lifecycles? Maybe some patterns that fall into the "creation" or "lifecycle" category go well with DIP, but surely DIP as a principle doesn't care about that and is all about design. – eljenso Mar 03 '09 at 12:36
  • 2
    Dependency *inversion* and dependency *injection* are far from being the same thing. – Rogério Aug 22 '13 at 18:33
-1

"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".

troelskn
  • 115,121
  • 27
  • 131
  • 155