LabVIEW Craft
  • Blog
  • About
  • Contact
  • Tools
  • Resources

Liskov Substitution Principle

12/1/2015

4 Comments

 
Jon McBee
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.
Picture
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
4 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...)

Reply
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

Reply
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?

Reply
Philip link
8/19/2023 03:11:26 am

Great blog you havve here

Reply



Leave a Reply.

    RSS Feed

    Tags

    All
    Abstract Messaging
    Actor Framework
    Agile
    AI
    Asynchronous Programming
    Best Practices
    C#
    Complexity
    Continuations
    Control Values By Index
    Craftsmanship
    Dependency Inversion
    Dependency Viewer
    Futures/Promises
    Genetic Algorithm
    Liskov Substitution
    Malleable VIs
    Mediator Pattern
    .NET
    Object Oriented
    Object-Oriented
    Packed Project Library
    Parallelism
    Polymorphism
    Pub/Sub
    RawCap
    Root Loop
    Scrum
    Task Parallel Library
    TCP/IP
    TDD
    Test Engineering
    UML
    Unit Test
    VI Scripting
    VI Server
    WireShark

    Archives

    October 2019
    April 2019
    July 2018
    October 2017
    March 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    August 2015
    February 2015
    January 2015

    LabVIEW Blogs

    Eyes on VIs
    LabVIEW Hacker
    VI Shots
    LabVIEW Artisan
    Software Engineering for LabVIEW
    ​Wiresmith Techology
Picture
Powered by the Panda Ant

  • Blog
  • About
  • Contact
  • Tools
  • Resources