Talk:Dependency inversion principle

Introduction

I miss a reference to the original author of this principle Robert C. Martin. The text in the presentation of the concept is the same as Martin wrote in several articles or books mentioned in the History section. --Klodr (talk) 01:08, 7 January 2013 (UTC)

Description

It's wrong that the interface which defines the services required by the higher layers is in the same package. That will result in an undesirable impact to re-usability of lower layers. For example, packages that defines persistence or logging sub-systems. The perfect DIP implementation requires that both layers depend on abstractions in separate libraries or packages. The dependency inversion is only by name, defining the policy as an abstraction of services, not for implementation or compilation.

--Klodr (talk) 01:08, 7 January 2013 (UTC)

Agree with Klodr. In fact, Martin said the same thing in The Dependency Inversion Principle. Page 7, Section near Figure 4 "Abstract Layers" states: Each of the lower level layers are represented by an abstract class. The actual layers are then derived from these abstract classes. Each of the higher level classes uses the next lowest layer through the abstract interface. Thus, none of the layers depends upon any of the other layers. Instead, the layers depend upon abstract classes.

Perhaps this is my interpretation, but I actually read that the Abstract Classes (Interfaces) should form an entire Layer itself. This entire Layer should be Abstract.

--Gary.plattenburg (talk) 14:33, 26 August 2013 (UTC)

Rewritten all the description section. Introduce other sections using Robert M. Martin as main reference. Klodr (talk) 19:55, 18 January 2015 (UTC)

Looks like your changes were reverted, Klodr. The article still states that the abstraction is part of the higher layer, which seemed mighty weird to me because it actually introduces more coupling than just using stuff from the lower layer would.

In fact, I still don't know what DIP is all about. Isn't it just another name for good old interface based design? Couldn't you achieve the same thing with a facade or adapter between the layers? What is "reusability of higher layers"? Why is DIP a thing? Which advantage do I get from the extra effort? Maybe a negative example would clear that up, something where the traditional way would get me in actual trouble. Thanks.

--84.245.149.53 (talk) 11:40, 7 April 2016 (UTC)

The article says: "Nevertheless the ″inversion″ concept does not mean that lower-level layers depend on higher-level layers". The first example of the implementation is the common --I would say ingenious-- understanding of the principle. The second example, shows clearly a better implementation: all concrete layers should depends on abstractions. Also it is notable that the different layers not necessarily means unit deployments. Although is better to separate the layers in different deployment packages if you want a real decoupling effect. For example, you could replace in any moment, the lowest concrete parts without affecting the highest, because they are all linked by abstractions. That the effect of follow the GoF principle of: ""Program to an interface, not an implementation".

Klodr (talk) 05:03, 17 July 2016 (UTC)

Introduction Rewrite Request

The introduction does not clearly state the principle being discussed in the language of OOP. 'High-level', 'low-level', and 'module' could have several interpretations. It would be better to simply talk of classes and inheritance, which is the common language of OOP. I request that someone familiar with this subject write a better introduction. --BBUCommander (talk) 19:58, 28 January 2013 (UTC)

The introduction begins within the context of OOP. Then, shouldn't be confused to anyone the concepts of 'High' or 'Lower' levels meaning under the further explanation/description. Klodr (talk) 19:59, 18 January 2015 (UTC)

Proposal to merge with Protocol (object-oriented programming)

If you read http://www.objectmentor.com/resources/articles/dip.pdf you can actually see that in both examples (copy program and button-lamp) there is exactly one thing going on: replacing concrete types with abstract types, also known as protocols/interfaces. My sense is that these papers are actually very clear and direct arguments in favor of widely adopting the use of interfaces and protocols. Of course there is always the possibility of over-engineering, but on balance it is a very good and worthwhile point to make. Less convincing is the notion that the idea of applying a particular tool (in this case, the "tool" is protocols/interfaces) deserves its own phrase, in this case "dependency inversion principle". Anyway, that's the argument to merge. I'm less inclined to merge this article with Inversion of Control, because the Inversion of Control article is pretty weak. I can't tell if anyone actually uses the phrase "inversion of control" anymore, or if it's a forced meme intended to help Martin Fowler sell his books... 173.239.78.54 (talk) 20:24, 29 October 2013 (UTC)

The two articles are defining two different concepts. Using interfaces are a mean to implement DIP, but not the only one. In other languages you could use abstract classes or other mechanisms. Also the protocol concept extends its definition to more extended context in other programming paradigms.

Klodr (talk) 20:05, 18 January 2015 (UTC)

Additionally, this is part of SOLID, and thus is necessary in order to understand the complete SOLID concept. --WiseWoman (talk) 21:33, 16 December 2018 (UTC)

Example needed

This article is currently rather abstract. It could use a concrete example with a specific application. Class designations like "policy", "mechanism", and "utility" are rather vague. -- Beland (talk) 20:35, 7 May 2015 (UTC)

A concrete example was included. Klodr (talk) 16:49, 26 March 2016 (UTC)

In the example using UML notation, arrows describing implementations should be drawn with dashes. The use of continuous line with a white triangle denotes inheritance, which is a different notion (an interface could inherit from another interface to extend it, but a class can only implement an interface, not inherit from it). Teuxe (talk) 15:17, 30 August 2018 (UTC)

Abstraction Dependency

«All variable instantiation requires the implementation of a Creational pattern as the Factory Method or the Factory pattern, or the more complex[why?] use of a Dependency Injection framework.»

I don't see how why to explain in more details why a framework is more «commplex» (multiple parts, etc.) than a method or a Factory class. Maybe «elaborated» could be used. The term is not used as meaning «difficult», but involves more components and knowledge of the framework used.

Klodr (talk) 16:49, 26 March 2016 (UTC)

xkcd

This article is the perfect example of xkcds:

• 927
• 974
• 1671

Consider tossing away 2/3rds the prose and replacing with some examples and diagrams. — Preceding unsigned comment added by 24.113.161.104 (talk) 19:58, 30 June 2018 (UTC)

What does it mean a module is high level or is low level?

Golopotw (talk) 18:41, 27 May 2021 (UTC)