Klodr

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.

The class diagrams are totally incorrect and confusing

The class diagrams are totally incorrect and confusing!!!

Policy layer does not depend on Policy Service interface that is implemented by Mechanism Layer as it's showed at "Ownership Inversion" section. The correct diagram is at the link below: http://1.bp.blogspot.com/-u0hl5IiR8k0/Tjl6papJcpI/AAAAAAAAbD8/0pJ9K4FA7LQ/s1600/layers.png Policy layer depends on Mechanism Service interface that is implemented by Mechanism Layer and so on... I wonder how this confusing class diagrams are still in Wikipedia confusing millions of people))) — Preceding unsigned comment added by 65.170.159.12 (talk) 19:14, 30 September 2015 (UTC)

You are correct about the names in the diagrams. But the main thing is not the naming convention about the abstract/interfaces layers, but the mechanisms of communication between them and concrete instances. The change of names clearly express the intention of the abstracts types in the example. You could name as you want, that doesn't change the relation.

Klodr (talk) 01:28, 20 December 2015 (UTC)