「労働者が自分の仕事をうまくやりたいなら、まず自分の道具を研ぎ澄まさなければなりません。」 - 孔子、「論語。陸霊公」
表紙 > プログラミング > 車両の例での楽しい例えを使用した SOLID 原則

車両の例での楽しい例えを使用した SOLID 原則

2024 年 11 月 6 日に公開
ブラウズ:891

SOLID principles using some fun analogies with Vehicle Example

SOLIDとは、コンピュータプログラミングにおける5つの優れた原則(ルール)の頭字語です。 SOLID を使用すると、プログラマは理解しやすく、後で変更しやすいコードを作成できます。 SOLID は、オブジェクト指向設計を使用するシステムでよく使用されます。
車両の例を使用して SOLID の原則を説明しましょう。輸送サービス用に、乗用車や電気自動車など、さまざまな種類の車両を管理するシステムを設計していると想像してください。

S - 単一責任原則 (SRP)

乗り物の例: 車を持っていると想像してください。運転する責任はありますが、独自のメンテナンス (オイル交換やタイヤの交換など) を処理する責任は負うべきではありません。代わりに、別の整備士がそれを担当します。
説明: このコードでは、Vehicle クラスは、メーカーやモデルの保存など、車両自体に関連することのみを処理する必要があります。メンテナンスを管理する必要がある場合は、そのための別のメンテナンス クラスを作成します。このようにして、各クラスに 1 つのジョブまたは責任があるため、コードの管理が容易になります。

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 - オープン/クローズ原則 (OCP)

車両の例: 基本的な自動車があり、システムに電気自動車を追加したいとします。電気自動車の機能を追加するために既存の自動車クラスを変更する必要はありません。代わりに、電気自動車用の新しいクラスを作成することで、既存の機能を拡張できます。
説明: Vehicle クラスは拡張が可能です (ElectricVehicle などの新しいタイプの車両を作成できます) が、変更は受け付けられていません (新しいタイプを追加するために Vehicle クラス自体を変更する必要はありません)。

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def description
    "#{@make} #{@model}"
  end
end

class ElectricVehicle 





L - リスコフ置換原理 (LSP)

車両の例: 多数の車両があり、普通車を問題なく電気自動車に置き換えることができると想像してください。どちらもシステムを壊すことなく、基本的な機能である運転を実行できる必要があります。
説明: サブクラス (ElectricVehicle など) は、プログラムの動作を変更することなく、その親クラス (Vehicle) を置き換えることができます。これにより、コードがさまざまなタイプの車両を同じ方法で処理できることが保証されます。

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

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

class ElectricVehicle 





I - インターフェース分離原理 (ISP)

車両の例: さまざまなタイプの車両があると想像してください。充電できる車両 (電気自動車など) もあれば、走行のみ可能な車両 (ガソリン車など) もあります。ガソリン車には充電関連の方法を考慮する必要はありません。
説明: クラスは必要なインターフェイス (または動作) のみを実装する必要があります。たとえば、ElectricVehicle は Drivable インターフェイスと Chargeable インターフェイスの両方を実装する可能性がありますが、通常の Vehicle は 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 





D - 依存関係逆転原理 (DIP)

車両の例: 車には、ガス エンジンや電気エンジンなど、さまざまな種類のエンジンが搭載されていると想像してください。車は特定のエンジン タイプに直接依存するのではなく、より一般的なエンジン インターフェイスに依存して、あらゆるタイプのエンジンを使用できるようにする必要があります。
説明: 高レベル モジュール (Vehicle など) は、低レベル モジュール (GasEngine や ElectricEngine など) に依存すべきではありません。どちらも抽象化 (エンジン インターフェイスなど) に依存する必要があります。これにより、システムがより柔軟になり、変更が容易になります。

class Engine
  def start
    raise NotImplementedError, "This #{self.class} cannot start"
  end
end

class GasEngine 



この車両例の SOLID 原則に従うことで、保守、拡張、新しい要件への適応が簡単なシステムを構築できます。

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

リリースステートメント この記事は次の場所に転載されています: https://dev.to/sonianand11/solid-principles-using-some-fun-analogies-with-vehicle-example-34p7?1 権利侵害がある場合は、[email protected] までご連絡ください。それを削除するには
最新のチュートリアル もっと>

免責事項: 提供されるすべてのリソースの一部はインターネットからのものです。お客様の著作権またはその他の権利および利益の侵害がある場合は、詳細な理由を説明し、著作権または権利および利益の証拠を提出して、電子メール [email protected] に送信してください。 できるだけ早く対応させていただきます。

Copyright© 2022 湘ICP备2022001581号-3