LLD eller lågnivådesign är en designprocess på komponentnivå som följer steg för steg förfiningsprocessen. Indata till LLD är HLD.

Vad är Low Level Design eller LLDn

Viktiga ämnen för lågnivådesign (LLD)

• Vad är Low-Level Design (LLD)?
• Hur skiljer sig LLD från HLD
• Hur bildar man LLD från HLD?
• Färdkarta för design på låg nivå

Vad är Low-Level Design (LLD)?

LLD, eller Low-Level Design, är en fas i mjukvaruutvecklingsprocessen där detaljerade systemkomponenter och deras interaktioner specificeras. Det innebär att konvertera designen på hög nivå till en mer detaljerad ritning, adressering av specifika algoritmer, datastrukturer och gränssnitt. LLD fungerar som en guide för utvecklare under kodning, vilket säkerställer en korrekt och effektiv implementering av systemets funktionalitet. LLD beskriver klassdiagram med hjälp av metoder och relationer mellan klasser och programspecifikationer.

Kom ihåg: Lågnivådesign är också känd som design på objektnivå eller mikronivå eller detaljerad design .

romerska siffror 1-100

Klassdiagram i LLD

I detta diagram listar vi i princip alla enheter som kan ingå i komponenter. Klassdiagram görs eftersom det blir lättare för utvecklare att konvertera det till kod.

Till exempel:

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

Hur skiljer sig LLD från HLD

Som studerat, High Level Design eller HLD är en generell systemdesign där vi gör avvägningar mellan olika ramverk, komponenter och olika databaser och vi väljer det bästa med tanke på vad verksamheten behöver och hur systemet ska fungera, både vad gäller funktionella och icke-funktionella aspekter. Här definierar vi komponenterna och hur dessa kommer att kommunicera med varandra. Därför är vi här störda med generiska saker enligt följande och inte störda om koden.

1. Val av komponenter, plattformar och olika verktyg.
2. Databasdesign.
3. Kort beskrivning av relationer mellan tjänster och moduler.

Hur bildar man LLD från HLD?

Som studerats ovan är input för inramning av lågnivådesign (LLD) HLD. Här i LLD tar vi hand om hur våra komponenter kommer att se ut, strukturen som olika enheter besitter och hur olika enheter kommer att ha sitt ansvar (operationer stöds). För denna konvertering använder vi Unified Modeling Language (UML) diagram . Lägger till dessa diagram vi använder OOPS principer och SOLIDA principer medan du designar. Med hjälp av dessa tre paradigmer kan vi därför konvertera alla HLD till LLD för att bli implementerade.

Färdkarta för design på låg nivå

För att överbrygga begreppen LLD med verklig kod låt oss För att förstå hur man designar ett lågnivådiagram låt oss förstå via stegen:

när kom windows 7 ut

java-program

1. Objektorienterade principer

Användarkravet behandlas med hjälp av koncept för OOPS-programmering. Därför rekommenderas det att ha ett starkt grepp om OOPS-koncept innan man går vidare med att designa något lågnivåsystem. Objektorienterat programmeringskoncept 4 pelare är ett måste för att börja lära sig design på låg nivå och programmeraren bör vara mycket väl insatt i dessa 4 pelare, nämligen enligt följande:

1. Arv
2. inkapsling
3. polymorfism
4. abstraktion

Inom polymorfism bör vi vara tydliga med kompilerings- och körtidspolymorfism. Programmerare bör vara helt tydliga om OOPS-koncepten till djupet ända till klasser och objekt eftersom OOPS är grunden på vilken lågnivåing på alla system är baserad. Att uppnå lågnivådesign är 'extremt subjektivt' eftersom vi måste använda dessa koncept optimalt under kodning för att bygga ett lågnivåsystem genom att implementera kodningsprogramvaruenheter (klasser, funktioner, moduler, etc)

2. Process för analys och design

Det är en analysfas som är vårt första steg där vi förvandlar verkliga problem till objektvärldsproblem med hjälp av OOPS-koncept och SOLID-principer.

3. Designmönster

Nu genomförs implementeringen av vårt ovanstående objektorienterade problem med hjälp av designmönster. Designmönster är återanvändbara lösningar på vanliga problem som uppstår i mjukvarudesign. De tillhandahåller ett strukturerat tillvägagångssätt för design genom att fånga bästa praxis och beprövade lösningar, vilket gör det lättare att utveckla skalbar, underhållbar och effektiv programvara. Designmönster hjälper till att effektivisera utvecklingsprocessen, främja kodåteranvändning och förbättra den övergripande kvaliteten på mjukvarusystem.

Varje mönster beskriver ett problem som uppstår om och om igen flera gånger i miljön, och deras lösningar kan tillämpas upprepade gånger utan redundans.

Algoritm för bfs

Varför finns det ett behov av designmönster?

Dessa problem har uppstått om och om igen i enlighet med vilka dessa lösningar har lagts fram. Dessa problem har ställts inför och lösts av expertdesigners inom programmeringsvärlden och lösningarna är robusta över tid och sparar mycket tid och energi. Därför löses de komplexa och klassiska problemen i mjukvaruvärlden med beprövade lösningar.

Dricks: Det rekommenderas starkt att ha god förståelse för vanliga designmönster för att ha ett bra grepp om design på låg nivå.

Olika typer av designmönster

Det finns väldigt många typer av designmönster, låt oss diskutera 4 typer av designmönster som används flitigt globalt:

• Fabriksdesignmönster
• Abstrakt fabriksmönster
• Singleton mönster
• Observer mönster

Det rekommenderas också att studera nedanstående 5 designmönster eftersom dessa är mindre nödvändiga men det rekommenderas att lära sig för den grundläggande förståelsen av designmönstren.

• Builder mönster
• Ansvarskedja Mönster
• Adaptermönster
• Fasadmönster
• Flugviktsmönster

4. UML-diagram

Det finns två typer av UML-diagram:

1. Strukturellt UML-diagram: Dessa typer av diagram definierar i princip hur olika enheter och objekt kommer att struktureras och definierar relationen mellan dem. De är användbara för att representera hur komponenter kommer att se ut med avseende på struktur.
2. Beteende UML-diagram: Dessa typer av diagram definierar i grund och botten vad det är för olika operationer som det stöder. Här visar olika beteendemässiga UML olika beteendemässiga av

Dricks: Viktiga UML-diagram som ofta används av utvecklare är följande:

• Klassdiagram från Strukturellt UML-diagram
• Sekvens , Användningsfall och Aktivitet från Behavioral UML Diagram.

5. SOLIDA principer

Dessa är uppsättningar av 5 principer (regler) som strikt följs enligt kraven i systemet eller kraven för optimal design.

git lägg till alla

För att skriva skalbar, flexibel, underhållbar och återanvändbar kod:

1. Principen om ett enda ansvar (SRP)
2. Öppen-stängd princip (OCP)
3. Liskovs substitutionsprincip (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

Det är viktigt att komma ihåg att SOLID principer bara är riktlinjer och inte strikta regler som ska följas. Nyckeln är att hitta en balans mellan att följa dessa principer och att överväga de specifika behoven och begränsningarna i ditt företags krav.