SOLID – Liskov Substitution Principle
Today we provide an overview of the third principle in the SOLID acronym. Liskov postures that your specific class implementations should utilize an abstract implementation of external objects. In so doing, you can change the functionality of that class by substituting a different implementation of the abstract external object with another, and the containing class need not be modified in any way.
In essence, this is one technique for fulfilling the Open/Closed principle discussed yesterday. In Jeremy Miller’s example, http://msdn.microsoft.com/en-us/magazine/cc546578.aspx#id0390079, he demonstrates an object called BusinessProcess. BusinessProcess requires interaction with a data source. Rather than instantiating a specific data source the BusinessProcess class utilizes an IDataSource interface. By using an interface the BusinessProcess object works with any implementation of the IDataSource interface.
The IDataSource interface can be implemented by an XML data store. Later it may be implemented with a relational database data store without modifying the BusinessProcess class in any manner.
In this fashion, Single Responsibility, Open/Closed and Liskov Substitution work together resulting in code that may be easily extended with the least impact to existing code. Utilizing other software development patterns, new implementations of IDataSource may be created, instantiated, and inserted into the program for execution by adding only new code, and modifying configuration data for implementation.
This provides you, the developer, with huge confidence in making drastic changes to software, adding new functionalities, without risk of breaking existing code. It reduces the load on testing resources because existing code continues to work in exactly the same way as previously coded.
Many of you are database professionals. How does this apply to you? Most specifically in the data access layers of your code. As a persistence professional learning the SOLID principles and developing an understanding around them provides you with the necessary skills to understand and implement ORM frameworks such as nHibernate or Entity Framework, along with dozens of other tools. If you write your own, you will be better positioned to write your own extensible code.
Although the concepts may not be directly applied to SQL objects since there is no object oriented concept as abstract, you can still take advantage of separation of concerns through calling stored procedures functions or views. Open/Closed is a little harder to maintain. But, if you restrict your objects to single responsibilities you can create new code re-using existing objects providing new functionality. It isn’t quite as elegant as object oriented programming…but it still provides many of the same benefits with a little more work.
Using this technique in your SQL code you can more easily release new changes to your software without disabling older implementations allowing both versions to co-exist until the old version is completely deprecated.
I hope you are enjoying this journey through the SOLID principles. Feel free to send your comments about this or other topics to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Creating and Managing User-Defined Roles in SQL Server 2012
This article shows how to create and manage user-defined server role that is a nice addition to SQL Server 2012.
Featured White Paper(s)
Key Management in the Multi-Platform Environment
Written by Townsend Security
This White Paper discusses the challenges … (read more)
Featured Script
dba3_Grouping_Data_Occurrences_demo
Demo of incidence grouping counts of number occurances… (read more)