Ohjelmistokehityksessä mm. Olio-suuntautunut suunnittelu Sillä on ratkaiseva rooli joustavan, skaalautuvan, ylläpidettävän ja uudelleenkäytettävän koodin kirjoittamisessa. OOD:n käyttämisessä on monia etuja, mutta jokaisen kehittäjän tulisi tietää myös SOLID-periaate hyvään oliosuuntautuneeseen suunnitteluun ohjelmoinnissa. SOLID-periaatteen esitteli Robert C. Martin, joka tunnetaan myös nimellä Uncle Bob, ja se on ohjelmoinnin koodausstandardi. Tämä periaate on lyhenne viidestä alla esitetystä periaatteesta:

• Yhden vastuun periaate (SRP)
• Avoin/suljettu periaate
• Liskovin korvausperiaate (LSP)
• Interface Segregation Principle (ISP)
• Riippuvuuden inversioperiaate (DIP)

SOLID-periaate auttaa vähentämään tiivistä kytkentää. Tiukka kytkentä tarkoittaa, että luokkaryhmät ovat erittäin riippuvaisia ​​toisistaan, mitä sinun tulee välttää koodissasi.

• Tiukan kytkennän vastakohta on löysä kytkentä ja koodiasi pidetään hyvänä koodina, kun siinä on löyhästi kytkettyjä luokkia.
• Löyhästi kytketyt luokat minimoivat koodisi muutokset, auttavat tekemään koodista uudelleenkäytettävyyttä, ylläpidettävää, joustavampaa ja vakaampaa. Keskustellaan nyt näistä periaatteista yksitellen…

1. Yhteisen vastuun periaate

Tämä periaate sanoo sen Luokassa saa olla vain yksi syy muuttua mikä tarkoittaa, että jokaisella luokalla tulisi olla yksi vastuu tai yksi työ tai yksi tarkoitus. Toisin sanoen luokalla pitäisi olla vain yksi tehtävä tai tarkoitus ohjelmistojärjestelmässä.

merkkijono etsi c++

Ymmärretään yhden vastuun periaate esimerkin avulla:

Kuvittele leipuri, joka on vastuussa leivän leipomisesta. Leipurin tehtävänä on keskittyä leivän leivontatehtävään ja varmistaa, että leipä on laadukasta, oikein paistettua ja leipomon standardien mukaista.

• Jos leipuri on kuitenkin vastuussa myös varaston hallinnasta, tarvikkeiden tilaamisesta, asiakkaiden palvelemisesta ja leipomon siivouksesta, tämä rikkoisi SRP:tä.
• Jokainen näistä tehtävistä edustaa erillistä vastuuta, ja niitä yhdistämällä leipurin keskittyminen ja tehokkuus leivän leivonnassa voivat vaarantua.
• SRP:n noudattamiseksi leipomo voisi antaa eri rooleja eri henkilöille tai ryhmille. Esimerkiksi erillinen henkilö tai tiimi voi olla vastuussa varaston hallinnasta, toinen tarvikkeiden tilaamisesta, toinen asiakkaiden palvelemisesta ja toinen leipomon siivouksesta.

2. Avoin/suljettu periaate

Tämä periaate sanoo sen Ohjelmistokokonaisuuksien (luokat, moduulit, funktiot jne.) tulee olla avoimia laajentamista varten, mutta suljettuja muokkausta varten mikä tarkoittaa, että sinun pitäisi pystyä laajentamaan luokan käyttäytymistä muuttamatta sitä.

Ymmärretään avoin/suljettu periaate esimerkin avulla:

Kuvittele, että sinulla on luokka nimeltäPaymentProcessor>joka käsittelee verkkokaupan maksuja. Aluksi,PaymentProcessor>luokka tukee vain maksujen käsittelyä luottokorteilla. Haluat kuitenkin laajentaa sen toimintoja tukemaan myös maksujen käsittelyä PayPalin kautta.

Sen sijaan, että muuttaisit olemassa olevaaPaymentProcessor>luokkaan lisätäksesi PayPal-tuen, voit luoda uuden luokan nimeltäPayPalPaymentProcessor>joka laajentaaPaymentProcessor>luokkaa. Tällä tavalla,PaymentProcessor>luokka pysyy suljettuna muokkauksille, mutta avoinna laajennukselle noudattaen Open-Closed -periaatetta

101 miljoonaa

3. Liskovin korvausperiaate

Periaatteen esitteli Barbara Liskov vuonna 1987 ja tämän periaatteen mukaisesti Johdettujen tai alaluokkien on voitava korvata perus- tai yläluokkansa . Tämä periaate varmistaa, että jokainen luokka, joka on yläluokan lapsi, on käyttökelpoinen vanhemman sijaan ilman odottamatonta käyttäytymistä.

faktoriaali javassa

Ymmärretään Liskovin korvausperiaate esimerkin avulla:

Yksi tämän periaatteen klassisista esimerkeistä on suorakulmio, jossa on neljä sivua. Suorakulmion korkeus voi olla mikä tahansa arvo ja leveys mikä tahansa arvo. Neliö on suorakulmio, jolla on sama leveys ja korkeus. Joten voidaan sanoa, että voimme laajentaa suorakulmioluokan ominaisuudet neliöluokkaan.

Tätä varten sinun on vaihdettava alaluokka (neliö) yläluokkaan (suorakulmio), jotta se sopii neliön määritelmään, jolla on neljä yhtä suurta sivua, mutta johdettu luokka ei vaikuta yläluokan käyttäytymiseen, joten jos teet niin että se rikkoo Liskovin substituutioperiaatetta.

4. Liitäntöjen erotteluperiaate

Tämä periaate on ensimmäinen periaate, jota sovelletaan liitäntöihin SOLIDin luokkien sijaan, ja se on samanlainen kuin yhden vastuun periaate. Siinä todetaan Älä pakota ketään asiakasta toteuttamaan käyttöliittymää, joka ei ole hänelle merkityksellinen . Tässä päätavoitteesi on keskittyä välttämään rasvaa käyttöliittymää ja suosimaan monia pieniä asiakaskohtaisia ​​rajapintoja. Sinun tulisi suosia useita asiakasrajapintoja yhden yleisen käyttöliittymän sijaan, ja jokaisella rajapinnalla tulisi olla erityinen vastuu.

Ymmärretään käyttöliittymän erotteluperiaate esimerkin avulla:

matriisiluettelo java

Oletetaan, että jos astut ravintolaan ja olet puhdas kasvissyöjä. Tämän ravintolan tarjoilija antoi sinulle valikkokortin, joka sisältää kasvisruokia, ei-kasvistuotteita, juomia ja makeisia.

• Tässä tapauksessa sinulla tulee olla asiakkaana ruokalista, joka sisältää vain kasvisruokia, ei kaikkea, mitä et syö ruoassasi. Tässä valikon tulisi olla erilainen erityyppisille asiakkaille.
• Yhteinen tai yleinen valikkokortti kaikille voidaan jakaa useisiin kortteihin yhden sijasta. Tämän periaatteen käyttäminen auttaa vähentämään sivuvaikutuksia ja tarvittavien muutosten tiheyttä.

5. Riippuvuuden inversioperiaate

Dependency Inversion Principle (DIP) on olio-suunnittelun periaate, joka sanoo tämän Korkean tason moduulit eivät saa olla riippuvaisia ​​matalan tason moduuleista. Molempien pitäisi riippua abstraktioista . Lisäksi abstraktion ei pitäisi olla riippuvainen yksityiskohdista. Yksityiskohtien pitäisi riippua abstraktioista.

• Yksinkertaisemmin sanottuna DIP ehdottaa, että luokkien tulisi luottaa abstrakteihin (esim. rajapintoihin tai abstrakteihin luokkiin) konkreettisten toteutusten sijaan.
• Tämä mahdollistaa joustavamman ja irrotetun koodin, mikä helpottaa toteutusten vaihtamista vaikuttamatta muihin koodikannan osiin.

Ymmärretään riippuvuuden inversioperiaate esimerkin avulla:

Ohjelmistokehitystiimissä kehittäjät ovat riippuvaisia ​​abstraktista versionhallintajärjestelmästä (esim. Git) koodikannan muutosten hallinnassa ja seuraamisessa. Ne eivät riipu erityisistä yksityiskohdista siitä, kuinka Git toimii sisäisesti.

Näin kehittäjät voivat keskittyä koodin kirjoittamiseen ilman, että heidän tarvitsee ymmärtää versionhallinnan toteutuksen monimutkaisuutta.