1 / 12

Liskov Substitution Principle in Object-Oriented Programming

Learn about the Liskov Substitution Principle (LSP) in object-oriented programming, which defines subtype substitutability. Understand its relationship with design by contract methodology and restrictions on inheritance.

dorisroyce
Download Presentation

Liskov Substitution Principle in Object-Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. COMPUTER 2430Object Oriented Programming andData Structures I

  2. Inheritance and Polymorphism Prog 6

  3. Liskov Substitution Principle (LSP) • In object-oriented programming, the Liskov substitution principle is a particular definition of subtype that was introduced by BarbaraLiskov in a 1987 conference keynote address entitled Data abstraction and hierarchy • Liskov's notion of "subtype" is based on the notion of substitutability

  4. Liskov Substitution Principle (LSP) • The Liskov substitution principle is closely related to the design by contract methodology, leading to some restrictions on how contracts can interact with inheritance: • Preconditions cannot be strengthened in a subclass. Require no more! • Postconditions cannot be weakened in a subclass. Promise no less! • A function using a class hierarchy violating the principle uses a reference to a base class, yet must have knowledge of the subclasses. Such a function violates the open/closedprinciple because it must be modified whenever a new derivative of the base class is created.

  5. Liskov Substitution Principle (LSP) Two paraphrases that capture the essence • A child can be used wherever a parent is expected • For every overridden method in a child class: Require no more Promise no less • It will be on Test 3 and the final

  6. public class Animal { private String _id; private int numLegs; private float weight; public void grow() . . . } public class Frog extends Animal { . . . @Override public void grow() // weight determines numLegs }

  7. public class AnimalList { private Animal[] list; private int count; public boolean add( Animal animal ) . . . } // Can FrogList be a sub-class of AnimalList? public class FrogList extends AnimalList { . . . // Can a fish be added to the list? @Override public boolean add( Animal animal ) }

  8. public class AnimalList { private Animal[] list; private int count; // Any animal can be added to the lis. public boolean add( Animal animal ) . . . } public class FrogList extends AnimalList { . . . // Require More! @Override public boolean add( Frog frog ) }

  9. public class AnimalList { private Animal[] list; private int count; // animal will be added to the list if not full public boolean add( Animal animal ) . . . } public class FrogList extends AnimalList { . . . // Promise Less! @Override public boolean add( Animal animal ) // do not add if not Frog }

  10. public class BagOfFruit { private Fruit items[]; public void add ( Fruit x ) ... } public class BagOfApple extends BagOfFruit { private Apple items[]; // How to override method add? } Is a BagOfApple a BagOfFruit? Should BagOfApple be a subclass of BagOfFruit? NO!

  11. Don't Overdo Inheritance • Is your inheritance good ? the notion of "is-a“ LSP • Circle can't inherit from Ellipse even though it "is-a” have to restrict overridden 2D "resize" • BagOfApples is not a BagOfFruit restrict overridden add or allow bananas in the apple bag

  12. Quiz 6

More Related