Are Dependency Inversion and Design for Interfaces the same principles?

Question

Does the principle “Dependency Inversion Principle” (DIP) and the “Principle of constructing the principle of interaction” comply with the same principle? If not, what's the difference?

EDIT

To clarify and narrow the context a bit: by interface I mean a programming interface, such as a Java interface or a pure abstract base class in C ++. No other "contracts" are involved.

Answer 1

I just wanted to submit and quote Derek Greer on another question, very similar to this one , since he really answers this question, in my opinion.

"The principle of dependency inversion does not apply to the simple practice of abstracting dependencies using interfaces (for example, MyService → [ILogger ⇐ Logger] ).

Although this separates the component from the specific dependency implementation details, it does not invert the relationship between the consumer and the dependency (for example, [MyService → IMyServiceLogger] ⇐ Logger ). "

Answer 2

Dependency inversion ensures that your higher-level modules are independent of lower-level modules. Thus, your application logic is independent of your business model or business logic. There is a clear separation of problems.

The principle says that your application defines and owns the interface that your business level should implement. Thus, your business layer depends on your interface defined by your application. Thus, dependencies are inverted.

By expanding this, if you now have three applications, each with its own interfaces implemented by the business layer, your business layer can change, and as long as they implement the interfaces as they should, your applications will not be wiser.

A good Java example of this principle and how such a project will be structured can be found here on my website: http://www.jeenisoftware.com/maven-dip-principle-example/

Dependency inversion is associated not so much with design as with the interface, although this happens, it is more related to the implementation of the service. In other words, a kind of design-oriented design.

Answer 3

Interface design (as an option design by contract ) supports dependency inversion. Both reduce grip. But:

• The design of the interfaces and DBC says nothing about how objects are created (for example, DIP, abstract factories , factory methods ).
• Dependency inversion ( dependency injection ) usually depends on the interfaces, but focuses on the life cycle of the object, and not on the design of the class. You can use DIP with abstract base classes if you want, so you really are not committed to clean interfaces.

Approaches tend to complement each other.

Answer 4

“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 that can be supported in various ways; In a language that has a Java-like class system, you can use interfaces to avoid specific class dependencies. "dependency injection" is another method that is often based on the existence of interfaces for work (but this is not always necessary - it depends on the language). I would say that dependency injection supports the concept of design by contract.