SOLID is an acronym for a group of five good principles (rules) in computer programming. SOLID allows programmers to write code that is easier to understand and change later on. SOLID is often used with systems that use an object-oriented design.
Let's explain the SOLID principles using the vehicle example. Imagine we're designing a system to manage different types of vehicles, like cars and electric cars, for a transportation service.
S - Single Responsibility Principle (SRP)
Vehicle Example: Imagine you have a car. It's responsible for driving, but it shouldn't be responsible for handling its own maintenance (like oil changes or tyre rotations). Instead, a separate mechanic is responsible for that.
Explanation: In our code, the Vehicle class should only handle things related to the vehicle itself, like storing its make and model. If we need to manage maintenance, we create a separate Maintenance class for that. This way, each class has one job or responsibility, making the code easier to manage.
class Vehicle
def initialize(make, model)
@make = make
@model = model
end
end
class Maintenance
def initialize(vehicle)
@vehicle = vehicle
end
def perform_maintenance
puts "Performing maintenance on #{@vehicle.make} #{@vehicle.model}"
end
end
O - Open/Closed Principle (OCP)
Vehicle Example: Suppose you have a basic car, and now you want to add an electric car to your system. You shouldn't have to modify the existing car class to add features for electric cars. Instead, you can extend the existing functionality by creating a new class for electric cars.
Explanation: The Vehicle class is open for extension (you can create new types of vehicles like ElectricVehicle), but it's closed for modification (you don't need to change the Vehicle class itself to add new types).
class Vehicle
def initialize(make, model)
@make = make
@model = model
end
def description
"#{@make} #{@model}"
end
end
class ElectricVehicle < Vehicle
def initialize(make, model, battery_range)
super(make, model)
@battery_range = battery_range
end
def description
"#{super} with #{@battery_range} miles battery range"
end
end
L - Liskov Substitution Principle (LSP)
Vehicle Example: Imagine you have a fleet of vehicles, and you can replace any regular car with an electric car without any issues. Both should be able to perform their basic function - driving - without breaking the system.
Explanation: Any subclass (like ElectricVehicle) should be able to replace its parent class (Vehicle) without altering the behaviour of the program. This ensures that our code can handle different types of vehicles in the same way.
class Vehicle
def initialize(make, model)
@make = make
@model = model
end
def drive
puts "Driving the #{@make} #{@model}"
end
end
class ElectricVehicle < Vehicle
def drive
puts "Driving the electric #{@make} #{@model} quietly"
end
end
def test_drive(vehicle)
vehicle.drive
end
car = Vehicle.new("Toyota", "Corolla")
ev = ElectricVehicle.new("Tesla", "Model 3")
test_drive(car) # Driving the Toyota Corolla
test_drive(ev) # Driving the electric Tesla Model 3 quietly
I - Interface Segregation Principle (ISP)
Vehicle Example: Imagine you have different types of vehicles: some can be charged (like electric cars), and some can only be driven (like gas cars). You don't want a gas car to have to deal with charging-related methods.
Explanation: Classes should only implement the interfaces (or behaviours) they need. For example, an ElectricVehicle might implement both Drivable and Chargeable interfaces, while a regular Vehicle only implements Drivable.
module Drivable
def drive
raise NotImplementedError, "This #{self.class} cannot drive"
end
end
module Chargeable
def charge
raise NotImplementedError, "This #{self.class} cannot be charged"
end
end
class Vehicle
include Drivable
def initialize(make, model)
@make = make
@model = model
end
def drive
puts "Driving the #{@make} #{@model}"
end
end
class ElectricVehicle < Vehicle
include Chargeable
def initialize(make, model, battery_range)
super(make, model)
@battery_range = battery_range
end
def drive
puts "Driving the electric #{@make} #{@model} quietly"
end
def charge
puts "Charging the #{@make} #{@model}"
end
end
D - Dependency Inversion Principle (DIP)
Vehicle Example: Imagine a car can have different types of engines: a gas engine or an electric engine. Instead of directly depending on a specific engine type, the car should depend on a more general Engine interface so it can use any type of engine.
Explanation: High-level modules (like the Vehicle) should not depend on low-level modules (like GasEngine or ElectricEngine). Both should depend on abstractions (like an Engine interface). This makes the system more flexible and easier to change.
class Engine
def start
raise NotImplementedError, "This #{self.class} cannot start"
end
end
class GasEngine < Engine
def start
puts "Starting gas engine"
end
end
class ElectricEngine < Engine
def start
puts "Starting electric engine"
end
end
class Vehicle
def initialize(engine)
@engine = engine
end
def start
@engine.start
end
end
gas_engine = GasEngine.new
electric_engine = ElectricEngine.new
gas_car = Vehicle.new(gas_engine)
electric_car = Vehicle.new(electric_engine)
gas_car.start # Starting gas engine
electric_car.start # Starting electric engine
By following the SOLID principles in this vehicle example, we can build a system that is easy to maintain, extend, and adapt to new requirements.
LinkedIn: https://www.linkedin.com/in/anandsoni11/
Top comments (0)