Liskov Substitution Principle

-o0O0o-

"Subclasses must be able to replace base classes without the client code noticing."

-o0O0o-

Original author: Barbara Liskov

PDF:

IntroIngSoft.Lesson7 Architecture-Design_2023

COSEIS:

Captura de Pantalla 2022-09-24 a las 13.38.54

Model Format MagicDraw

The Liskov substitution principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application.

Formally speaking, it is a particular definition of a subtyping relation, called strong behavioral subtyping, that was initially introduced by Barbara Liskov in a 1988 conference keynote address titled Data abstraction and hierarchy.

It is based on the concept of “substitutability” – a general principle in object-oriented programming stating that an object (such as a class) and a sub-object (such as a class that extends the first class) must be interchangeable without breaking the program. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.

Advantages

Ensures semantic interoperability of subtypes

Disadvantages

LSP Violation = Latent OCP Violation
LSP non-compliance leads to OCP non-compliance

Code Examples

// Example of violation of LSP

class Rectangle {
      public int setWidth(int a) {
         width = a;
      }
      public int setHeight(int a) {
         height = a;
      }
      public int area {
         return (width * height);
      }

}

class Square extends Rectangle {
      public int setWidth(int a) {
         width = height = a;
      }
      public int setHeight(int a) {
         width = height = a;
      }
   }

class RectangleTest {
/*
 * This test fails for objects of class Square because they do not
 * respect the semantics of the setWidth and setHeight operations 
 * in the superclass. 
 */
 @Test
 public void testArea(Rectangle r) {
		 r.setWidth(2);
		 r.setHeight(5);
		 assert(r.area() == 2*5);
   }
}

/*
 * “Fixing” the test method through violation of OCP:
 */

 @Test
 public void testArea(Rectangle r) {
      if (r instaceOf Rectangle) {
		 r.setWidth(2);
		 r.setHeight(5);
		 assert(r.area() == 2*5);
      }
   }

/*
 * As we have seen, the problem is not easy to solve, but most 
 * important, it is originated by a wrong understanding of the
 * generalization relation. No matter how similar two objects look
 * in the real world, the generalization is applied to their computer
 * representation (e.g. class). Consequently, it only makes sense to
 * use generalization when the subclass will correspond to the semantics
 * of the superclass. Otherwise, it is better to use two separate classes.
 * 
 * We could even force their relation in some cases by using a more 
 * complex class structure, but we must bear in mind that having those
 * classes related may not be worth the complexity.
 */

public abstract class Rectangle {
      public int area {
         return (width * height);
      }
}

class PureRectangle extends Rectangle {
      public int setWidth(int a) {
         width = a;
      }
      public int setHeight(int a) {
         height = a;
      }
}

class Square extends Rectangle {
      public int setSide(int a) {
         width = height = a;
      }
}

/*
 * Now, client classes of the Rectangle class can only expect the semantics
 * of the area operation of the subclasses of Rectangle to be consistent with
 * the Rectangle specification.
 *
 * On the other hand, clients of each subclass will not have any problem with
 * semantics of the other subclass. 
 */

// Example of violation of LSP

class Rectangle {

public int setWidth(int a) {

width = a;

}

public int setHeight(int a) {

height = a;

}

public int area {

return (width * height);

}

class Square extends Rectangle {

public int setWidth(int a) {

width = height = a;

}

public int setHeight(int a) {

width = height = a;

}

class RectangleTest {

* This test fails for objects of class Square because they do not

* respect the semantics of the setWidth and setHeight operations

* in the superclass.

@Test

public void testArea(Rectangle r) {

r.setWidth(2);

r.setHeight(5);

assert(r.area() == 2*5);

}

* “Fixing” the test method through violation of OCP:

@Test

public void testArea(Rectangle r) {

if (r instaceOf Rectangle) {

r.setWidth(2);

r.setHeight(5);

assert(r.area() == 2*5);

}

* As we have seen, the problem is not easy to solve, but most

* important, it is originated by a wrong understanding of the

* generalization relation. No matter how similar two objects look

* in the real world, the generalization is applied to their computer

* representation (e.g. class). Consequently, it only makes sense to

* use generalization when the subclass will correspond to the semantics

* of the superclass. Otherwise, it is better to use two separate classes.

* We could even force their relation in some cases by using a more

* complex class structure, but we must bear in mind that having those

* classes related may not be worth the complexity.

public abstract class Rectangle {

public int area {

return (width * height);

}

class PureRectangle extends Rectangle {

public int setWidth(int a) {

width = a;

}

public int setHeight(int a) {

height = a;

}

class Square extends Rectangle {

public int setSide(int a) {

width = height = a;

}

* Now, client classes of the Rectangle class can only expect the semantics

* of the area operation of the subclasses of Rectangle to be consistent with

* the Rectangle specification.

* On the other hand, clients of each subclass will not have any problem with

* semantics of the other subclass.