LLD ali načrtovanje na nizki ravni je proces oblikovanja na ravni komponente, ki sledi procesu izpopolnjevanja po korakih. Vhod v LLD je HLD.
Kaj je nizkostopenjski dizajn ali LLDn
Pomembne teme za oblikovanje na nizki ravni (LLD)
- Kaj je načrtovanje na nizki ravni (LLD)?
- V čem se LLD razlikuje od HLD
- Kako oblikovati LLD iz HLD?
- Načrt za načrtovanje na nizki ravni
Kaj je načrtovanje na nizki ravni (LLD)?
LLD ali načrtovanje na nizki ravni je faza v procesu razvoja programske opreme, kjer so določene podrobne sistemske komponente in njihove interakcije. Vključuje pretvorbo načrta na visoki ravni v podrobnejši načrt, ki obravnava specifične algoritme, podatkovne strukture in vmesnike. LLD služi kot vodnik za razvijalce med kodiranjem in zagotavlja natančno in učinkovito implementacijo funkcionalnosti sistema. LLD opisuje diagrame razredov s pomočjo metod in odnosov med razredi in specifikacijami programa.
Ne pozabite: Oblikovanje na nizki ravni je znano tudi kot projektiranje na ravni objekta oz mikroravni oz podrobno projektiranje .
Diagram razredov v LLD
V tem diagramu v bistvu naštejemo vse entitete, ki so lahko del komponent. Diagrami razredov so narejeni tako, da jih razvijalec lažje pretvori v kodo.
Na primer:
User Service <-- User <--Profile <--ID>
V čem se LLD razlikuje od HLD
Kot so preučevali, Oblikovanje na visoki ravni ali HLD je splošna zasnova sistema, kjer delamo kompromise med različnimi ogrodji, komponentami in različnimi bazami podatkov ter izberemo najboljše glede na to, kaj potrebuje podjetje in kako naj bi sistem deloval, tako v smislu funkcionalnih kot nefunkcionalnih vidikov. Tukaj definiramo komponente in kako bodo te komponente med seboj komunicirale. Zato se tukaj obremenjujemo z generičnimi stvarmi, kot sledi, ne pa s kodo.
- Izbor komponent, platform in različnih orodij.
- Oblikovanje baze podatkov.
- Kratek opis odnosov med storitvami in moduli.
Kako oblikovati LLD iz HLD?
Kot smo raziskali zgoraj, je vhod za oblikovanje nizke ravni (LLD) HLD. Tukaj v LLD skrbimo za to, kako bodo izgledale naše komponente, strukturo, ki jo imajo različni subjekti, in kako bodo različni subjekti imeli svojo odgovornost (podprte operacije). Za to pretvorbo uporabljamo Diagrami Unified Modeling Language (UML). . Tem diagramom, ki jih uporabljamo, dodamo OOPS načela in SOLID načela med projektiranjem. Zato lahko z uporabo teh treh paradigm pretvorimo kateri koli HLD v LLD, da ga lahko implementiramo.
Načrt za načrtovanje na nizki ravni
Da bi premostili koncepte LLD z resnično kodo, nam dovolite, da razumemo, kako oblikovati kateri koli nizkonivojski diagram, po korakih:
1. Objektno usmerjena načela
Zahteva uporabnika je obdelana z uporabo konceptov programiranja OOPS. Zato je priporočljivo, da se dobro seznanite s koncepti OOPS, preden nadaljujete z načrtovanjem katerega koli nizkonivojskega sistema. Koncept objektno usmerjenega programiranja 4 stebri so nujni, da se začnete učiti načrtovanja na nizki ravni in programer bi moral biti zelo dobro seznanjen s temi 4 stebri, in sicer na naslednji način:
- Dedovanje
- enkapsulacija
- polimorfizem
- abstrakcija
Znotraj polimorfizma bi morali biti jasni glede polimorfizma časa prevajanja in izvajanja. Programerjem bi morali biti popolnoma jasni koncepti OOPS do globine, vse do razredov in objektov, ker je OOPS temelj, na katerem temelji nizkonivojsko delovanje v katerem koli sistemu. Nizkonivojsko načrtovanje je 'izjemno subjektivno', ker moramo optimalno uporabiti te koncepte med kodiranjem, da zgradimo nizkonivojski sistem z implementacijo programskih entitet za kodiranje (razredi, funkcije, moduli itd.)
2. Proces analiziranja in načrtovanja
To je faza analiziranja, ki je naš prvi korak, kjer težave iz resničnega sveta razvrstimo v probleme objektnega sveta z uporabo konceptov OOPS in načel SOLID.
3. Oblikovalski vzorci
Zdaj se implementacija našega zgornjega objektno orientiranega problema izvaja s pomočjo oblikovalskih vzorcev. Načrtovalni vzorci so rešitve za pogoste težave, ki se pojavljajo pri načrtovanju programske opreme, za večkratno uporabo. Zagotavljajo strukturiran pristop k oblikovanju z zajemanjem najboljših praks in preizkušenih rešitev, kar olajša razvoj razširljive, vzdržljive in učinkovite programske opreme. Oblikovalski vzorci pomagajo racionalizirati razvojni proces, spodbujajo ponovno uporabo kode in izboljšajo splošno kakovost programskih sistemov.
Vsak vzorec opisuje problem, ki se vedno znova pojavlja v okolju, njihove rešitve pa je mogoče uporabiti večkrat brez odvečnosti.
Zakaj obstaja potreba po oblikovalskih vzorcih?
Te težave so se pojavljale znova in znova, v skladu s katerimi so bile predstavljene te rešitve. S temi težavami se soočajo in jih rešujejo strokovni oblikovalci v svetu programiranja, rešitve pa so sčasoma robustne in prihranijo veliko časa in energije. Zato se kompleksni in klasični problemi v svetu programske opreme rešujejo s preizkušenimi rešitvami.
Nasvet: Zelo priporočljivo je, da dobro razumete običajne vzorce oblikovanja, da boste imeli dober nadzor nad načrtovanjem na nizki ravni.
Različne vrste oblikovalskih vzorcev
Obstaja zelo veliko vrst oblikovalskih vzorcev, razpravljajmo o 4 vrstah oblikovalskih vzorcev, ki se v veliki meri uporabljajo po vsem svetu:
- Tovarniški oblikovalski vzorec
- Abstraktni tovarniški vzorec
- Enojni vzorec
- Vzorec opazovalca
Priporočljivo je tudi, da preučite spodnjih 5 vzorcev načrtovanja, saj so ti manj potrebni, vendar je priporočljivo, da se naučite za osnovno razumevanje vzorcev načrtovanja.
java math.random
- Vzorec graditelja
- Vzorec verige odgovornosti
- Vzorec adapterja
- Vzorec fasade
- Vzorec muhe
4. UML diagram
Obstajata dve vrsti diagramov UML:
- Strukturni diagram UML: Te vrste diagramov v bistvu določajo, kako bodo strukturirani različni subjekti in objekti, ter opredeljujejo odnos med njimi. Pomagajo pri predstavitvi, kako bodo komponente videti glede na strukturo.
- Vedenjski diagram UML: Te vrste diagramov v bistvu določajo, katere različne operacije podpirajo. Tu različni vedenjski UML prikazujejo različno vedenje
Nasvet: Pomembni diagrami UML, ki jih razvijalci pogosto uporabljajo, so naslednji:
- Razredni diagram od Strukturni diagram UML
- Zaporedje , Primer uporabe in dejavnost iz vedenjskega diagrama UML.
5. Načela SOLID
To so sklopi 5 načel (pravil), ki se strogo upoštevajo glede na zahteve sistema ali zahteve za optimalno načrtovanje.
Če želite napisati razširljivo, prilagodljivo kodo, ki jo je mogoče vzdrževati in ponovno uporabiti:
- Načelo ene same odgovornosti (SRP)
- Odprto-zaprto načelo (OCP)
- Liskovo substitucijsko načelo (LSP)
- Načelo ločevanja vmesnika (ISP)
- Načelo inverzije odvisnosti (DIP)
Pomembno je vedeti, da so načela SOLID le smernice in ne stroga pravila, ki jih je treba upoštevati. Ključno je najti ravnotežje med spoštovanjem teh načel in upoštevanjem posebnih potreb in omejitev vaših poslovnih zahtev.