LLD vai zema līmeņa dizains ir komponentu līmeņa projektēšanas process, kas seko soli pa solim pilnveidošanas procesam. LLD ievade ir HLD.

Kas ir zema līmeņa dizains jeb LLDn

Svarīgas tēmas zema līmeņa dizainam (LLD)

• Kas ir zema līmeņa dizains (LLD)?
• Kā LLD atšķiras no HLD
• Kā no HLD izveidot LLD?
• Ceļvedis uz zema līmeņa projektēšanu

Kas ir zema līmeņa dizains (LLD)?

LLD jeb zema līmeņa dizains ir programmatūras izstrādes procesa fāze, kurā tiek norādīti detalizēti sistēmas komponenti un to mijiedarbība. Tas ietver augsta līmeņa dizaina pārvēršanu detalizētākā projektā, pievēršoties konkrētiem algoritmiem, datu struktūrām un saskarnēm. LLD kalpo kā ceļvedis izstrādātājiem kodēšanas laikā, nodrošinot precīzu un efektīvu sistēmas funkcionalitātes ieviešanu. LLD apraksta klašu diagrammas, izmantojot metodes un attiecības starp klasēm un programmas specifikācijām.

Atcerieties: Zema līmeņa projektēšana ir pazīstama arī kā objektu līmeņa projektēšana vai mikrolīmenis vai detalizēts projektēšana .

Klases diagramma LLD

Šajā diagrammā mēs būtībā uzskaitām visas entītijas, kas var būt komponentu daļa. Klašu diagrammas tiek veidotas, jo izstrādātājam kļūst vieglāk to pārvērst kodā.

Piemēram:

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

Kā LLD atšķiras no HLD

Kā pētīts, Augsta līmeņa dizains vai HLD ir vispārējs sistēmas dizains, kurā mēs veicam kompromisus starp dažādiem ietvariem, komponentiem un dažādām datu bāzēm un izvēlamies labāko, ņemot vērā uzņēmuma vajadzības un to, kā sistēmai jādarbojas gan funkcionālo, gan nefunkcionālo aspektu ziņā. Šeit mēs definējam komponentus un to, kā šie komponenti sazināsies viens ar otru. Tāpēc šeit mūs nomoka tālāk norādītās vispārīgās lietas, nevis kods.

1. Komponentu, platformu un dažādu rīku izvēle.
2. Datu bāzes dizains.
3. Īss pakalpojumu un moduļu attiecību apraksts.

Kā no HLD izveidot LLD?

Kā pētīts iepriekš, ievade zema līmeņa dizaina (LLD) kadrēšanai ir HLD. Šeit, LLD, mēs rūpējamies par to, kā izskatīsies mūsu komponenti, par struktūru, kas pieder dažādām entītijām, un par to, kā dažādām entītijām būs sava atbildība (atbalstītas darbības). Šai konversijai mēs izmantojam Vienotās modelēšanas valodas (UML) diagrammas . Pievienojot šīm diagrammām, mēs izmantojam OOPS principi un SOLID principi projektēšanas laikā. Tādējādi, izmantojot šīs 3 paradigmas, mēs varam pārvērst jebkuru HLD par LLD, lai to ieviestu.

Ceļvedis uz zema līmeņa projektēšanu

Lai apvienotu LLD koncepcijas ar reālu kodu, lai saprastu, kā izveidot jebkuru zema līmeņa diagrammu, ļaujiet mums saprast, veicot šādas darbības:

1. Objektorientēti principi

Lietotāja prasības tiek apstrādātas, izmantojot OOPS programmēšanas koncepcijas. Tāpēc pirms jebkuras zema līmeņa sistēmas projektēšanas ir ieteicams stingri pārzināt OOPS koncepcijas. Objektorientētās programmēšanas koncepcijas 4 pīlāri ir obligāti, lai sāktu mācīties zema līmeņa projektēšanu, un programmētājam ir ļoti labi jāpārzina šie 4 pīlāri, proti:

1. Mantojums
2. iekapsulēšana
3. polimorfisms
4. abstrakcija

Polimorfisma ietvaros mums ir jābūt skaidram ar kompilēšanas laika un izpildlaika polimorfismu. Programmētājiem ir jābūt pilnīgi skaidram par OOPS jēdzieniem līdz pat klasēm un objektiem, jo ​​OOPS ir pamats, uz kura balstās zemā līmeņa noteikšana jebkurā sistēmā. Zema līmeņa dizains ir “ārkārtīgi subjektīvs”, jo mums ir optimāli jāizmanto šie jēdzieni kodēšanas laikā, lai izveidotu zema līmeņa sistēmu, ieviešot kodēšanas programmatūras entītijas (klases, funkcijas, moduļi utt.)

2. Analīzes un projektēšanas process

Tā ir analīzes fāze, kas ir mūsu pirmais solis, kurā mēs pārvēršam reālās pasaules problēmas objektu pasaules problēmās, izmantojot OOPS koncepcijas un SOLID principus.

3. Dizaina modeļi

Tagad mūsu iepriekš minētās objektorientētās problēmas īstenošana tiek veikta, izmantojot dizaina modeļus. Dizaina modeļi ir atkārtoti lietojami risinājumi bieži sastopamām programmatūras projektēšanas problēmām. Tie nodrošina strukturētu pieeju dizainam, tverot labāko praksi un pārbaudītus risinājumus, atvieglojot mērogojamu, uzturējamu un efektīvu programmatūru. Dizaina modeļi palīdz racionalizēt izstrādes procesu, veicina koda atkārtotu izmantošanu un uzlabo programmatūras sistēmu vispārējo kvalitāti.

Katrs modelis apraksta problēmu, kas vidē atkārtojas vairākas reizes, un to risinājumus var izmantot atkārtoti bez liekām pārbaudēm.

Kāpēc ir nepieciešami dizaina modeļi?

Šīs problēmas ir radušās atkal un atkal, atbilstoši kurām šie risinājumi ir izklāstīti. Ar šīm problēmām saskaras un tās atrisina pieredzējuši dizaineri programmēšanas pasaulē, un risinājumi laika gaitā ir stabili, ietaupot daudz laika un enerģijas. Tādējādi sarežģītās un klasiskās problēmas programmatūras pasaulē tiek atrisinātas ar pārbaudītiem risinājumiem.

Padoms: Ir ļoti ieteicams labi izprast izplatītos dizaina modeļus, lai labi pārzinātu zema līmeņa projektēšanu.

Dažādi dizaina modeļu veidi

Ir ļoti daudz dizaina modeļu veidu, apspriedīsim 4 dizaina modeļu veidus, kas tiek plaši izmantoti visā pasaulē:

• Rūpnīcas dizaina modelis
• Abstrakts rūpnīcas raksts
• Singleton raksts
• Novērotāja modelis

Ieteicams arī izpētīt tālāk norādītos 5 dizaina modeļus, jo tie ir mazāk pieprasīti, taču ieteicams apgūt pamata izpratni par dizaina modeļiem.

• Builder Pattern
• Atbildības ķēdes modelis
• Adaptera modelis
• Fasādes raksts
• Flyweight Pattern

4. UML diagramma

Tie ir divu veidu UML diagrammas:

1. Strukturālā UML diagramma: Šāda veida diagrammas pamatā nosaka, kā tiks strukturētas dažādas entītijas un objekti, un nosaka attiecības starp tiem. Tie ir noderīgi, lai attēlotu, kā komponenti izskatīsies attiecībā uz struktūru.
2. Uzvedības UML diagramma: Šāda veida diagrammas pamatā nosaka, kādas ir dažādās darbības, kuras tās atbalsta. Šeit dažādi uzvedības UML demonstrē dažādus uzvedības veidus

Padoms: Svarīgas UML diagrammas, ko izstrādātāji bieži izmanto, ir šādas:

• Klases diagramma no Strukturālā UML diagramma
• Secība , Izmantot gadījumu un Aktivitāte no uzvedības UML diagrammas.

5. CIETI principi

Tie ir 5 principu (noteikumu) kopumi, kas tiek stingri ievēroti atbilstoši sistēmas prasībām vai prasībām optimālai projektēšanai.

Lai rakstītu mērogojamu, elastīgu, uzturējamu un atkārtoti lietojamu kodu:

1. Vienas atbildības princips (SRP)
2. Atvērts-slēgts princips (OCP)
3. Liskova aizstāšanas princips (LSP)
4. Interfeisa segregācijas princips (ISP)
5. Atkarības inversijas princips (DIP)

Ir svarīgi paturēt prātā, ka SOLID principi ir tikai vadlīnijas, nevis stingri noteikumi, kas jāievēro. Galvenais ir panākt līdzsvaru starp šo principu ievērošanu un jūsu biznesa prasību īpašo vajadzību un ierobežojumu apsvēršanu.

java bloks