Do You Write SOLID Code – Day 5
We have been discussing the different components of the SOLID acronym from Robert Martin, defining five basic principles of object oriented programming. As stated previously, these principles apply to any object oriented language, and even to some that are hybrid or non-object oriented languages.
The five principles of SOLID are:
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
The goal for applying these principles to your software development practices is that you will write software that is stable, robust, and extensible over time. Today we conclude this discussion with the fifth principle…the Dependency Inversion Principle.
Dependency inversion is a specific form of lose coupled software. In lose coupled software, a consumer of an object declares an object type using an Interface or an Abstract class. When this object is instantiated, it is instantiated with a concrete implementation of a class, that also inherits from the same abstract class or interface.
For example, consider a printer driver. If my software defines a variable from a printer interface, it can be instantiated from any printer driver implementing that interface. In contrast, if my software instantiates a specific printer driver, whenever that driver is modified, my software is directly impacted. This close coupling is a dependency that has a higher cost to maintain over time than taking the time to create an abstract dependency in the first place.
Lose coupling is common in Object Oriented software. Dependency Inversion is a specific type of lose coupling distinguished by the package in which the interface is defined. In the case of Dependency Inversion there are at least two packages, a Higher Level package and a Lower Level package. The higher level package contains the abstract definition in the form of an abstract class or interface. The lower level package(s) contain concrete implementations of the abstract definition.
Wiki summarizes,
“A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.”
An operating system is a great example of Dependency Inversion. An operating system defines the interface, using our example above, for how to communicate with a printer. The operating system is the High Level package. The interface is published and available for inheritance by low level printer drivers.
In this case, each hardware manufacturer simply inherits from the interface specified by the operating system manufacturer, and implements the requirements specific to their hardware.
Using this technique, the operating system can be extended to work with other new printers, not yet in existence, without requiring any modification to the Operating System Code. A good interface will also expose definitions regarding how to instantiate a specific implementation. So, not only must a printer driver provide the communication link to be printed, it must also provide a mechanism to be instantiated without prior knowledge of it’s existence by the operating system.
Many detail patterns implement the Dependency Inversion principle which you will find in the links above.
Did you find this series helpful? Please let me know with a yes or no…drop a line on facebook, twitter or Email at btaylor@sswug.org. Your quick response provides me insight into future topics we may consider.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
SQL Performance: How Do I Tackle You?
It’s important to know about the different data collection techniques available within SQL Server for performance-related scenarios.
Featured White Paper(s)
Upgrading to Microsoft SQL Server 2008 R2 from Microsoft SQL Server 2008, SQL Server 2005, and SQL Server 2000
More than ever, organizations rely on data storage and analysis for business operations. Companies need the ability to deploy… (read more)
Featured Script
sp_random
Random number generator code snippet…. (read more)