In this second entry, we continue telling you about the SOLID principles, to maintain order when programming, with examples from day to day.
LSP: Liskov Substitution Principle
This principle was baptized in the name of Barbara Liskov, she, in her work named, "Behavioral Subtyping Using Invariants and Constraints" presents a way of defining the subtype relationship that is able to ensure that the objects of this subtype , they can preserve the behavioral properties of their supertypes. The subtype relationship is based on the specifications of the sub and super types.
She created some mathematical rules, which must be taken in consideration for the following conditions to be met:
The main class or client should only use the methods of the parent class.
The child class must not alter the behavior of the parent class's methods.
Contravariance of Arguments
If the subclass implements the same method, then they must have the same number of arguments. The type of each argument in the subclass method must be the same as the one it is inheriting.
Result covariance
If the method of the base type returns any result, then the result of the subtype method can be a subtype of the base result type.
Rule for exceptions
The exceptions thrown by the subtype must belong to the set of exceptions thrown by its type.
Pre-condition rule
An assertion about the state of the system before the method is called. Preconditions required by methods of the subclass must not be stronger than the preconditions required by its superclass.
Post-condition rule
A statement about the state of the system after the method has been called. Clients that invoke the subclass should not be surprised by the return type of the method.
Class invariance
An assertion about a specific property of the class that is always true. An invariant is a condition or property that holds true.
Constraint rule
A subclass must include all constraints that its superclass exhibits.
ISP: Interface Segregation Principle
The interface segregation principle states that clients are not forced to rely on interfaces they do not use. In the previous example we started to see how the interfaces help us to abstract the "how" from the "what" to the point that we can depend on the contract (calculateArea) without even knowing what happens in each implementation to generate said area.
But in some cases there may be cases where the interfaces define more methods than your client needs. From here can derive the need to extract the definition of certain functionalities from a high-level interface and make use of inheritance (Object-Oriented Programming), or the composition of functions (functional programming) to compose an interface according to the client's concept. An example of this can be the birds, we can start with an interface that represents the birds and implement it for the case of the Aguila class:
So far so good, the eagle can scream, can fly, and plummet to hunt so the interface complies with what the client (the Eagle class needs), but what happens if we include a new bird, let's imagine that now let's add a penguin, which is a bird, can flap, but cannot fly:
In this case, the penguin client implements functionalities that are not typical of the species, which is why the segregation of the Ave interface comes in here. A penguin can flap, in addition to squawking, and swim. So the common with the Eagle is only flapping. so we can keep flapping as part of the Bird concept, but separate the specific things of the eagles and those of the penguin in two different interfaces, sharing by inheritance being Birds.
With this, the clients: Eagle and Penguin can determine which methods to implement according to their natures, the Eagle being a Flying Eagle can scream, fly and plummet while the Penguin can swim, leaving the segregation as follows:
In the final part of this article, we will delve into what is DIP: Dependency Inversion Principle, along with key concepts that will help you plan and create your code, avoiding errors and continuously.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.