LLD of low-level ontwerp is een ontwerpproces op componentniveau dat een stapsgewijs verfijningsproces volgt. De invoer voor LLD is HLD.

Wat is Low Level Design of LLDn

Belangrijke onderwerpen voor het Low Level Design (LLD)

• Wat is Low-Level Design (LLD)?
• Waarin verschilt LLD van HLD
• Hoe LLD van HLD vormen?
• Routekaart naar ontwerpen op laag niveau

Wat is Low-Level Design (LLD)?

LLD, of Low-Level Design, is een fase in het softwareontwikkelingsproces waarin gedetailleerde systeemcomponenten en hun interacties worden gespecificeerd. Het omvat het omzetten van het ontwerp op hoog niveau in een meer gedetailleerde blauwdruk, waarbij specifieke algoritmen, datastructuren en interfaces aan de orde komen. LLD dient als gids voor ontwikkelaars tijdens het coderen en zorgt voor een nauwkeurige en efficiënte implementatie van de systeemfunctionaliteit. LLD beschrijft klassendiagrammen met behulp van methoden en relaties tussen klassen en programmaspecificaties.

Herinneren: Ontwerpen op laag niveau wordt ook wel genoemd ontwerpen op objectniveau of micro niveau of gedetailleerd ontwerpen .

samengestelde primaire sleutel

Klassendiagram in LLD

In dit diagram geven we in principe alle entiteiten weer die deel kunnen uitmaken van componenten. Klassendiagrammen worden gemaakt omdat het voor ontwikkelaars gemakkelijker wordt om deze in code om te zetten.

Bijvoorbeeld:

User Service  <-- User   <--Profile  <--ID>

Waarin verschilt LLD van HLD

Zoals bestudeerd, Ontwerp op hoog niveau of HLD is een algemeen systeemontwerp waarbij we afwegingen maken tussen verschillende raamwerken, componenten en verschillende databases en we de beste kiezen, rekening houdend met wat het bedrijf nodig heeft en hoe het systeem zou moeten werken, zowel in termen van functionele als niet-functionele aspecten. Hier definiëren we de componenten en hoe deze componenten met elkaar zullen communiceren. Daarom houden we ons hier als volgt bezig met generieke zaken en maken we ons geen zorgen over de code.

1. Selectie van componenten, platforms en verschillende tools.
2. Database-ontwerp.
3. Korte beschrijving van relaties tussen services en modules.

Hoe LLD van HLD vormen?

Zoals hierboven bestudeerd, is de input voor het framen van low-level design (LLD) HLD. Hier bij LLD zorgen we ervoor hoe onze componenten eruit zullen zien, de structuur die verschillende entiteiten bezitten en hoe verschillende entiteiten hun verantwoordelijkheid zullen hebben (ondersteunde operaties). Voor deze conversie gebruiken we Unified Modeling Language (UML)-diagrammen . Als aanvulling op deze diagrammen gebruiken we OOPS-principes En SOLIDE principes tijdens het ontwerpen. Met behulp van deze drie paradigma's kunnen we dus elke HLD naar LLD omzetten om deze te implementeren.

Routekaart naar ontwerpen op laag niveau

Laten we, om de concepten van LLD te overbruggen met echte code, het volgende doen: Om te begrijpen hoe we een diagram op laag niveau moeten ontwerpen, kunnen we dit begrijpen via de stappen:

string-tokenizer java

Java-programma

1. Objectgerichte principes

De gebruikersbehoefte wordt verwerkt door concepten van OOPS-programmering te gebruiken. Daarom wordt aanbevolen om een ​​sterke grip te hebben op OOPS-concepten voordat u verder gaat met het ontwerpen van een laag niveau-systeem. Objectgeoriënteerd programmeerconcept 4 pijlers zijn een must-have om te beginnen met het leren van ontwerpen op laag niveau en de programmeur moet zeer goed thuis zijn in deze 4 pijlers, namelijk als volgt:

1. Erfenis
2. inkapseling
3. polymorfisme
4. abstractie

Binnen het polymorfisme moeten we duidelijk zijn over het compile-time- en runtime-polymorfisme. Programmeurs moeten absoluut duidelijk zijn over de OOPS-concepten om tot in klassen en objecten te komen, omdat OOPS de basis is waarop low-leveling op elk systeem is gebaseerd. Het ontwerpen op laag niveau is ‘extreem subjectief’ omdat we deze concepten optimaal moeten gebruiken tijdens het coderen om een ​​systeem op laag niveau te bouwen door het implementeren van coderingssoftware-entiteiten (klassen, functies, modules, enz.)

2. Proces van analyseren en ontwerpen

Het is een analysefase die onze eerste stap is waarin we problemen uit de echte wereld omvormen tot problemen uit de objectwereld met behulp van OOPS-concepten en SOLID-principes.

3. Ontwerppatronen

Nu wordt de implementatie van ons bovenstaande objectgeoriënteerde probleem uitgevoerd met behulp van ontwerppatronen. Ontwerppatronen zijn herbruikbare oplossingen voor veelvoorkomende problemen bij het ontwerpen van software. Ze bieden een gestructureerde ontwerpbenadering door best practices en bewezen oplossingen vast te leggen, waardoor het gemakkelijker wordt om schaalbare, onderhoudbare en efficiënte software te ontwikkelen. Ontwerppatronen helpen het ontwikkelingsproces te stroomlijnen, hergebruik van code te bevorderen en de algehele kwaliteit van softwaresystemen te verbeteren.

Elk patroon beschrijft een probleem dat zich meerdere keren in de omgeving voordoet, en de oplossingen ervan kunnen herhaaldelijk zonder redundantie worden toegepast.

Java-escape-teken

Waarom is er behoefte aan ontwerppatronen?

Deze problemen hebben zich keer op keer voorgedaan, in overeenstemming met dewelke deze oplossingen zijn uiteengezet. Deze problemen worden onder ogen gezien en opgelost door deskundige ontwerpers in de programmeerwereld en de oplossingen zijn in de loop van de tijd robuust en besparen veel tijd en energie. Daarom worden de complexe en klassieke problemen in de softwarewereld opgelost door beproefde oplossingen.

Tip: Het wordt ten zeerste aanbevolen om een ​​goed begrip te hebben van algemene ontwerppatronen om grip te krijgen op ontwerpen op een laag niveau.

Verschillende soorten ontwerppatronen

Er zijn veel soorten ontwerppatronen. Laten we vier soorten ontwerppatronen bespreken die wereldwijd op grote schaal worden gebruikt:

• Fabrieksontwerppatroon
• Abstract fabriekspatroon
• Singleton-patroon
• Waarnemer patroon

Het wordt ook aanbevolen om de onderstaande 5 ontwerppatronen te bestuderen, omdat deze minder nodig zijn, maar het wordt aanbevolen om te leren voor een basiskennis van de ontwerppatronen.

• Bouwer patroon
• Keten van verantwoordelijkheidspatroon
• Adapterpatroon
• Gevelpatroon
• Vlieggewicht patroon

4. UML-diagram

Er zijn 2 soorten UML-diagrammen:

1. Structureel UML-diagram: Dit soort diagrammen definieert in principe hoe verschillende entiteiten en objecten zullen worden gestructureerd en definieert de relatie daartussen. Ze zijn nuttig om weer te geven hoe componenten eruit zullen zien met betrekking tot de structuur.
2. Gedrags-UML-diagram: Dit soort diagrammen definieert in feite de verschillende bewerkingen die het ondersteunt. Hier toont verschillende gedrags-UML verschillende gedragsvormen

Tip: Belangrijke UML-diagrammen die vaak door ontwikkelaars worden gebruikt, zijn als volgt:

• Klassendiagram van Structureel UML-diagram
• Reeks , Gebruiksgeval En Activiteit uit het gedrags-UML-diagram.

5. SOLIDE Principes

Dit zijn sets van 5 principes (regels) die strikt worden gevolgd volgens de vereisten van het systeem of vereisten voor een optimaal ontwerp.

c#-tutorial

Om schaalbare, flexibele, onderhoudbare en herbruikbare code te schrijven:

1. Principe van één verantwoordelijkheid (SRP)
2. Open-gesloten principe (OCP)
3. Liskovs substitutieprincipe (LSP)
4. Interface-segregatieprincipe (ISP)
5. Afhankelijkheidsinversieprincipe (DIP)

Het is belangrijk om in gedachten te houden dat de SOLID-principes slechts richtlijnen zijn en geen strikte regels die moeten worden gevolgd. De sleutel is om een ​​evenwicht te vinden tussen het naleven van deze principes en het overwegen van de specifieke behoeften en beperkingen van uw zakelijke vereisten.