LLD または低レベル設計 は、段階的な改良プロセスに続くコンポーネント レベルの設計プロセスです。 LLD への入力は HLD です。
ローレベルデザインまたはLLDnとは何ですか
ローレベルデザイン(LLD)の重要なトピック
Javaの文字から文字列へ
ローレベルデザイン(LLD)とは何ですか?
LLD (低レベル設計) は、詳細なシステム コンポーネントとその相互作用を指定するソフトウェア開発プロセスのフェーズです。これには、高レベルの設計をより詳細な設計図に変換し、特定のアルゴリズム、データ構造、インターフェイスに対応する作業が含まれます。 LLD は開発者がコーディングする際のガイドとして機能し、システムの機能を正確かつ効率的に実装できるようにします。 LLD は、メソッドと、クラスとプログラム仕様間の関係を利用してクラス図を記述します。
覚えて： 低レベル設計とも呼ばれます。 オブジェクトレベルの設計 または ミクロレベル または 詳細設計 。
LLD のクラス図
この図では、基本的に、コンポーネントの一部となり得るすべてのエンティティをリストします。クラス図は、開発者がコードに変換しやすいように作成されます。
例えば：
User Service <-- User <--Profile <--ID>
LLD と HLD はどう違うのですか
研究したように、 高レベル設計または HLD は、さまざまなフレームワーク、コンポーネント、およびさまざまなデータベース間でトレードオフを行い、機能面と非機能面の両方の観点から、ビジネスに必要なものとシステムがどのように機能するかを考慮して最適なものを選択する一般的なシステム設計です。ここでは、コンポーネントと、これらのコンポーネントが相互に通信する方法を定義します。したがって、ここでは次のような一般的な内容に注目し、コードについては気にしません。
- コンポーネント、プラットフォーム、さまざまなツールの選択。
- データベースの設計。
- サービスとモジュール間の関係の簡単な説明。
HLD から LLD を形成するにはどうすればよいですか?
上で検討したように、フレーミング低レベル デザイン (LLD) の入力は HLD です。ここ LLD では、コンポーネントがどのように見えるか、さまざまなエンティティが持つ構造、およびさまざまなエンティティがどのように責任を負うか (サポートされる操作) を管理します。この変換には、次を使用します。 統一モデリング言語 (UML) 図 。私たちが使用するこれらの図に加えて、 OOPS の原則 そして 堅固な原則 設計中。したがって、これら 3 つのパラダイムを使用すると、任意の HLD を LLD に変換して実装できます。
低レベル設計へのロードマップ
LLD の概念と実際のコードを橋渡しするために、低レベルの図を設計する方法を理解するために、次の手順を理解してみましょう。
1. オブジェクト指向の原則
ユーザー要件は、OOPS プログラミングの概念を使用して処理されます。したがって、低レベルのシステムの設計に進む前に、OOPS の概念をしっかりと理解することをお勧めします。オブジェクト指向プログラミングの概念 4 つの柱は、低レベル設計の学習を開始するために必須であり、プログラマはこれら 4 つの柱、つまり次の 4 つの柱に精通している必要があります。
- 継承
- カプセル化
- 多態性
- 抽象化
ポリモーフィズム内では、コンパイル時と実行時のポリモーフィズムを明確に区別する必要があります。 OOPS はあらゆるシステムの低レベル化の基礎となるため、プログラマは OOPS の概念を完全に理解し、クラスやオブジェクトまで深く理解する必要があります。低レベルの設計を進めることは「非常に主観的」です。なぜなら、コーディング中にこれらの概念を最適に使用して、コーディング ソフトウェア エンティティ (クラス、関数、モジュールなど) を実装して低レベル システムを構築する必要があるからです。
2. 分析・設計のプロセス
これは、OOPS の概念と SOLID 原則を使用して、現実世界の問題をオブジェクト世界の問題に組み込む最初のステップである分析フェーズです。
3. デザインパターン
ここで、上記のオブジェクト指向の問題の実装は、デザイン パターンの助けを借りて実行されます。設計パターンは、ソフトウェア設計で遭遇する一般的な問題に対する再利用可能な解決策です。これらは、ベスト プラクティスと実証済みのソリューションを取り込むことによって設計への構造化されたアプローチを提供し、拡張性、保守性、効率性の高いソフトウェアの開発を容易にします。デザイン パターンは、開発プロセスを合理化し、コードの再利用を促進し、ソフトウェア システムの全体的な品質を向上させるのに役立ちます。
各パターンは、環境内で何度も繰り返し発生する問題を記述しており、その解決策は重複することなく繰り返し適用できます。
なぜデザインパターンが必要なのでしょうか?
Javaのinstanceof
これらの問題は何度も発生しており、それに応じてこれらの解決策が提示されてきました。これらの問題は、プログラミングの世界の専門デザイナーによって直面され、解決されており、その解決策は長期にわたって堅牢であり、多くの時間とエネルギーを節約します。したがって、ソフトウェアの世界における複雑で古典的な問題は、実証済みのソリューションによって解決されています。
ヒント： 下位レベルの設計をしっかりと行うために、一般的な設計パターンをよく理解することを強くお勧めします。
デザイン パターンには非常に多くの種類がありますが、世界中で広く使用されている 4 種類のデザイン パターンについて説明します。
- 工場設計パターン
- 抽象的な工場パターン
- シングルトンパターン
- オブザーバーパターン
以下の 5 つのデザイン パターンも必要性は低いため、学習することをお勧めします。ただし、デザイン パターンの基本的な理解のために学習することをお勧めします。
- ビルダーパターン
- 責任の連鎖のパターン
- アダプターのパターン
- ファサードパターン
- フライウェイトパターン
4. UML図
これらは 2 種類の UML 図です。
Linux フォルダーの名前を変更
- 構造 UML 図: これらのタイプの図は基本的に、さまざまなエンティティやオブジェクトがどのように構造化され、それらの間の関係が定義されるかを定義します。これらは、コンポーネントが構造に関してどのように表示されるかを表すのに役立ちます。
- 動作 UML 図: これらのタイプの図は基本的に、サポートされるさまざまな操作が何であるかを定義します。ここでは、さまざまな動作の UML がさまざまな動作を示しています。
ヒント： 開発者が頻繁に使用する重要な UML 図は次のとおりです。
5. 確固たる原則
システムの要件や最適設計の要件に応じて厳格に遵守される 5 つの原則 (ルール) です。
スケーラブルで柔軟、保守可能、再利用可能なコードを作成するには、次の手順を実行します。
- 単一責任原則 (SRP)
- オープンクローズ原則 (OCP)
- リスコフの置換原理(LSP)
- インターフェース分離原則 (ISP)
- 依存関係逆転の原則 (DIP)
SOLID 原則は単なるガイドラインであり、従うべき厳格なルールではないことに留意することが重要です。重要なのは、これらの原則を遵守することと、ビジネス要件の特定のニーズと制約を考慮することとの間でバランスを取ることです。