SOLIDE Prinzipien unter Verwendung einiger unterhaltsamer Analogien zum Fahrzeugbeispiel

SOLID ist ein Akronym für eine Gruppe von fünf guten Prinzipien (Regeln) in der Computerprogrammierung. SOLID ermöglicht es Programmierern, Code zu schreiben, der später leichter zu verstehen und zu ändern ist. SOLID wird häufig bei Systemen verwendet, die ein objektorientiertes Design verwenden.
Lassen Sie uns die SOLID-Prinzipien am Beispiel eines Fahrzeugs erklären. Stellen Sie sich vor, wir entwerfen ein System zur Verwaltung verschiedener Fahrzeugtypen, wie Autos und Elektroautos, für einen Transportdienst.

S - Single-Responsibility-Prinzip (SRP)

Fahrzeugbeispiel: Stellen Sie sich vor, Sie hätten ein Auto. Es ist für das Fahren verantwortlich, sollte aber nicht für die Durchführung seiner eigenen Wartungsarbeiten (wie Ölwechsel oder Reifenwechsel) verantwortlich sein. Dafür ist stattdessen ein eigener Mechaniker zuständig.
Erklärung: In unserem Code sollte die Fahrzeugklasse nur Dinge behandeln, die sich auf das Fahrzeug selbst beziehen, wie etwa die Speicherung von Marke und Modell. Wenn wir die Wartung verwalten müssen, erstellen wir dafür eine separate Wartungsklasse. Auf diese Weise hat jede Klasse eine Aufgabe oder Verantwortung, was die Verwaltung des Codes erleichtert.

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 - Offenes/Geschlossenes Prinzip (OCP)

Fahrzeugbeispiel: Angenommen, Sie haben ein einfaches Auto und möchten nun ein Elektroauto zu Ihrem System hinzufügen. Sie sollten die bestehende Fahrzeugklasse nicht ändern müssen, um Funktionen für Elektroautos hinzuzufügen. Stattdessen können Sie die bestehende Funktionalität erweitern, indem Sie eine neue Klasse für Elektroautos erstellen.
Erklärung: Die Fahrzeugklasse ist offen für Erweiterungen (Sie können neue Fahrzeugtypen wie ElectricVehicle erstellen), aber sie ist für Änderungen geschlossen (Sie müssen die Fahrzeugklasse selbst nicht ändern, um neue Typen hinzuzufügen).

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-Substitutionsprinzip (LSP)

Fahrzeugbeispiel: Stellen Sie sich vor, Sie verfügen über eine Fahrzeugflotte und können jedes normale Auto problemlos durch ein Elektroauto ersetzen. Beide sollten in der Lage sein, ihre Grundfunktion „Fahren“ auszuführen, ohne das System zu beschädigen.
Erklärung: Jede Unterklasse (wie ElectricVehicle) sollte in der Lage sein, ihre übergeordnete Klasse (Vehicle) zu ersetzen, ohne das Verhalten des Programms zu ändern. Dadurch wird sichergestellt, dass unser Code verschiedene Fahrzeugtypen auf die gleiche Weise verarbeiten kann.

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-Segregationsprinzip (ISP)

Fahrzeugbeispiel: Stellen Sie sich vor, Sie haben verschiedene Fahrzeugtypen: Einige können aufgeladen werden (wie Elektroautos), andere können nur gefahren werden (wie Benzinautos). Sie möchten nicht, dass sich ein Benzinauto mit Lademethoden auseinandersetzen muss.
Erklärung: Klassen sollten nur die Schnittstellen (oder Verhaltensweisen) implementieren, die sie benötigen. Beispielsweise könnte ein Elektrofahrzeug sowohl fahrbare als auch aufladbare Schnittstellen implementieren, während ein normales Fahrzeug nur fahrbare Schnittstellen implementiert.

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 - Abhängigkeitsinversionsprinzip (DIP)

Fahrzeugbeispiel: Stellen Sie sich vor, ein Auto könnte verschiedene Motortypen haben: einen Benzinmotor oder einen Elektromotor. Anstatt direkt von einem bestimmten Motortyp abhängig zu sein, sollte das Auto von einer allgemeineren Motorschnittstelle abhängig sein, damit es jeden Motortyp verwenden kann.
Erklärung: High-Level-Module (wie das Fahrzeug) sollten nicht von Low-Level-Modulen (wie GasEngine oder ElectricEngine) abhängen. Beide sollten von Abstraktionen abhängen (wie eine Engine-Schnittstelle). Dies macht das System flexibler und einfacher zu ändern.

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

Indem wir die SOLID-Prinzipien in diesem Fahrzeugbeispiel befolgen, können wir ein System aufbauen, das einfach zu warten, zu erweitern und an neue Anforderungen anzupassen ist.

LinkedIn: https://www.linkedin.com/in/anandsoni11/

Das obige ist der detaillierte Inhalt vonSOLIDE Prinzipien unter Verwendung einiger unterhaltsamer Analogien zum Fahrzeugbeispiel. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!