{"id":414,"date":"2026-07-02T12:51:58","date_gmt":"2026-07-02T12:51:58","guid":{"rendered":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/?p=414"},"modified":"2026-07-02T12:52:52","modified_gmt":"2026-07-02T12:52:52","slug":"liskov-substitution-principle","status":"publish","type":"post","link":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/2026\/07\/02\/liskov-substitution-principle\/","title":{"rendered":"Liskov Substitution Principle"},"content":{"rendered":"\n

A Subclass Must Be a Replaceable Substitute for Its Base Class<\/h4>\n\n\n\n

The Liskov Substitution Principle (LSP)<\/strong> states that objects of a derived class should be able to replace objects of the base class without affecting the correctness of the program.<\/p>\n\n\n\n

Simply put:<\/p>\n\n\n\n

If class B inherits from class A, then anywhere we use A, we should be able to use B and the program should continue to work correctly.<\/strong><\/p>\n\n\n\n

This principle is not only about method signatures but, more importantly, about behavior. A derived class must not change the expected semantics of methods inherited from the base class.<\/p>\n\n\n\n

Real-Life Example: How to Understand It?<\/h4>\n\n\n\n

Imagine a car rental company.<\/p>\n\n\n\n

A customer walks in and says:<\/p>\n\n\n\n

\n

“I’d like to rent a car.”<\/p>\n<\/blockquote>\n\n\n\n

The rental company hands over the keys and points to a vehicle in the parking lot.<\/p>\n\n\n\n

The customer assumes that the car will:<\/p>\n\n\n\n

    \n
  • start when the key is turned,<\/li>\n\n\n\n
  • stop when the brake pedal is pressed,<\/li>\n\n\n\n
  • move when the accelerator is pressed.<\/li>\n<\/ul>\n\n\n\n

    Now imagine the rental company gives the customer a vehicle with the engine removed.<\/p>\n\n\n\n

    It still looks like a car. It has a key, a steering wheel, and pedals. However, when the key is turned, nothing happens.<\/p>\n\n\n\n

    Is it still a “car” according to the agreement with the customer?<\/p>\n\n\n\n

    Technically, yes.<\/p>\n\n\n\n

    Practically, absolutely not.<\/p>\n\n\n\n

    The customer has every right to expect that every vehicle provided by the rental company behaves like a car. The rental company violated that expectation by supplying an object that looks like a car but does not behave like one.<\/p>\n\n\n\n

    Programming works exactly the same way.<\/p>\n\n\n\n

    If we have a Car<\/code> class with a start()<\/code> method and create a subclass CarWithoutEngine<\/code> that overrides the method and throws an exception, we violate LSP.<\/p>\n\n\n\n

    Any piece of code that expects a Car<\/code> receives an object that does not fulfill the contract.<\/p>\n\n\n\n

    A Thought Experiment<\/h5>\n\n\n\n

    Consider the classic programming example of a rectangle and a square.<\/p>\n\n\n\n

    At first glance, a square is a rectangle (every square is a rectangle).<\/p>\n\n\n\n

    But should a Square<\/code> class inherit from a Rectangle<\/code> class in code?<\/p>\n\n\n\n

    Let’s see where things break down.<\/p>\n\n\n\n

    Example \u2014 LSP Violation<\/h4>\n\n\n\n

    Suppose we are building a system for calculating the areas of geometric shapes.<\/p>\n\n\n\n

    We start with a rectangle:<\/p>\n\n\n

    <\/pre>\n
    \/\/ Base class: Rectangle with independent dimensions<\/div>\n
    class Rectangle {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 protected int width;<\/div>\n
    \u00a0\u00a0\u00a0 protected int height;<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 public void setWidth(int width) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.width = width;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 public void setHeight(int height) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.height = height;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 public int calculateArea() {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return width * height;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    Mathematically, a square is a special type of rectangle, so we inherit from it:<\/p>\n\n\n
    <\/pre>\n
    \/ Square inherits from Rectangle – seems logical at first<\/div>\n
    class Square extends Rectangle {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 \/\/ A square must have equal sides,<\/div>\n
    \u00a0\u00a0\u00a0 \/\/ so we override the setters<\/div>\n
    \u00a0\u00a0\u00a0 @Override<\/div>\n
    \u00a0\u00a0\u00a0 public void setWidth(int width) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Set BOTH dimensions to preserve square properties<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.width = width;<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.height = width; \/\/ \u2190 problem starts here<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 @Override<\/div>\n
    \u00a0\u00a0\u00a0 public void setHeight(int height) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Both dimensions must remain equal<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.width = height; \/\/ \u2190 silently changes another field<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.height = height;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    Now let’s write a method that operates on a Rectangle<\/code> and see what happens when we pass a Square<\/code>.<\/p>\n\n\n
    <\/pre>\n
    \/\/ According to LSP, a method expecting Rectangle<\/div>\n
    \/\/ should also work with Square<\/div>\n
    public static void testArea(Rectangle r) {<\/div>\n
    \u00a0\u00a0\u00a0 r.setWidth(5);<\/div>\n
    \u00a0\u00a0\u00a0 r.setHeight(3);<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 \/\/ Expected: 5 * 3 = 15<\/div>\n
    \u00a0\u00a0\u00a0 int expected = 15;<\/div>\n
    \u00a0\u00a0\u00a0 int actual = r.calculateArea();<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 System.out.println(“Expected: ” + expected);<\/div>\n
    \u00a0\u00a0\u00a0 System.out.println(“Actual: ” + actual);<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 \/\/ Rectangle: prints 15\u00a0<\/div>\n
    \u00a0\u00a0\u00a0 \/\/ Square:\u00a0\u00a0\u00a0 prints 9\u00a0\u00a0<\/div>\n
    }<\/div>\n\n\n
    Following:<\/p>\n\n\n
    <\/pre>\n
    public static void main(String[] args) {<\/div>\n
    \u00a0\u00a0\u00a0 testArea(new Rectangle()); \/\/ works correctly<\/div>\n
    \u00a0\u00a0\u00a0 testArea(new Square());\u00a0\u00a0\u00a0 \/\/ incorrect result, LSP violated<\/div>\n
    }<\/div>\n\n\n
    What’s Wrong with This Approach?<\/h5>\n\n\n\n
    The derived class changes the behavior of base-class methods.<\/p>\n\n\n\n
    In the Rectangle<\/code> class, setWidth()<\/code> changes only the width.<\/p>\n\n\n\n
    In the Square<\/code> class, the same method also changes the height, without the caller’s knowledge.<\/p>\n\n\n\n
    Code that trusted the contract of the base class no longer works correctly.<\/p>\n\n\n\n
    The testArea()<\/code> method does not know that it received a Square<\/code>, and it should not need to know.<\/p>\n\n\n\n
    That is the essence of an LSP violation.<\/p>\n\n\n\n
    The inheritance hierarchy reflects a mathematical relationship<\/strong>, not a programming relationship<\/strong>.<\/p>\n\n\n\n
    In geometry, a square is a rectangle.<\/p>\n\n\n\n
    In object-oriented programming, that is not necessarily true if their behavior differs.<\/p>\n\n\n\n
    Example \u2014 LSP-Compliant Design<\/h4>\n\n\n\n
    Instead of forcing a square into a rectangle hierarchy, we extract a shared abstraction representing what both shapes truly have in common: the ability to calculate an area.<\/p>\n\n\n
    <\/pre>\n
    \/ Common abstraction<\/div>\n
    abstract class Shape {<\/div>\n
    \u00a0\u00a0\u00a0 public abstract int calculateArea();<\/div>\n
    }<\/div>\n\n\n
    Then:<\/p>\n\n\n


    \/\/ Rectangle - independent dimensions

    class Rectangle extends Shape {




    \u00a0\u00a0\u00a0 private int width;

    \u00a0\u00a0\u00a0 private int height;




    \u00a0\u00a0\u00a0 public Rectangle(int width, int height) {

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.width = width;

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.height = height;

    \u00a0\u00a0\u00a0 }




    \u00a0\u00a0\u00a0 @Override

    \u00a0\u00a0\u00a0 public int calculateArea() {

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return width * height;

    \u00a0\u00a0\u00a0 }

    }<\/pre>\n\n\n
    Add a class type:<\/p>\n\n\n
    <\/pre>\n
    \/ Square – one side, its own logic<\/div>\n
    class Square extends Shape {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 private int side;<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 public Square(int side) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 this.side = side;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 @Override<\/div>\n
    \u00a0\u00a0\u00a0 public int calculateArea() {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return side * side;<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    Now a method operating on Shape<\/code> works correctly for both classes:<\/p>\n\n\n
    <\/pre>\n
    public static void printArea(Shape shape) {<\/div>\n
    \u00a0\u00a0\u00a0 System.out.println(“Shape area: ” + shape.calculateArea());<\/div>\n
    }<\/div>\n\n
    <\/pre>\n
    public static void main(String[] args) {<\/div>\n
    \u00a0\u00a0\u00a0 printArea(new Rectangle(5, 3)); \/\/ Shape area: 15\u00a0<\/div>\n
    \u00a0\u00a0\u00a0 printArea(new Square(4));\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Shape area: 16\u00a0<\/div>\n
    }<\/div>\n\n\n
    What Did We Gain?<\/h4>\n\n\n\n
    Each class is responsible for its own logic.<\/p>\n\n\n\n
    The Square<\/code> class no longer pretends to be a rectangle. It has its own consistent behavior.<\/p>\n\n\n\n
    The base-class contract is always honored.<\/p>\n\n\n\n
    calculateArea()<\/code> in every subclass does exactly what the caller expects: it returns the area of the shape.<\/p>\n\n\n\n
    We can safely substitute subclasses.<\/p>\n\n\n\n
    Any code that accepts a Shape<\/code> will work correctly whether it receives a Rectangle<\/code>, a Square<\/code>, or any other future shape.<\/p>\n\n\n\n
    Why Is LSP Important?<\/h4>\n\n\n\n
    Inheritance Is a Promise<\/h5>\n\n\n\n
    When we write:<\/p>\n\n\n
    class B extends A<\/pre>\n\n\n
    we are making a promise:<\/p>\n\n\n\n
    \n
    “B behaves like A wherever A is expected.”<\/p>\n<\/blockquote>\n\n\n\n
    Violating LSP breaks that promise and introduces bugs that are often difficult to debug because the code still compiles successfully.<\/p>\n\n\n\n
    Predictable Behavior<\/h5>\n\n\n\n
    When LSP is respected, we can trust that subclasses will not introduce surprises.<\/p>\n\n\n\n
    A method that works for the base class will also work for every subclass without requiring special handling.<\/p>\n\n\n\n
    Eliminating instanceof<\/code> Checks<\/h5>\n\n\n\n
    The need to write code such as:<\/p>\n\n\n
    if (object instanceof Square)

    <\/pre>\n\n\n
    is often a sign of an LSP violation.<\/p>\n\n\n\n
    The code must distinguish between types because subclasses are not truly substitutable for their base class.<\/p>\n\n\n\n
    Better Team Collaboration<\/h5>\n\n\n\n
    In large projects, LSP violations often surface months later.<\/p>\n\n\n\n
    Someone adds a new subclass and suddenly part of the system behaves differently.<\/p>\n\n\n\n
    Respecting LSP gives the team confidence that extending class hierarchies is safe.<\/p>\n\n\n\n
    Consequences in Large Systems<\/h5>\n\n\n\n
    Imagine a payment system with a base class Payment<\/code> and dozens of subclasses representing different payment methods.<\/p>\n\n\n\n
    If one subclass throws:<\/p>\n\n\n
    UnsupportedOperationException<\/pre>\n\n\n
    for a method such as:<\/p>\n\n\n
    refund()<\/pre>\n\n\n
    the refund mechanism breaks for that payment type.<\/p>\n\n\n\n
    Customers do not receive their money back, and the bug may only be discovered in production.<\/p>\n\n\n\n
    When Should You Apply LSP?<\/h4>\n\n\n\n
    Whenever You Use Inheritance<\/h5>\n\n\n\n
    Before creating a subclass, ask yourself:<\/p>\n\n\n\n
    \n
    Can this subclass replace the base class in every scenario?<\/p>\n<\/blockquote>\n\n\n\n
    If the answer is:<\/p>\n\n\n\n
    \n
    “Not always”<\/p>\n<\/blockquote>\n\n\n\n
    then the inheritance hierarchy is likely incorrect.<\/p>\n\n\n\n
    When instanceof<\/code> Appears in the Code<\/h5>\n\n\n\n
    Type checking is often a sign that subclasses are not true substitutes for the base class.<\/p>\n\n\n
    <\/pre>\n
    public void processShape(Shape shape) {<\/div>\n
    \u00a0<\/pre>\n
    \u00a0\u00a0\u00a0 if (shape instanceof Square) {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ special handling<\/div>\n
    \u00a0\u00a0\u00a0 } else {<\/div>\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ standard handling<\/div>\n
    \u00a0\u00a0\u00a0 }<\/div>\n
    }<\/div>\n\n\n
    In E-Commerce Systems<\/h5>\n\n\n\n
    Consider an Order<\/code> class and an ExportOrder<\/code> subclass.<\/p>\n\n\n\n
    If ExportOrder<\/code> does not support calculateDiscount()<\/code> in the same way as a normal order, it violates LSP and can cause failures in the discount system.<\/p>\n\n\n\n
    In Spring Framework<\/h5>\n\n\n\n
    Spring heavily relies on LSP.<\/p>\n\n\n\n
    Any Bean can be replaced by a mock implementation during testing.<\/p>\n\n\n\n
    That is one of the reasons dependency injection through interfaces is so powerful: every implementation acts as a valid substitute.<\/p>\n\n\n\n
    \n\n\n\n
    \n
    “If it looks like a duck and quacks like a duck\u2014but requires batteries to quack\u2014you have a bad inheritance model.”<\/p>\n<\/blockquote>\n\n\n\n
    A subclass must not only look like the base class\u2014it must also behave like it.<\/p>\n\n\n\n
    No surprises.<\/p>\n\n\n\n
    No exceptions.<\/p>\n\n\n\n
    No silent behavioral changes.<\/p>\n\n\n\n
    Inheritance is not just about sharing code\u2014it is a commitment to honoring a contract.<\/p>\n\n\n\n
    A derived class may extend the behavior of a base class, but it should never break that behavior.<\/p>\n","protected":false},"excerpt":{"rendered":"
    A Subclass Must Be a Replaceable Substitute for Its Base Class The Liskov Substitution Principle (LSP) states that objects of a derived class should be able to replace objects of the base class without affecting the correctness of the program. Simply put: If class B inherits from class A, then anywhere we use A, we […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"saved_in_kubio":false,"footnotes":""},"categories":[12],"tags":[],"class_list":["post-414","post","type-post","status-publish","format-standard","hentry","category-solid"],"_links":{"self":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/414","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/comments?post=414"}],"version-history":[{"count":2,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/414\/revisions"}],"predecessor-version":[{"id":416,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/414\/revisions\/416"}],"wp:attachment":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/media?parent=414"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/categories?post=414"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/tags?post=414"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}