LSP: Liskov Substitution Principle • OnloadCode

Introduction

This is the 10th article in the System Design and Software Architecture series. In this article, we are discussing the sub-topic of the design principle, LSP: Liskov Substitution Principle.

What is The Liskov Substitution Principle?

At a higher level, the LSP states that in an object-oriented program, if we replace a super-class object reference with an object in any of its subclasses, the program should not break.

According to the LSP, functions that use references to basic classes can use them without knowing the objects of the derivative class. In simple words, derivative classes should be substitutable for the base class. To illustrate LSP, we take the example of rectangles and squares. Someone tends to confirm the ISA connection and, thus, you can say a square is a rectangle.

The Liskov Substitution Principle states: “In a computer program, if S is a subtype of T, T-type objects can be substituted for S-type objects without modification (i.e., S-type objects have the ability to substitute for T-type objects), which is one of the preferred properties of the program (i.e., the work performed, etc.). Simply put, in an object-oriented program, any object in a class can be replaced by a child class object. To better understand this principle, we would like to make a brief mention of the concept of inheritance and its properties, as well as a brief reminder of a subtype polymorphism.

Quality of Code Represented by the LSP

The following are some of the qualitative characteristics of the code represented by the Liskov Substitution Principle:

Only when derivatives are completely substitutable for their base types can the functions that use those base types be reused without modification, and the derivatives can be modified without modification.
LSP is also referred to as “design by contract.” Using this scheme, the class system states the preconditions and post-conditions. The preconditions for the system to operate must be true. Upon completion, the system certifies that the post-condition is true.
Contract design affects the “throw” exception statement as well as the runtime exception throw and general try/catch.

Inheritance, Polymorphism, Subtype

Inheritance is a fairly simple concept that one can understand. It occurs when an object or class is based on another object or class. When a class is “inherited” from another class, it means that the inherited class (also known as the subclass or child class) contains all the characteristics of the superior class (parent class) but may also contain new attributes. We illustrate this with a common example: if you have a class watch, you can inherit it from that class to get a class pocket watch. The pocket watch is still a watch; it has a few extra features only. Another example is the class where the mother is the woman with the child class. In addition to having a baby, but the point is a mother is still a woman.
This brings us to the next term that needs to be explained, which is called polymorphism: objects that can be manipulated in one way and manipulated in another. In object-oriented programming, this is called context-dependent behavior. To use the last example: A mother behaves like a mother when she walks with her child or attends a school parent meeting. But when she is with her friends, at work, or when she makes a mistake, she will behave like a woman.
The subtype is a concept that is not dissimilar to polymorphism. However, the two are closely intertwined in common languages such as C++, Java, and C#, and there is practically no difference between them. For completeness, we provide a formal definition of sub-classification, but the details are not discussed in this article. “In programming language theory, a subtype (subclass polymorphism or inclusion polymorphism) is a type of polymorphism. A subtype is a data type that is related to another data type (supertype) and is based on some concept of substitution, that is, the program element. Subtypes or functions written to operate on the elements of the supertype can also operate on the element of the subtype. If S is a subtype of T, the subtype relation is often written as S : T, which means that any S type application can be used safely in a context where a T type term is desired.”

Requirements

Liskov substitution principle in new object-oriented programming languages (usually at the class level rather than types; nominal versus structural).
The covariance of method parameters of subtype.
Covariance of subtype method return types.
New exceptions cannot be thrown by subtype methods except for subtypes of exceptions thrown by supertype methods.
In addition to signature requirements, the subtype must meet several behavioral conditions. These are described in detail in the terminology similar to the plan in terms of contract methodology, which may impose some limitations on how the contract inheritance can interact with:
- The preconditions of the subtype cannot be strengthened.
- The post-conditions of the subtype should not be weakened.
- Invariants must be preserved within the subtype.

History Boundary (“History Rule”)

The history boundary forbids this. It is a new feature introduced by Liskov and Wing.

This limit can be exemplified by defining a mutable point as a subtype of an immutable point. This violates the boundaries of history because the history of the immutable point and the history of a mutable point, in general, cannot be combined, as the state after creation is always the same.
However, the fields added to the subtype can be safely modified because they are not tracked by supertype methods. Thus, a circle with an immutable center and a mutable radius can be defined as a subtype of a point that cannot be changed without violating the boundaries of history.

Conclusion

Thanks for reading the article LSP: Liskov Substitution Principle as an essential component in system design and architecture.

Originally published at https://onloadcode.com on March 28, 2021.