What would be an example of the Liskov Substitution Principle, if you don't use inheritance?

Question

I am reading about the SOLID principles, but it seems like the Liskov-Substitution Principle primarily refers to programs that use inheritance.

From my understanding people are shifting more towards composition over inheritance. If that is the case, does the "L" in SOLID still apply? If so what would be an example of its use if one almost never relies on inheritance?

Answer 1

It's not about inheritance, it's about substitutability of types. In languages that support duck typing (JavaScript, Python, compile-time polymorphism of C++ templates, etc...), or structural typing (TypeScript, Go, etc...), the two types don't have to form an inheritance relationship at all. E.g., this JavaScript code will work just fine, even if there's no inheritance in sight:

var cat = {
  getSpecies: () => 'Cat',
  vocalize: () => 'Meow!'
}

var dog = {
  getSpecies: () => 'Dog',
  vocalize: () => 'Woof!'
}

var growls = ['Growl!', 'Grrr!', 'Rumble-rumble...', '(Blank stare)'];
var growlIndex = 0;

var growler = {
  getSpecies: () => 'Growler',
  vocalize: () => {
    var index = growlIndex;
    growlIndex++; if (growlIndex === growls.length) growlIndex = 0;
    return growls[index];
  }
}

// There's, effectively, an implicit abstract type Animal
function GreetAnimal(animal) {
  console.log('Human: Hi, there!');
  console.log(`${animal.getSpecies()}: ${animal.vocalize()}`);
}

GreetAnimal(cat);
GreetAnimal(dog);
GreetAnimal(growler);

Often, when using composition, you'll allow for the ability to plug in different implementations of something into the composite; in class-based statically typed languages, the composite would have a reference to a subobject of an abstract type/interface, so you'll have inheritance in there. And in duck-typed languages, you have an implicit type, even if there's no inheritance.

Also, it doesn't even have to be about objects; it can apply to functions too.

For example, suppose you have a tree structure with a method that visits every node in the tree, and allows you to pass in a function (or a lambda) of the form void MyFunc(Node n) (or (node) => { ... }) that allows you to access each node; the documentation says that this function must not modify the tree structure (but may modify the contents of the node itself), as the code in the Tree class relies on the tree itself not being modified.

The signature of the function is a kind of an abstract type, and the requirement in the documentation is a specification of the abstract behavior required of that type, and all its implementers. A concrete function that you pass in is a concrete implementation of this type. If you pass in a function that modifies the tree structure, you've just violated LSP.

Now, in this case, it would have been better if the design was such that you cannot easily break LSP in this way - e.g. instead of passing the node itself (thus allowing the caller to modify the child pointers), only pass the contents. But this is not always possible, and sometimes, the requirements on the behavior of the type are not easily designed away.

Suppose you need to write some kind of algorithm that processes a bunch of objects, and that requires the user to provide a way to decide the ordering of these objects. You can use the standard int compare(a, b) approach, where the negative value indicates that a comes before b, a zero indicates they are the same in terms of ordering, and a positive value indicates that b should come before a. You also require that the ordering functions makes sense as an ordering function: if a < b and b < c, then the function should also say that a < c (the ordering "transfers" as you'd expect; it doesn't suddenly say that a == c, there's no rock-paper-scissors kind of thing where c < a, etc.).

So if you supply a comparison function that, say, behaves like this:

compare(a, b);    // returns -1 (a is before b)
compare(b, a);    // returns -1 (b is before a)

you break Liskov with respect to your algorithm. You can't easily design that away - it's the responsibility of the users of your library to provide a sensible implementation of the int compare(a, b) type, or take on the risk of not doing so (the risk being, your function could crash, produce nonsensical result, or it might work, but then when you publish a new version where you change the internals, their code will break even though it's a non-breaking change, and it's on them, because they didn't adhere to the contract).

In some other context (e.g. when implementing rock-paper-scissors), the behavior expected from int compare(a, b) might be specified differently (the type, in the LSP sense, is not entirely defined by just the signature (or by an interface)). So, the same implementation may break LSP in one context, and be valid in another.

I guess another way to look at it is that what's a compiler considers to be a type, is not quite the same as what you, the developer (either as an author or as a user of some piece of code) consider to be a type; typically, types, in the sense relevant to us developers, cannot be entirely expressed in the language itself - and we know this intuitively; everyone knows that if a code compiles, it doesn't necessarily mean that it works as intended. In a sense, LSP (that is, Liskov & Wing 1994 paper) captures that in a more precise way.

Answer 2

I am reading about the SOLID principles, but it seems like the Liskov-Substitution Principle primarily refers to programs that use inheritance.

The Liskov Substitution Principle has nothing to do with Inheritance. The LSP is about Subtyping.

From my understanding people are shifting more towards composition over inheritance. If that is the case, does the "L" in SOLID still apply?

Since the LSP has nothing to do with inheritance, whether or not you use inheritance is irrelevant to whether or not the LSP applies.

If so what would be an example of its use if one almost never relies on inheritance?

Here are two simple examples from Ruby:

• Class inherits from Module, but is not a subtype. (You can multiply-inherit from modules, but you can only inherit from one class; ergo, you cannot substitute a class for a module without breaking your code.)
• StringIO has no inheritance relationship with IO, i.e. neither one does inherit from the other, nor do they both inherit from a common ancestor (except of course they both inherit from Object). Yet, depending on how you look at it, you can either say that StringIO is a subtype of IO, or (and that is my preferred interpretation) you can say that both IO and StringIO are sibling subtypes of an unnamed IOLike protocol.

Maybe a code example will help:

class Foo
  def initialize
    @backing_store = []
  end

  def <<(element)
    @backing_store << element
    self
  end

  def to_s
    -@backing_store.join(', ')
  end
end

class Bar
  def initialize
    @backing_store = +''
    @first_element = true
  end

  def <<(element)
    if @first_element
      @backing_store << element
      @first_element = false
    else
      @backing_store << ', ' << element
    end

    self
  end

  def to_s
    -@backing_store
  end
end

Both of these classes are subtypes of the unnamed Appendable protocol. In addition, Bar is a subtype of Foo[String] but not of Foo[T] in general. Conversely, Foo[String] (but not Foo[T] in general) is also a subtype of Bar. In other words, Foo[String] and Bar are the same type.

Answer 3

As long as the classes conform to a common interface where they can be substituted in a process that expects such a common interface, it doesn't matter whether you use inheritance or not. This can be done in languages that support interfaces like Java or duck-typing like others.

import java.util.List;
import java.util.ArrayList;

public class Test{
    public static void main(String args[]){
        List<A> list = new ArrayList<A>();
        list.add(new B());
        list.add(new C());
        
        for (A item: list){
            item.doThis();
        }
    }
}

interface A {
    void doThis();
}

class B implements A {
    
    public void myOwnStuff(){
        
    }
    
    public void doThis(){
        System.out.println("B");
    }
}

class C implements A {
    
    public void whatEver(){
        
    }
    
    public void doThis(){
        System.out.println("C");
    }
}

OUTPUT:
B
C

Note: inside the for loop you cannot access methods that are not part of the A interface.

Answer 4

Remember that Liskov wrote:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

As others have pointed out, there is no notion of inheritance here. And although in OOP languages inheritance does create a subtyping hierarchy, it is certainly not the only subtyping feature.

For example, in languages like Java, thanks to numeric promotion, wherever you expect a long you could pass a byte or an int, and wherever you expect a double you could pass a float or even an int. And thanks to boxing and unboxing wherever int is expected you could pass a java.lang.Integer and vice-versa.

None of these forms of ad-hoc polymorphism use inheritance in any way.

It is implied in the Liskov substitution principle that types form is-a relationships and when this precondition is broken then we could say the substitution is not satisfied.

However, a language type system could allow us to define type relationships that are sound from the type system point of view, but not from Liskov’s principle perspective. For example, mathematically speaking, it seems like every integer is also a real number, but is it true that every Java int is a float? It is not. Still, even though when loss of precision may occur when automatically promoting an int to a float, a widening primitive conversion never results in a run-time exception in Java. Thus, even when its type system allows it, these widening conversions break the Liskov substitution principle.

int big = 1234567890;
float approx = big;
System.out.println(big - (int)approx); //-46

To continue with other examples of subtypes that do not use inheritance, you can consider Java generics and how it creates subtyping rules a la carte using covariance and contravariance. For example a List<Number> is not a supertype of List<Integer>, hence where List<Number> appears I cannot pass a List<Integer>; however a List<? extends Number> is a supertype of List<Integer>. These are type relationships expressed in a way that makes the type system more malleable.

To rescue a comment I left in another answer, you could also consider Google Go (which is not an OOP language) where there is no such thing as an inheritance. Yet it has interface definitions that behave like statically-typed duck typing, allowing the language to define subtype relationships.

interface Stringer {
  String() string
}

In Go any type that has a String a method is considered a subtype of the Stringer interface without the need of statically expressing an explicit relationship with the interface.

You may want to consider other languages that have no notion of inheritance, not even interfaces, like some functional programming languages with structural type systems, like SML and Haskell, where type hierarchies are built using algebraic data types.

For example, in SML, a hierarchy of mathematical expressions could be defined as:

datatype expression = Number of int 
                    | Neg of expression
                    | Add of (expression * expression)
                    | Sub of (expression * expression)
                    | Mult of (expression * expression)
                    | Div of (expression * expression)

Where Number(5) is an expression just as Add(Number(1), Number(2)) is. Structurally, the variants create different kinds of expressions, all considered of the same type.

If you try to define that in Java today, you would probably resort to sealed interfaces and record classes.

sealed interface Expression
        permits Number, Neg, Exp, Add, Mult, Div {}

record Number(int c) implements Expression{}
record Neg(Expression expression) implements Expression{}
record Exp(Expression expression,int exponent) implements Expression{}
record Add(Expression left, Expression right) implements Expression{}
record Mult(Expression left, Expression right) implements Expression{}
record Div(Expression left, Expression right) implements Expression{}

So, you can probably see the usefulness of algebraic data types as an alternative to even interface inheritance to express type relationships.

In a way, the algebraic type definition from SML and the sealed interface/record type relationships in Java using interface inheritance, both represent a way to define subtype hierarchies of the kind that could be used to represent the Liskov principle. How these relationships are expressed is just a matter of syntax. So, perhaps the Liskov substitution principle is called that way for a reason: a principle is something beyond syntax.

Developers only familiar with OOP type systems might use some terms as euphemisms of others when in a broader perspective of programming languages they are not. Subtyping allows the Liskov substitution principle and in most OOP languages I know this takes the form of interface types, as a subtyping mechanism. From my point of view, interfaces, tacit or implicit, are not a form of inheritance. But if we take interfaces out of the equation, then what is left to define type relationships of the Liskov type? Only ad-hoc polymorphism, as I have already exemplified above.

Answer 5

Would be the same with interfaces / protocols. Technically they just specify that a class has certain methods either certain parameters and a certain return value. The LSP and common sense will tell you that this is pretty useless if two objects supporting the same interface or protocol behave in incompatible ways.