ソフトウェア開発では、 オブジェクト指向設計 は、柔軟でスケーラブル、保守可能、再利用可能なコードを作成する場合に重要な役割を果たします。 OOD を使用することには非常に多くの利点がありますが、すべての開発者は、プログラミングにおける優れたオブジェクト指向設計のための SOLID 原則も知っておく必要があります。 SOLID 原則は、Uncle Bob としても知られる Robert C. Martin によって導入され、プログラミングにおけるコーディング標準です。この原則は、以下に示す 5 つの原則の頭字語です。

• 単一責任原則 (SRP)
• オープン/クローズの原則
• リスコフの置換原理 (LSP)
• インターフェース分離原則 (ISP)
• 依存関係逆転の原則 (DIP)

SOLID 原理は密結合の軽減に役立ちます。密結合とは、クラスのグループが相互に大きく依存していることを意味し、コード内ではこれを避ける必要があります。

• 密結合の反対は疎結合であり、コードに疎結合クラスがある場合、コードは良好なコードとみなされます。
• 疎結合クラスはコードの変更を最小限に抑え、コードをより再利用しやすく、保守しやすく、柔軟性と安定性を高めるのに役立ちます。それでは、これらの原則を 1 つずつ説明しましょう。

1. 単一責任の原則

この原則は次のように述べています。 クラスを変更する理由は 1 つだけである必要があります これは、すべてのクラスが単一の責任、単一の仕事、または単一の目的を持たなければならないことを意味します。言い換えれば、クラスはソフトウェア システム内で 1 つのジョブまたは目的のみを持つ必要があります。

検索アルゴリズム

例を使用して単一責任の原則を理解しましょう。

パンを焼く責任のあるパン屋を想像してみてください。パン職人の役割は、パンを焼く作業に集中し、パンが高品質で適切に焼き上げられ、パン屋の基準を満たしていることを確認することです。

• ただし、パン屋が在庫の管理、消耗品の注文、顧客へのサービス、パン屋の清掃などの責任も負っている場合、これは SRP に違反することになります。
• これらのタスクはそれぞれ個別の責任を表しており、それらを組み合わせると、パンを焼く際のパン職人の集中力や効率が損なわれる可能性があります。
• SRP を遵守するために、ベーカリーはさまざまな役割をさまざまな個人またはチームに割り当てることができます。たとえば、在庫の管理を担当する人やチーム、消耗品の注文を担当する人、顧客にサービスを提供する人、パン屋の清掃を担当する人やチームが個別に存在する可能性があります。

2. オープン/クローズの原則

この原則は次のように述べています。 ソフトウェア エンティティ (クラス、モジュール、関数など) は拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります つまり、クラスの動作を変更せずに拡張できる必要があります。

Javaチェックがnullです

例を使用してオープン/クローズの原則を理解しましょう。

というクラスがあると想像してください。PaymentProcessor>オンラインストアの支払いを処理します。当初は、PaymentProcessor>このクラスは、クレジット カードを使用した支払い処理のみをサポートします。ただし、その機能を拡張して、PayPal を使用した支払い処理もサポートしたいと考えています。

既存のものを変更するのではなく、PaymentProcessor>PayPal サポートを追加するクラスを作成するには、次の名前の新しいクラスを作成します。PayPalPaymentProcessor>それを拡張するのはPaymentProcessor>クラス。このようにして、PaymentProcessor>クラスは変更に対してはクローズされたままですが、拡張に対してはオープンであり、オープンクローズの原則に準拠しています。

3. リスコフの置換原理

この原則は 1987 年に Barbara Liskov によって導入され、この原則に従っています。 派生クラスまたは子クラスは、基本クラスまたは親クラスの代わりに使用できる必要があります 。この原則により、親クラスの子であるクラスは、予期しない動作が発生することなく、その親の代わりに使用できることが保証されます。

例を使用してリスコフの置換原理を理解しましょう。

この原理の典型的な例の 1 つは、4 つの辺を持つ長方形です。長方形の高さと幅は任意の値にできます。正方形とは、幅と高さが等しい長方形です。したがって、rectangle クラスのプロパティを square クラスに拡張できると言えます。

これを行うには、4 つの等しい辺を持つ正方形の定義に適合するように子 (正方形) クラスを親 (長方形) クラスと交換する必要がありますが、派生クラスは親クラスの動作に影響を与えないため、そうする場合それはリスコフ置換原則に違反することになるということです。

4. インターフェース分離原理

この原則は、SOLID のクラスではなくインターフェイスに適用される最初の原則であり、単一責任の原則に似ています。それは次のように述べています クライアントに無関係なインターフェイスの実装を強制しないでください 。ここでの主な目標は、太いインターフェイスを回避し、多くの小さなクライアント固有のインターフェイスを優先することに重点を置くことです。 1 つの一般的なインターフェイスよりも多くのクライアント インターフェイスを使用し、各インターフェイスに特定の責任を持たせる必要があります。

クラスカルアルゴリズム

例を使用してインターフェイス分離の原則を理解しましょう。

あなたがレストランに入って、あなたが純粋なベジタリアンだと仮定してください。そのレストランのウェイターは、ベジタリアン料理、非ベジタリアン料理、飲み物、お菓子を含むメニューカードを渡しました。

• この場合、顧客は、食事で食べないものすべてではなく、ベジタリアンのアイテムのみを含むメニューカードを持っている必要があります。ここでは、さまざまなタイプの顧客に応じてメニューが異なる必要があります。
• 全員共通のメニューカードを1枚ではなく複数枚に分割することも可能です。この原則を使用すると、副作用と必要な変更の頻度を減らすことができます。

5. 依存関係逆転の原則

依存性反転原則 (DIP) は、次のように規定するオブジェクト指向設計の原則です。 高レベルのモジュールは低レベルのモジュールに依存しないでください。どちらも抽象化に依存する必要があります 。さらに、抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。

• より簡単に言うと、DIP は、クラスが具体的な実装ではなく抽象化 (インターフェイスや抽象クラスなど) に依存する必要があることを示唆しています。
• これにより、より柔軟で分離されたコードが可能になり、コードベースの他の部分に影響を与えることなく実装を変更することが容易になります。

例を使用して依存関係逆転の原理を理解しましょう。

ソフトウェア開発チームでは、開発者はコードベースへの変更を管理および追跡するために抽象バージョン管理システム (Git など) に依存しています。これらは、Git が内部でどのように動作するかという特定の詳細には依存しません。

インラインスタイルに反応する

これにより、開発者はバージョン管理の実装の複雑さを理解する必要がなく、コードの作成に集中できます。