Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Real-World Software Development: The Liskov Substitution Principle

 
Sheriff
Posts: 7108
184
Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was a professional programmer in the 80s working with a flavor of BASIC.  In my twenty years in the business, we didn't do a lot of object oriented programming; the language wasn't setup for it.  Then I started working for a company that taught Java and then hired you.  We did OOP and testing, but not a lot of other design principles.

I'm retired now, but I'm still an amateur programmer trying to fill in the holes in my knowledge.  I noticed that you go over SOLID programming in your book.  I know the Single Responsibility Principle, and I think I know the Open/Closed Principle, the I've only heard of the Liskov Substitution Principle; I know nothing about it.

What's a brief definition of LSP?  I'm looking forward to learning the other design principles in SOLID.
 
Sheriff
Posts: 15815
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hope you and the authors don't mind if I give you a brief answer.

The LSP is named after its co-developer/creator, Barbara Liskov, a computer scientist who won the 2008 Turing Award. Basically, it's about "programming to abstractions, not concretions." It's the principle behind this kind of code:

The Foo type can be a superclass or an interface and myFoos should be able to contain subclasses or implementations of Foo without breaking the code in the for-loop. The first line where you declare myFoos also adheres to LSP because you can switch to (i.e., substitute) a different List implementation on the right hand side and still expect the for-loop code to work correctly.
 
Knute Snortum
Sheriff
Posts: 7108
184
Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, thank you.  I did know that principle but I didn't know that name for it.
 
Author
Posts: 31
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Knute

Knute Snortum wrote:I was a professional programmer in the 80s working with a flavor of BASIC.  In my twenty years in the business, we didn't do a lot of object oriented programming; the language wasn't setup for it.  Then I started working for a company that taught Java and then hired you.  We did OOP and testing, but not a lot of other design principles.

I'm retired now, but I'm still an amateur programmer trying to fill in the holes in my knowledge.  I noticed that you go over SOLID programming in your book.  I know the Single Responsibility Principle, and I think I know the Open/Closed Principle, the I've only heard of the Liskov Substitution Principle; I know nothing about it.

What's a brief definition of LSP?  I'm looking forward to learning the other design principles in SOLID.



Thanks for your question. As you mention there's an extensive section on LSP in the book that goes through a more extensive example that I won't replicate here. Instead I'll just explain the fundamental problem that it's solving. If you've got a parent class called Document and a series of different document types that extend the Document class - say Invoice, Receipt, PatientRecord, etc. how do you know that those subclasses are good substitutes for the parent class. That is to say if you use "Document" elsewhere in your code - what are the rules that it's subclasses need to abide by in their implementation in order for different implementations to be plugged in. These 4 rules form the LSP and act as a really good rule as to what to do and what not to do when extending classes.

regards,

 Richard
 
It's a beautiful day in this neighborhood - Fred Rogers. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic