Liskov substitution principle VS Interface Segregation principle

Question

I have some troubles with understanding these two principles. This is a bit long-read-question, so be patient.

Lets assume that we have a class

abstract class Shape {
    abstract void onDraw();
}

and interface

interface SideCountable {
  int getSidesCount();
}

And then we create two children classes

class Quad extends Shape {

   @Override
   public void onDraw() {
   //some draw logic here
   }
}

class Triangle extends Shape {

   @Override
   public void onDraw() {
   //some draw logic here
   }
}

And now we will make Shape implements SideCountable

abstract class Shape implements SideCountable{
    abstract void onDraw();
}

and make changes in children classes

class Quad extends Shape {

   @Override
   public int getSidesCount() {
       return 4;
   }

   @Override
   public void onDraw() {
   //some draw logic here
   }
}

class Triangle extends Shape {

   public int getSidesCount() {
       return 3;
   }

   public void onDraw() {
   //some draw logic here
   }
}

And create test function for this structure (following LSP) :

public void printSidesCount(List<Shape> shapes) {
    for(int i=0; i < shapes.size(); i++) {
        System.out.println(shapes.get(i).getSidesCount());
    }
}

And here I want to stop because actually in the next step I was stucked. What if we'll create a third class Circle?

class Circle extends Shape {

   public int getSidesCount() {
       return ???;
   }

   @Override
   public void onDraw() {
   //some draw logic here
   }
}

Circle has no sides, so implementation of SideCountable for this children sounds ridiculous. Ok, we can move implementation to Quad and Triangle only, but in this case LSP will not working anymore. Can someone describe what the best way I should to do?

Leave SideCountable in Shape class and return 0 for Circle and break interface segregation principle?
Move SideCountable to Quad and Triangle and break LSP principle?

Just as a note, the Liskov Substitution principle really doesn't apply to this kind of setup - it's supposed to provide an abstraction for classes that all provide the same result with different implementations. A `Quad` and a `Triangle` will never provide the same side count. Different `Quad` implementations will, which is when Liskov Substitution is fulfilled. — daniu, Dec 17 '19 at 10:39
`Circle` could have a child `CircumscribedCircle` (https://en.wikipedia.org/wiki/Circumscribed_circle), which, for `getSidesCount`, could return its polygon sides. So it also depends on your domain, and how profound your hierarchy is. But a general piece of advice, as @Jesper put it, would be not putting too specific interfaces (`SideCountable`) on top of too abstract classes (`Shape`) unless your domain is well-defined and you perfectly know what children could be there. — Andrew Tobilko, Dec 17 '19 at 10:49

Jesper · Accepted Answer · 2019-12-17T10:36:13.840

First of all, your method printSidesCount only needs to know that the list contains SideCountable objects. So giving its parameter the type List<Shape> is more specific than necessary. Give it a List<SideCountable> instead:

public void printSidesCount(List<SideCountable> sideCountables) {
    for(int i=0; i < (); i++) {
        System.out.println(sideCountables.get(i).getSidesCount());
    }
}

Or even List<? extends SideCountable> which means "a list of some arbitrary unknown type that implements SideCountable":

public void printSidesCount(List<? extends SideCountable> sideCountables) {
    for(int i=0; i < sideCountables.size(); i++) {
        System.out.println(sideCountables.get(i).getSidesCount());
    }
}

If not all shapes have a countable number of sides, then class Shape should not implement interface SideCountable. Instead, make classes Quad and Triangle implement interface SideCountable besides extending class Shape:

class Quad extends Shape implements SideCountable {
    // ...
}

class Triangle extends Shape implements SideCountable {
    // ...
}

And make class Circle extend Shape but not implement SideCountable:

class Circle extends Shape { // Not SideCountable
    // ...
}

When you do it like this, the type system will help you:

you can pass a List<Quad> or List<Triangle> to printSidesCount since those types implement SideCountable
you cannot pass a List<Circle> to printSidesCount, which is good because trying to do this would not make sense for a list of circles

Liskov substitution principle VS Interface Segregation principle

1 Answers1