LLD arba žemo lygio dizainas yra komponento lygio projektavimo procesas, kuris seka žingsnis po žingsnio tobulinimo procesą. Įvestis į LLD yra HLD.

Kas yra žemo lygio dizainas arba LLDn

Svarbios temos žemo lygio dizainui (LLD)

• Kas yra žemo lygio dizainas (LLD)?
• Kuo LLD skiriasi nuo HLD
• Kaip suformuoti LLD iš HLD?
• Žemo lygio projektavimo planas

Kas yra žemo lygio dizainas (LLD)?

LLD, arba žemo lygio projektavimas, yra programinės įrangos kūrimo proceso fazė, kurioje nurodomi detalūs sistemos komponentai ir jų sąveika. Tai apima aukšto lygio dizaino pavertimą detalesniu planu, sprendžiant konkrečius algoritmus, duomenų struktūras ir sąsajas. LLD tarnauja kaip vadovas kūrėjams kodavimo metu, užtikrinantis tikslų ir efektyvų sistemos funkcionalumo įgyvendinimą. LLD aprašo klasių diagramas naudodamas metodus ir ryšius tarp klasių ir programos specifikacijų.

Prisiminti: Žemo lygio projektavimas taip pat žinomas kaip objekto lygio projektavimas arba mikro lygiu arba detalus projektavimas .

powershell kelių eilučių komentaras

Klasės diagrama LLD

Šioje diagramoje iš esmės išvardijame visus objektus, kurie gali būti komponentų dalis. Klasių diagramos sudaromos, nes kūrėjui tampa lengviau jas konvertuoti į kodą.

masyvas java

Pavyzdžiui:

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

Kuo LLD skiriasi nuo HLD

Kaip studijavo, Aukšto lygio dizainas arba HLD yra bendras sistemos dizainas, kuriame mes darome kompromisus tarp skirtingų sistemų, komponentų ir skirtingų duomenų bazių ir pasirenkame geriausią, atsižvelgdami į verslo poreikius ir kaip sistema turėtų veikti, tiek funkcinių, tiek nefunkcinių aspektų atžvilgiu. Čia apibrėžiame komponentus ir tai, kaip šie komponentai bendraus vienas su kitu. Taigi čia mes varginamės dėl bendrų dalykų, o ne dėl kodo.

1. Komponentų, platformų ir įvairių įrankių pasirinkimas.
2. Duomenų bazės dizainas.
3. Trumpas paslaugų ir modulių ryšių aprašymas.

Kaip suformuoti LLD iš HLD?

Kaip išnagrinėta aukščiau, žemo lygio dizaino (LLD) kadravimo įvestis yra HLD. Čia, LLD, rūpinamės, kaip atrodys mūsų komponentai, skirtingų subjektų struktūra ir kaip skirtingi subjektai turės savo atsakomybę (palaikomos operacijos). Šiai konversijai naudojame Vieningos modeliavimo kalbos (UML) diagramos . Papildydami šias diagramas mes naudojame OOPS principai ir SOLID principai projektuojant. Taigi, naudodami šias 3 paradigmas, galime konvertuoti bet kurį HLD į LLD, kad būtų galima įgyvendinti.

Žemo lygio projektavimo planas

Norėdami sujungti LLD sąvokas su tikru kodu, leiskite mums suprasti, kaip sukurti bet kokią žemo lygio diagramą, leiskite mums suprasti atlikdami šiuos veiksmus:

java programa

1. Objektiniai principai

Vartotojo reikalavimas apdorojamas naudojant OOPS programavimo koncepcijas. Todėl prieš pradedant kurti bet kokią žemo lygio sistemą rekomenduojama stipriai įsisavinti OOPS koncepcijas. Objektinio programavimo koncepcijos 4 ramsčiai yra privalomi norint pradėti mokytis žemo lygio projektavimo, o programuotojas turėtų būti labai gerai susipažinęs su šiais 4 ramsčiais, būtent taip:

1. Paveldėjimas
2. inkapsuliavimas
3. polimorfizmas
4. abstrakcija

Polimorfizme turėtume aiškiai suprasti kompiliavimo ir vykdymo laiko polimorfizmą. Programuotojai turėtų būti visiškai aiškūs OOPS sąvokoms iki klasių ir objektų gylio, nes OOPS yra pagrindas, kuriuo grindžiamas žemo lygio nustatymas bet kurioje sistemoje. Žemo lygio projektavimas yra „labai subjektyvus“, nes koduodami turime optimaliai naudoti šias sąvokas, kad sukurtume žemo lygio sistemą, įgyvendindami kodavimo programinės įrangos objektus (klases, funkcijas, modulius ir kt.)

2. Analizės ir projektavimo procesas

Tai yra analizės fazė, kuri yra pirmasis mūsų žingsnis, kai realaus pasaulio problemas paverčiame objekto pasaulio problemomis, naudodami OOPS koncepcijas ir SOLID principus.

3. Dizaino raštai

Dabar mūsų aukščiau pateiktos objektinės problemos įgyvendinimas vykdomas naudojant dizaino modelius. Dizaino modeliai yra daugkartinio naudojimo problemų, su kuriomis susiduriama kuriant programinę įrangą, sprendimai. Jie pateikia struktūrinį požiūrį į dizainą, fiksuodami geriausią praktiką ir patikrintus sprendimus, todėl lengviau kurti keičiamo dydžio, prižiūrimą ir veiksmingą programinę įrangą. Dizaino modeliai padeda supaprastinti kūrimo procesą, skatina pakartotinį kodo naudojimą ir pagerina bendrą programinės įrangos sistemų kokybę.

Kiekvienas modelis aprašo problemą, kuri aplinkoje kartojasi kelis kartus, o jų sprendimai gali būti taikomi pakartotinai be pertekliaus.

java sala

Kodėl reikalingi dizaino modeliai?

Šios problemos kartojosi vėl ir vėl, todėl buvo išdėstyti šie sprendimai. Su šiomis problemomis susiduria ir jas išsprendžia patyrę dizaineriai programavimo pasaulyje, o sprendimai ilgainiui yra patikimi, taupydami daug laiko ir energijos. Taigi sudėtingos ir klasikinės programinės įrangos pasaulio problemos sprendžiamos išbandytais sprendimais.

Patarimas: Primygtinai rekomenduojama gerai išmanyti įprastus dizaino modelius, kad galėtumėte gerai valdyti žemo lygio projektavimą.

Įvairių tipų dizaino modeliai

Yra labai daug dizaino modelių tipų, aptarkime 4 dizaino modelių tipus, kurie plačiai naudojami visame pasaulyje:

• Gamyklos dizaino modelis
• Abstraktus gamyklos modelis
• Singleton modelis
• Stebėtojo modelis

Taip pat rekomenduojama išstudijuoti toliau pateiktus 5 dizaino modelius, nes jie yra mažiau reikalingi, tačiau rekomenduojama išmokti pagrindinį dizaino modelių supratimą.

• Statybininko modelis
• Atsakomybės grandinės modelis
• Adapterio modelis
• Fasado raštas
• Flyweight modelis

4. UML diagrama

Tai yra 2 UML diagramų tipai:

1. Struktūrinė UML diagrama: Šių tipų diagramos iš esmės apibrėžia, kaip bus struktūrizuoti skirtingi subjektai ir objektai, ir apibrėžia ryšį tarp jų. Jie padeda parodyti, kaip komponentai atrodys atsižvelgiant į struktūrą.
2. Elgsenos UML diagrama: Šio tipo diagramos iš esmės apibrėžia, kokias skirtingas operacijas jos palaiko. Čia skirtingos elgesio UML demonstruoja skirtingą elgesį

Patarimas: Svarbios UML diagramos, kurias dažnai naudoja kūrėjai, yra šios:

• Klasės diagrama iš Struktūrinė UML diagrama
• Seka , Naudojimo atvejis ir Veikla iš elgesio UML diagramos.

5. KIETIEJI principai

Tai yra 5 principų (taisyklės), kurių griežtai laikomasi pagal sistemos reikalavimus arba optimalaus projektavimo reikalavimus, rinkiniai.

masyvo sąrašas.rūšiuoti

Norėdami parašyti keičiamo dydžio, lankstų, prižiūrimą ir pakartotinai naudojamą kodą:

1. Vienos atsakomybės principas (SRP)
2. Atviro-uždarymo principas (OCP)
3. Liskovo pakeitimo principas (LSP)
4. Sąsajos atskyrimo principas (IPT)
5. Priklausomybės inversijos principas (DIP)

Svarbu nepamiršti, kad SOLID principai yra tik gairės, o ne griežtos taisyklės, kurių reikia laikytis. Svarbiausia yra rasti pusiausvyrą tarp šių principų laikymosi ir specifinių verslo poreikių bei suvaržymų įvertinimo.