Do You Write SOLID Code – Day 3
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 continue this discussion on the second principle…the Liskov Substitution Principle.
The Liskov Substitution principle was defined by Barbara Liskov in a “1987 conference keynote address entitled Data abstraction and hierarchy” (quote take from Viki).
The principle simply stated is this:
If object Y inherits from object X, and you have an instance j of type Y, j can be substituted for objects written to use X.
In short, a subtype can be substituted with an instance of its ancestor.
Viki provides a good example regarding this dilemma. A square and a rectangle both have four sides. However, by rule, all the sides of a square must be equal. In contrast, only parallel sides of a rectangle may be equal. If they are the same size then it is not a rectangle, but a square. Therefore, these two objects may not become a subtype of the other…because their behaviors are in direct contradiction.
This doesn’t mean that you couldn’t define instead a Class of Rectangle, and allow it to have equal sides. But that class would stand alone, and not have any relationship to another class of type Square. You simply wouldn’t have a separate class enforcing the rules of a square or a rectangle; instead you would have a class that could implement either design.
Why would you want to program in this fashion? That’s kind of the point of inheritance then isn’t it…to create additional functionality but not have to repeat everything from the parent type?
The reason is that when you start to consume your objects in your programs, it becomes important for the behavior of a type to be consistent. When you come out with version 2 of your system, following the open/closed principle discussed yesterday, you will want to extend the version 1 object. However, if it is your intention for software that previously consumed objects written in version 1 to also be able to work exactly the same with the new version 2, the version 2 must behave exactly the same as version 1. Otherwise you will have to change all consumers of that class as well.
So, if your new class has all the same external interfaces and behaviors of it’s parent, it is easily substituted in your system without fear of breaking old code. You may add additional public behaviors to that class. But those new behaviors or interfaces will only be utilized by new code. And all the behaviors of the prior version work exactly the same in the new class.
Using this principle is a great way to add new functionality to an existing program allowing both versions to live side by side. This is especially useful for large projects where changes are performed incrementally.
So, are you getting SOLID or is this too theoretical for you? Drop me a note and share your thoughts. We have two more principles to go on this series…but your input will help me with future topics. Send your input to btaylor@sswug.org.
Check out SSWUG on Facebook
Check out www.facebook.com/sswug. When you drop into our page you can ask questions, and find cool stuff. Your questions are answered on facebook, used for SelecTViews, or even introduced as presentations for a later time. Go check it out…and while you’re there, check out the great pictures of the SSWUGies!
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Database Archiving and Auditing Can Minimize the Potential of a Data Breach (Part 2)
The bottom line is that you can combat the risk of data breaches by developing a comprehensive database archiving plan to protect your valuable data assets.
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)