底層設計與 SOLID 原則

低レベル設計 (LLD) は、高レベル設計と実際の実装の間のギャップを埋める、ソフトウェア開発における重要なフェーズです。高レベルの設計はアーキテクチャの設計図に焦点を当てますが、LLD はシステム全体の要件を満たすために各コンポーネント、クラス、または機能がどのように実装されるかを扱います。

もっと簡単に言うと、LLD には、クラス、メソッド、インターフェイス、およびそれらの間の相互作用の設計が含まれ、コードが効率的で、保守可能で、スケーラブルであることを保証します。これは、ソフトウェア エンジニアにとって、特に堅牢で再利用可能であり、長期にわたって簡単に変更できる必要があるシステムを構築する場合に不可欠なスキルです。

このブログでは、低レベル設計に関連する重要な概念、原則、テクニックを紹介し、それらがより優れた、より保守しやすいコードを作成するのにどのように役立つかを示します。

私たちの頭に浮かぶ最初の質問は次のとおりです:

低レベル設計が重要なのはなぜですか?

1. 保守性: よく考えられた設計により、コードの保守、拡張、デバッグが容易になります。不適切な設計は技術的負債につながり、将来の変更にコストがかかります。
2. スケーラビリティ: 優れた LLD により、パフォーマンスの点でも、システムの進化に伴う新機能のサポートの点でも、コードがスケーラブルであることが保証されます。
3. 再利用性: 適切に設計されたコンポーネントは、システムのさまざまな部分またはまったく異なるプロジェクトで再利用できます。
4. 明確さ: 明確に定義された設計により、エンジニアはシステムのさまざまな部分がどのように組み合わされるかを理解でき、コラボレーションが容易になります。

LLD の概念と実際のコードの間のギャップを埋めるために、次の手順に従って低レベルの図を設計するプロセスを詳しく見てみましょう。

ステップ 1:オブジェクト指向の原則
ステップ 2:堅固な原則
ステップ 3: パターンをデザインする

オブジェクト指向の原則

オブジェクト指向プログラミングの概念 4 つの柱は、低レベルの設計を学習し始めるために必須です。このコンセプトについては、簡単なチェックアウト ブログですでに説明しました

堅実な原則

S: 単一責任原則 (SRP)

• コードの各単位は 1 つの責任のみを持つ必要があります。
• ユニットは、クラス、モジュール、関数、またはコンポーネントです。
• コードのモジュール化を維持し、密結合を軽減します。

例: ユーザー認証とログ記録の両方を処理するクラスを想像してください。ロギングの仕組みを変更する必要がある場合、最終的には認証クラスも変更することになります。これはSRPに違反します。代わりに、2 つの別個のクラスを用意する必要があります。1 つはユーザー認証用、もう 1 つはログ記録用であり、各クラスが 1 つの責任を負います。

O: オープン/クローズ原則 (OCP)

• コードのユニットは拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります。
• 既存のコードを変更するのではなく、新しいコードを追加して機能を拡張します。
• React フロントエンドなどのコンポーネントベースのシステムで役立ちます。

例: クレジット カードによる支払いを処理する支払い処理システムを考えてみましょう。 PayPal のサポートを追加する必要がある場合は、既存のコードを変更するのではなく、PayPal 支払い用の新しいクラスを追加してコードを拡張する必要があります。これにより、既存のシステムが安定した状態を維持しながら、新しい機能を追加できるようになります。

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

• サブクラスは、基本クラスの代わりに使用できる必要があります。
• 基本クラスの機能はすべてのサブクラスで使用できる必要があります。
• サブクラスが基本クラスの機能を使用できない場合、そのサブクラスを基本クラスに含めるべきではありません。

例: fly() メソッドを持つ Bird クラスがあり、飛行できないサブクラス Penguin を作成すると、LSP に違反します。 Penguin クラスは、予期される動作を変更するため、fly() を継承しないでください。代わりに、異なる方法で飛べる鳥と飛べない鳥を処理できるように、Bird クラスをリファクタリングする必要があります。

I: インターフェース分離原則 (ISP)

• いくつかの汎用インターフェイスではなく、複数の特定のインターフェイスを提供します。
• クライアントは、使用していないメソッドに依存すべきではありません。

例: メソッド fly()、swim()、walk() を持つインターフェース Animal があると仮定します。 Animal を実装するクラス Dog は、必要のない fly() を定義する必要があります。 ISP に準拠するには、Animal インターフェイスを Flyable、Swimmable、Walkable などの小さなインターフェイスに分割して、クラスに無関係なメソッドを強制しないようにする必要があります

D：依賴倒置原則（DIP）

• 依賴抽象，而不是具體的類別。
• 使用抽象化來解耦系統各部分之間的依賴關係。
• 避免使用介面或抽像在程式碼單元之間直接呼叫。

範例：在電子商務應用程式中，如果結帳流程（進階模組）直接依賴 PayPal（低階模組）等特定支付網關，則更改支付網關需要修改結帳流程。透過引入抽象，例如 PaymentProcessor 接口，結帳流程可以使用任何付款方式，而無需了解 PayPal 或任何其他服務的具體資訊。

設計模式

設計模式是針對軟體設計中出現的常見問題的經過驗證的解決方案。它們是開發人員可以遵循的最佳實踐，可以有效、系統地解決特定的設計問題。設計模式不是重新發明輪子，而是提供了解決重複出現問題的標準方法。

設計模式可以分為三種：

1. 建立模式：處理物件建立

   • 工廠設計模式
   • 抽象工廠設計模式
   • 建構器設計模式
   • 原型設計模式
   • 單例設計模式

2. 結構模式：處理物件組合與關係

   • 適配器模式
   • 橋樑圖案
   • 複合模式
   • 裝飾器模式
   • 外觀圖案
   • 蠅量模式
   • 代理模式

3. 行為模式：處理物件互動與責任

   • 責任鏈模式
   • 指令模式
   • 解釋器模式
   • 調解員帕特
   • 紀念品圖案
   • 觀察者模式
   • 狀態模式
   • 策略模式
   • 模板方法模式
   • 訪客模式

現在我們已經透過探索 SOLID 原則奠定了基礎，並介紹了設計模式的廣闊前景，我們準備好深入研究了！在即將推出的系列中，我將透過實際範例和現實場景來分解每種設計模式。無論您是剛開始設計之旅還是希望提高自己的技能，這些模式都將幫助您編寫更清晰、更具可擴展性的程式碼。請繼續關注下一篇博客，我們將一步步揭開第一個設計模式！

如果您已經做到了這一步，請不要忘記按讚❤️，並在下面發表評論以提出任何問題或想法。您的回饋對我來說至關重要，我很樂意收到您的來信！

以上是底層設計與 SOLID 原則的詳細內容。更多資訊請關注PHP中文網其他相關文章！