This article will present the Liskov Substitution Principle (LSP). Along with the introduction of this topic, examples from MechLynx project will be used (https://github.com/CharlieGearsTech/MechLynx)
SOLID principles were introduced by Robert C. Martin around 2000. These principles are “guidelines”, they are not rules due that the application of these principles for certain software systems will not be feasible or recommended in some cases. The goal of these principles is to create reusable software modules that are able to tolerate changes over time and are easy to understand.
LSP is a important feature to all Software Entity that conforms with the Open Close Principle which was introduced by Barbara Liskov as follows:
“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”
This means for example at Architectural level that: All interface between SW Components shall offer substitutable types. For example:
MechLynx SW system has an interface of Syntax Analyzer which serves functions where the client can pass Syntax Analyzer references without worry about how these references are treated. This is called extrinsic public behavior.
Syntax Analyzer contains two derived classes, Infix Syntax Analyzer and RPN Syntax Analyzer, both can behave as syntax analyzer within their own logic; this is called intrinsic private behavior.
Using this structure, the client (in this case through Inference Kernel), is using Syntax Analyzer regardless of its concrete type. Dynamically Syntax Analyzer will decide which type of Syntax Analyzer to use.
Now, the client decided to add a non-mathematical notation called “Doggo Notation”. Following OCP, it is possible to define Doggo Notation as a subtype of syntax Analyzer as follows due Doggo Notation contains the same intrinsic private behavior as Infix and RPN Notations:
As Doggo Notation only interacts with Left Tokens; then the Right Token interfaces are set with the value of the current Left Token. Allowing this, the implementation would be amiss: Client would expect the public behavior of Doggo Notation when passing an reference of Syntax Analyzer, probably Client extrinsic public behavior expect that Left Token and Right Token of all Syntax Analyzer types, shall be different; this is not the case of Doggo Notation.
Since due LSP, all functions that use reference of a base class shall be able to use derived classes without knowing it, some uses of Doggo Notation do not match the uses of Syntax Analyzer, then Doggo Notation violates LSP.
A way to solve this is by considering that the relationship of real world entities does not share the same relationship among their code representations. Therefore, Doggo Notation can be called a Meme Notation sub type and avoid the relationship with Syntax Analyzer.