Liskov Substitution Principle﻿

Liskov Substitution Principle

12/1/2015

The Liskov Substitution Principle (LSP) is one of the five SOLID principles of object oriented design. At first glance the LSP seems rather complex but I hope that my presentation below will help clarify what it means and how it can effect the flexibility of your software.

This presentation assumes you have seen my presentation on the Dependency Inversion Principle, if not check it out here.

Don't forget to check out Caraya from JKI here.

liskov_substitution_principle.pptx
File Size:	952 kb
File Type:	pptx

Download File

Jon McBee is a Principal Software Engineer at Cambridge NanoTech and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, and a LabVIEW Champion

3 Comments

Russell Blake link

12/1/2015 07:48:08 am

Hello Jon,

Another great presentation. I thought the choice of explaining the concept by using the power supply as an example of something that does not meet the criteria for the principle was a very good way to explain the topic. I also liked how you included unit testing. Unit testing would catch a rule violation after the implementation is complete. I was thinking documentation is really important as well to avoid a developer spending time coding something that would break a rule, like passing an error out. What are your thoughts on best practices for documentation of rules? (VI comment, VI description, a separate design document, etc...)

Jon McBee

12/1/2015 11:52:04 am

Hi Russell,

I'd say a great candidate for this kind of documentation is in the VI Description as it persists from parent dynamic dispatch VI to child override VI. At some level the existence of the unit test is documenting the rule, and the fact that the unit test exists implies that a requirement or user story should exist as well. However even if a requirements document/user story/or other design document exists, the odds are that a future developer will go straight to the code, and so the best place to document this type of rule (in my opinion) would be by stating its existence in the VI Description and also putting a note about the unit test created to account for the rule in the VI Description.

I would be very interested in hearing other people's thoughts on this as well.

-Jon

Ryan Vallieres

12/4/2015 04:29:15 pm

Hey Jon;

Nice presentation on the LSP. It's really interesting to consider how closely the DIP and the LSP are tied together. It seems pretty difficult to violate one or the other independently.

Never thought about power supplies as an LSP violation, which they clearly are. However, that brings up an interesting discussion on interface design. In the world of power supplies, we really like common interfaces. If you look at cell phones, it's common practice to use microUSB as an interface for many different models of phones and power supplies for the phones. This is done without regard for the actual type of supply being used to charge the phone. We do this because people find it useful. Lets you use a friend's charger for your phone and typically be fine.

This works because the phones have either have a wide tolerance for being charged by different sources, or the chargers being built for phones are typically in some reasonable range. In an ideal world for LSP, power supplies with different specifications have different interfaces. This kinda sucks in practice, cause no phone works without the exact same power supply made for it exactly (never mind being real close to violating the DIP). The opposite case of a single interface for all power supplies is equally crazy. There really shouldn't be a case where you can plug a 1200W power supply into a phone to charge it.

I believe this puts us in an interesting system design situation. The unit testing is a good way to detect if a component will violate a rule for the target system, but still fit into a defined interface. But that's somewhat of a reactionary response where a preemptive one may have been more useful. Considering this, do you have any thoughts on interface design?