SOLID Principals - Liskov Substitution Principle (LSP)
The Liskov Substitution Principle (LSP) is one of the SOLID principles that guides the design of object-oriented systems. It emphasizes the idea that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
Overview of Liskov Substitution Principle
The Liskov Substitution Principle is named after Barbara Liskov, who introduced it in a paper titled “A Behavioral Notion of Subtyping.” The principle helps ensure that derived classes (subtypes) can be used interchangeably with their base classes (superclasses) without altering the desirable properties of the program.
Example 1: Violation of LSP
Consider a scenario where we have a class hierarchy representing different types of birds:
class Bird
def fly
# Code to make the bird fly
end
end
class Penguin < Bird
def fly
raise "Penguins can't fly!" # Violation of LSP
end
end
In this example, the Penguin class violates the Liskov Substitution Principle because it raises an exception when the fly method is called. Code that expects a Bird should be able to work with a Penguin without unexpected errors.
Refactoring for LSP
To adhere to the Liskov Substitution Principle, we can modify the class hierarchy to ensure that subtypes behave in a way expected by the base type:
class Bird
def move
# Code to make the bird move (common behavior)
end
end
class Penguin < Bird
def move
# Penguins can move by swimming
end
end
In this refactoring, we introduce a more generic method move in the base class Bird. Now, both Bird and its subtype Penguin adhere to the Liskov Substitution Principle, as Penguin provides a substitute behavior compatible with the base class.
Example 2: Using Interfaces
Ruby doesn’t have interfaces in the same way as languages like Java, but we can use modules to achieve a similar effect. Let’s consider an example where different animals can make sounds:
module SoundMaker
def make_sound
raise NotImplementedError, "Subclasses must implement this method"
end
end
class Dog
include SoundMaker
def make_sound
"Woof!"
end
end
class Cat
include SoundMaker
def make_sound
"Meow!"
end
end
In this example, the SoundMaker module acts as an interface, ensuring that any class including it must implement the make_sound method. This approach helps maintain consistency and adherence to the Liskov Substitution Principle.
Conclusion
The Liskov Substitution Principle promotes a design philosophy that encourages the creation of cohesive and interchangeable classes. By ensuring that subclasses can be used seamlessly in place of their base classes, developers create systems that are more flexible, maintainable, and extensible. The examples provided illustrate how to refactor code to adhere to LSP, fostering a robust and consistent object-oriented design in Ruby.