Talk:Dependency inversion principle
 | Computer science Unassessed | ||||||||||||||||
| |||||||||||||||||
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[1]. 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)
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)
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)