SOLID principles using some fun analogies with Vehicle Example

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/

The above is the detailed content of SOLID principles using some fun analogies with Vehicle Example. For more information, please follow other related articles on the PHP Chinese website!