LLD tai matalan tason suunnittelu on komponenttitason suunnitteluprosessi, joka seuraa askel askeleelta tarkennusprosessia. LLD-syöte on HLD.

Mikä on Low Level Design tai LLDn

Tärkeitä aiheita matalan tason suunnittelulle (LLD)

• Mikä on Low-Level Design (LLD)?
• Miten LLD eroaa HLD:stä
• Kuinka muodostaa LLD HLD:stä?
• Tiekartta matalan tason suunnitteluun

Mikä on Low-Level Design (LLD)?

LLD eli Low-Level Design on vaihe ohjelmistokehitysprosessissa, jossa määritellään yksityiskohtaiset järjestelmäkomponentit ja niiden vuorovaikutukset. Se sisältää korkean tason suunnittelun muuntamisen yksityiskohtaisemmaksi suunnitelmaksi, jossa käsitellään tiettyjä algoritmeja, tietorakenteita ja rajapintoja. LLD toimii oppaana kehittäjille koodauksen aikana varmistaen järjestelmän toimivuuden tarkan ja tehokkaan toteutuksen. LLD kuvaa luokkakaavioita menetelmien ja luokkien välisten suhteiden ja ohjelman spesifikaatioiden avulla.

Muistaa: Matalan tason suunnittelu tunnetaan myös nimellä objektitason suunnittelu tai mikrotaso tai yksityiskohtainen suunnittelu .

Luokkakaavio LLD:ssä

Tässä kaaviossa luetellaan periaatteessa kaikki entiteetit, jotka voivat olla osa komponentteja. Luokkakaavioita tehdään, kun kehittäjän on helpompi muuntaa ne koodiksi.

Esimerkiksi:

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

Miten LLD eroaa HLD:stä

Kuten tutkittu, Korkean tason suunnittelu tai HLD on yleinen järjestelmäsuunnittelu, jossa teemme kompromisseja eri kehysten, komponenttien ja eri tietokantojen välillä ja valitsemme parhaan huomioon ottaen, mitä liiketoiminta tarvitsee ja miten järjestelmän pitäisi toimia, sekä toiminnallisilta että ei-toiminnallisilta puolilta. Tässä määrittelemme komponentit ja kuinka nämä komponentit kommunikoivat keskenään. Siksi tässä meitä häiritsevät yleiset asiat seuraavasti, emmekä välitä koodista.

1. Valikoima komponentteja, alustoja ja erilaisia ​​työkaluja.
2. Tietokannan suunnittelu.
3. Lyhyt kuvaus palveluiden ja moduulien välisistä suhteista.

Kuinka muodostaa LLD HLD:stä?

Kuten edellä on tutkittu, matalan tason suunnittelun (LLD) kehystyssyöte on HLD. Täällä LLD:ssä huolehdimme siitä, miltä komponenttimme näyttävät, eri entiteettien rakenteesta ja siitä, miten eri entiteetit kantavat vastuunsa (tuettua toimintaa). Tätä muuntamista varten käytämme Unified Modeling Language (UML) -kaaviot . Lisäämällä näihin kaavioihin käytämme OOPS periaatteet ja KIINTEÄT periaatteet suunnittelun aikana. Näin ollen käyttämällä näitä kolmea paradigmaa voimme muuntaa minkä tahansa HLD:n LLD:ksi, jotta se voidaan toteuttaa.

Tiekartta matalan tason suunnitteluun

Ymmärtääksemme LLD:n käsitteet todellisen koodin kanssa, meidän on ymmärrettävä, kuinka minkä tahansa matalan tason kaavio suunnitellaan, seuraavien vaiheiden avulla:

1. Olio-periaatteet

Käyttäjävaatimus käsitellään OOPS-ohjelmoinnin konseptien avulla. Tästä syystä on suositeltavaa ottaa vahva ote OOPS-konsepteihin ennen kuin lähdetään eteenpäin minkään matalan tason järjestelmän suunnittelussa. Olio-ohjelmointikonseptin 4 pilaria ovat pakollisia aloittaaksesi matalan tason suunnittelun oppiminen, ja ohjelmoijan tulee olla erittäin perehtynyt näihin neljään pilariin, nimittäin seuraavasti:

1. Perintö
2. kapselointi
3. polymorfismi
4. abstraktio

Polymorfismissa meidän tulisi olla selkeät käännösajan ja ajonaikaisen polymorfismin kanssa. Ohjelmoijien tulee olla täysin selvillä OOPS-konsepteista aina luokkiin ja objekteihin saakka, koska OOPS on perusta, jolle matalatasoisuus missä tahansa järjestelmässä perustuu. Matalan tason suunnittelu on 'erittäin subjektiivista', koska meidän on käytettävä näitä käsitteitä optimaalisesti koodattaessa rakentaaksemme matalan tason järjestelmän toteuttamalla koodausohjelmistokokonaisuuksia (luokat, funktiot, moduulit jne.)

2. Analysointi- ja suunnitteluprosessi

Se on analysointivaihe, joka on ensimmäinen vaiheemme, jossa muutetaan tosielämän ongelmat objektimaailman ongelmiksi käyttämällä OOPS-konsepteja ja SOLID-periaatteita.

3. Suunnittelumallit

Nyt yllä olevan olio-ongelmamme toteutus toteutetaan suunnittelumallien avulla. Suunnittelumallit ovat uudelleenkäytettäviä ratkaisuja yleisiin ohjelmistosuunnittelun ongelmiin. Ne tarjoavat jäsennellyn lähestymistavan suunnitteluun vangitsemalla parhaat käytännöt ja todistetut ratkaisut, mikä helpottaa skaalautuvien, ylläpidettävien ja tehokkaiden ohjelmistojen kehittämistä. Suunnittelumallit auttavat virtaviivaistamaan kehitysprosessia, edistämään koodin uudelleenkäyttöä ja parantamaan ohjelmistojärjestelmien yleistä laatua.

Jokainen kuvio kuvaa ongelmaa, joka toistuu ympäristössä yhä useammin, ja niiden ratkaisuja voidaan soveltaa toistuvasti ilman redundanssia.

Miksi suunnittelumalleja tarvitaan?

Näitä ongelmia on ilmennyt yhä uudelleen ja uudelleen, minkä mukaisesti nämä ratkaisut on laadittu. Ohjelmoinnin asiantuntijasuunnittelijat ovat kohdanneet ja ratkaisseet nämä ongelmat, ja ratkaisut ovat kestäviä ja säästävät paljon aikaa ja energiaa. Siksi ohjelmistomaailman monimutkaiset ja klassiset ongelmat ratkaistaan ​​testatuilla ratkaisuilla.

Kärki: On erittäin suositeltavaa, että ymmärrät hyvin yleiset suunnittelumallit, jotta voit hallita matalan tason suunnittelua.

merkkijono

Erilaiset suunnittelumallit

Suunnittelukuvioita on laajalti monenlaisia. Keskustelkaamme neljästä suunnittelumallityypistä, joita käytetään laajasti maailmanlaajuisesti:

• Tehdassuunnittelukuvio
• Abstrakti tehdaskuvio
• Singleton malli
• Tarkkailijamalli

On myös suositeltavaa tutkia alla olevat 5 suunnittelumallia, koska niitä tarvitaan vähemmän, mutta on suositeltavaa oppia suunnittelumallien perusymmärrys.

• Rakennusmalli
• Vastuuketjun malli
• Sovittimen kuvio
• Julkisivukuvio
• Flyweight malli

4. UML-kaavio

Ne ovat kahdenlaisia ​​UML-kaavioita:

1. Rakenteellinen UML-kaavio: Tämäntyyppiset kaaviot määrittelevät pohjimmiltaan kuinka eri entiteetit ja objektit rakennetaan, ja määrittelevät niiden välisen suhteen. Ne auttavat esittämään, kuinka komponentit näyttävät rakenteen suhteen.
2. Käyttäytymisen UML-kaavio: Tämäntyyppiset kaaviot määrittelevät pohjimmiltaan ne toiminnot, joita ne tukevat. Tässä eri käyttäytymis-UML esittelee erilaisia ​​käyttäytymismalleja

Kärki: Tärkeitä kehittäjien usein käyttämiä UML-kaavioita ovat seuraavat:

• Luokkakaavio alkaen Rakenteellinen UML-kaavio
• Järjestys , Käyttötapaus ja Toiminta Behavioral UML -kaaviosta.

5. KIINTEÄT periaatteet

Nämä ovat 5 periaatteen (säännön) sarjaa, joita noudatetaan tiukasti järjestelmän vaatimusten tai optimaalisen suunnittelun vaatimusten mukaisesti.

Skaalautuvan, joustavan, ylläpidettävän ja uudelleenkäytettävän koodin kirjoittaminen:

1. Yhden vastuun periaate (SRP)
2. Avoin-kiinni -periaate (OCP)
3. Liskovin korvausperiaate (LSP)
4. Interface Segregation Principle (ISP)
5. Riippuvuuden inversioperiaate (DIP)

On tärkeää pitää mielessä, että SOLID-periaatteet ovat vain ohjeita, eivät tiukkoja sääntöjä, joita on noudatettava. Tärkeintä on löytää tasapaino näiden periaatteiden noudattamisen ja yrityksesi erityistarpeiden ja rajoitusten huomioimisen välillä.