Robert Martin introduced the Dependency Inversion Principle as one of ten best practice object-oriented design principles in his seminal article, “Design Principles and Design Patterns.” In the article, Martin categorizes the Dependency Inversion Principle, along with the Open/Closed Principle, the Liskov Substitution Principle, and the Interface Segregation Principle, as a standard for well designed object-oriented classes. Besides these class based design principles, he also lists architecture of package design as a parameter to good design practices, which I won’t focus on here.
The Dependency Inversion Principle supports one of the main tenets of object-oriented design, abstraction. This principle inverts the logical dependency structure of an object-oriented program; concrete classes depend on abstract classes rather than abstract classes end depending on concrete, instantiated classes. Rather than high level modules specifically dependent on the implementation found in lower level modules, they rely on an abstract interface.
The Dependency Inversion Principle allows for flexible, robust designs. If the concrete classes only depend upon an abstract interface, then by swapping out different instantiated class objects, the concrete class can do act differently. Also relying on a minimal set of public methods provided by the abstract class, the fan-in and fan-out metrics will be minimized, and fat interfaces will not be too much of a problem. Relying on abstract classes also contributes to a more cohesive design, because many classes would be of the same type that they form a tighter logically cohesive package. Finally, relying on abstract classes produces a less coupled system. The number of dependencies is lower if concrete classes rely on only a few abstract classes. The concrete classes don’t have to physically include several instances of derived concrete classes, but just one dependency to an abstract classes.
Finally, the Dependency Inversion Principle is realized in the idea of component design. It is reflected in the motifs found in CORBA (Common Object Request Broker Architecture) and COM (Common Object Model). These specifications provide an interface to allow different objects or entities to communicate amongst themselves. They provide an interface, an abstract interface, for the programmer to write her program.
The Dependency Inversion Principle supports one of the main tenets of object-oriented design, abstraction. This principle inverts the logical dependency structure of an object-oriented program; concrete classes depend on abstract classes rather than abstract classes end depending on concrete, instantiated classes. Rather than high level modules specifically dependent on the implementation found in lower level modules, they rely on an abstract interface.
The Dependency Inversion Principle allows for flexible, robust designs. If the concrete classes only depend upon an abstract interface, then by swapping out different instantiated class objects, the concrete class can do act differently. Also relying on a minimal set of public methods provided by the abstract class, the fan-in and fan-out metrics will be minimized, and fat interfaces will not be too much of a problem. Relying on abstract classes also contributes to a more cohesive design, because many classes would be of the same type that they form a tighter logically cohesive package. Finally, relying on abstract classes produces a less coupled system. The number of dependencies is lower if concrete classes rely on only a few abstract classes. The concrete classes don’t have to physically include several instances of derived concrete classes, but just one dependency to an abstract classes.
Finally, the Dependency Inversion Principle is realized in the idea of component design. It is reflected in the motifs found in CORBA (Common Object Request Broker Architecture) and COM (Common Object Model). These specifications provide an interface to allow different objects or entities to communicate amongst themselves. They provide an interface, an abstract interface, for the programmer to write her program.