LLD eller lavt niveau design er en designproces på komponentniveau, der følger en trinvis forfiningsproces. Input til LLD er HLD.
Hvad er Low Level Design eller LLDn
Vigtige emner for Low Level Design (LLD)
- Hvad er Low-Level Design (LLD)?
- Hvordan adskiller LLD sig fra HLD
- Hvordan dannes LLD fra HLD?
- Køreplan til design på lavt niveau
Hvad er Low-Level Design (LLD)?
LLD, eller Low-Level Design, er en fase i softwareudviklingsprocessen, hvor detaljerede systemkomponenter og deres interaktioner er specificeret. Det involverer at konvertere højniveaudesignet til en mere detaljeret plan, der adresserer specifikke algoritmer, datastrukturer og grænseflader. LLD fungerer som en guide for udviklere under kodning, hvilket sikrer en nøjagtig og effektiv implementering af systemets funktionalitet. LLD beskriver klassediagrammer ved hjælp af metoder og relationer mellem klasser og programspecifikationer.
Husk: Design på lavt niveau er også kendt som design på objektniveau eller mikro-niveau eller detaljeret design .
Klassediagram i LLD
I dette diagram lister vi grundlæggende alle de entiteter, der kan indgå i komponenter. Klassediagrammer laves, da det bliver lettere for udvikleren at konvertere det til kode.
For eksempel:
User Service <-- User <--Profile <--ID>
Hvordan adskiller LLD sig fra HLD
Som undersøgt, High Level Design eller HLD er et generelt systemdesign, hvor vi foretager afvejninger mellem forskellige rammer, komponenter og forskellige databaser, og vi vælger det bedste i betragtning af, hvad virksomheden har behov for, og hvordan systemet skal fungere, både med hensyn til funktionelle og ikke-funktionelle aspekter. Her definerer vi komponenterne, og hvordan disse komponenter vil kommunikere med hinanden. Derfor er vi her generet med generiske ting som følger og ikke generet af koden.
string.format java-streng
- Udvælgelse af komponenter, platforme og forskellige værktøjer.
- Database design.
- Kort beskrivelse af sammenhænge mellem ydelser og moduler.
Hvordan dannes LLD fra HLD?
Som undersøgt ovenfor er input til indramning af lavniveaudesign (LLD) HLD. Her i LLD tager vi os af, hvordan vores komponenter vil se ud, den struktur, som forskellige enheder besidder, og hvordan forskellige enheder vil have deres ansvar (understøttet drift). Til denne konvertering bruger vi Unified Modeling Language (UML) diagrammer . Tilføjelse til disse diagrammer, vi bruger OOPS principper og SOLIDE principper mens du designer. Derfor kan vi ved at bruge disse 3 paradigmer konvertere enhver HLD til LLD for at blive implementeret.
Køreplan til design på lavt niveau
For at bygge bro mellem begreber om LLD med ægte kode, lad os For at forstå, hvordan man designer et hvilket som helst diagram på lavt niveau, lad os forstå via trinene:
1. Objektorienterede principper
Brugerkravet behandles ved at bruge koncepter for OOPS-programmering. Derfor anbefales det at have et stærkt greb om OOPS-koncepter, før man går videre med at designe et hvilket som helst lavniveau-system. Objektorienteret programmeringskoncept 4 søjler er et must for at begynde at lære design på lavt niveau, og programmøren bør være meget velbevandret med disse 4 søjler, nemlig som følger:
- Arv
- indkapsling
- polymorfi
- abstraktion
Inden for polymorfi bør vi være klare med kompileringstids- og runtime-polymorfi. Programmører bør være helt klar over OOPS-koncepterne til dybden lige til klasser og objekter, fordi OOPS er grundlaget, som lav-nivellering på ethvert system er baseret på. At opnå design på lavt niveau er 'ekstremt subjektivt', fordi vi skal bruge disse koncepter optimalt, mens vi koder for at bygge et system på lavt niveau via implementering af kodningssoftwareenheder (klasser, funktioner, moduler osv.)
2. Proces med analyse og design
Det er en analysefase, som er vores 1. trin, hvor vi sammensætter problemer fra den virkelige verden til problemer i objektverdenen ved hjælp af OOPS-koncepter og SOLID-principper.
3. Design mønstre
Nu udføres implementeringen af vores ovenstående objektorienterede problem ved hjælp af designmønstre. Designmønstre er genanvendelige løsninger på almindelige problemer, man støder på i softwaredesign. De giver en struktureret tilgang til design ved at indfange bedste praksis og gennemprøvede løsninger, hvilket gør det nemmere at udvikle skalerbar, vedligeholdelig og effektiv software. Designmønstre hjælper med at strømline udviklingsprocessen, fremme genbrug af kode og forbedre den overordnede kvalitet af softwaresystemer.
Hvert mønster beskriver et problem, der opstår igen og igen flere gange i miljøet, og deres løsninger kan anvendes gentagne gange uden redundans.
Hvorfor er der behov for designmønstre?
Disse problemer er opstået igen og igen, svarende til hvilke disse løsninger er blevet lagt. Disse problemer er blevet konfronteret med og løst af ekspertdesignere i programmeringsverdenen, og løsningerne er robuste over tid, hvilket sparer en masse tid og energi. Derfor bliver de komplekse og klassiske problemer i softwareverdenen løst ved afprøvede løsninger.
windows.åbn javascript
Tip: Det anbefales kraftigt at have en god forståelse af almindelige designmønstre for at have et godt hold over design på lavt niveau.
Forskellige typer designmønstre
Der er meget mange typer designmønstre, lad os diskutere 4 typer designmønstre, der er flittigt brugt globalt:
- Fabriksdesignmønster
- Abstrakt fabriksmønster
- Singleton mønster
- Observer mønster
Det anbefales også at studere nedenstående 5 designmønstre, da disse er mindre nødvendige, men det anbefales at lære for den grundlæggende forståelse af designmønstrene.
- Builder mønster
- Ansvarskæde mønster
- Adapter mønster
- Facade mønster
- Flyvevægt mønster
4. UML diagram
De er 2 typer UML-diagrammer:
java program
- Strukturelt UML-diagram: Disse typer af diagrammer definerer grundlæggende, hvordan forskellige enheder og objekter vil blive struktureret og definerer forholdet mellem dem. De er nyttige til at repræsentere, hvordan komponenter vil fremstå med hensyn til struktur.
- Adfærdsmæssigt UML-diagram: Disse typer diagrammer definerer grundlæggende, hvad der er de forskellige operationer, som det understøtter. Her viser forskellige adfærdsmæssige UML forskellige adfærdsmæssige af
Tip: Vigtige UML-diagrammer, der ofte bruges af udviklere, er som følger:
- Klassediagram fra Strukturelt UML-diagram
- Sekvens , Use case og Aktivitet fra Behavioural UML Diagram.
5. SOLIDE principper
Disse er sæt af 5 principper(regler), der nøje følges i henhold til kravene til systemet eller krav til optimal design.
For at skrive skalerbar, fleksibel, vedligeholdelig og genbrugelig kode:
- Enkeltansvarsprincippet (SRP)
- Åbent-lukket princip (OCP)
- Liskovs substitutionsprincip (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
Det er vigtigt at huske på, at SOLID principper kun er retningslinjer og ikke strenge regler, der skal følges. Nøglen er at finde en balance mellem at overholde disse principper og overveje de specifikke behov og begrænsninger i din virksomheds krav.