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 




<hr>

<h2>
  
  
  L - Liskov Substitution Principle (LSP)
</h2>

<p><strong>Vehicle Example</strong>: 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.<br>
<strong>Explanation</strong>: 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.<br>
</p>

<pre class="brush:php;toolbar:false">class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle 




<hr>

<h2>
  
  
  I - Interface Segregation Principle (ISP)
</h2>

<p><strong>Vehicle Example</strong>: 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.<br>
<strong>Explanation</strong>: 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.<br>
</p>

<pre class="brush:php;toolbar:false">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 




<hr>

<h2>
  
  
  D - Dependency Inversion Principle (DIP)
</h2>

<p><strong>Vehicle Example</strong>: 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.<br>
<strong>Explanation</strong>: 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.<br>
</p>

<pre class="brush:php;toolbar:false">class Engine
  def start
    raise NotImplementedError, "This #{self.class} cannot start"
  end
end

class GasEngine 



<p>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.</p>

<p>LinkedIn: https://www.linkedin.com/in/anandsoni11/</p>


          

            
        

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!