Kuriant programinę įrangą, Objektinis dizainas vaidina lemiamą vaidmenį rašant lankstų, keičiamo dydžio, prižiūrimą ir pakartotinai naudojamą kodą. OOD naudojimas turi tiek daug privalumų, tačiau kiekvienas kūrėjas taip pat turėtų žinoti SOLID principą, kad būtų galima programuoti į objektą. SOLID principą pristatė Robertas C. Martinas, dar žinomas kaip dėdė Bobas, ir tai yra programavimo kodavimo standartas. Šis principas yra penkių toliau pateiktų principų akronimas:

• Vienos atsakomybės principas (SRP)
• Atviro/uždarymo principas
• Liskovo pakeitimo principas (LSP)
• Sąsajos atskyrimo principas (IPT)
• Priklausomybės inversijos principas (DIP)

SOLID principas padeda sumažinti sandarų sujungimą. Tvirtas sujungimas reiškia, kad klasių grupė yra labai priklausoma viena nuo kitos, ko turėtumėte vengti savo kode.

• Priešinga glaudžiam sujungimui yra laisvas sujungimas, o jūsų kodas laikomas geru kodu, kai jis turi laisvai susietas klases.
• Laisvai susietos klasės sumažina kodo pakeitimus, padeda kodą padaryti daugkartinį, jį prižiūrimą, lankstesnį ir stabilesnį. Dabar aptarkime šiuos principus po vieną...

1. Vienos atsakomybės principas

Šis principas teigia, kad Klasė turėtų turėti tik vieną priežastį keistis o tai reiškia, kad kiekviena klasė turėtų turėti vieną atsakomybę, vieną darbą arba vieną tikslą. Kitaip tariant, klasė programinės įrangos sistemoje turėtų turėti tik vieną darbą arba tikslą.

visa sumatoriaus grandinė

Supraskime vienos atsakomybės principą naudodami pavyzdį:

Įsivaizduokite kepėją, kuri yra atsakinga už duonos kepimą. Kepėjo pareiga yra sutelkti dėmesį į duonos kepimo užduotį, užtikrinti, kad duona būtų kokybiška, tinkamai iškepta ir atitiktų kepyklos standartus.

• Tačiau jei kepėjas taip pat yra atsakingas už atsargų tvarkymą, prekių užsakymą, klientų aptarnavimą ir kepyklos valymą, tai pažeistų SRP.
• Kiekviena iš šių užduočių reiškia atskirą atsakomybę, o jas derinant gali būti pažeistas kepėjo dėmesys ir duonos kepimo efektyvumas.
• Siekdama laikytis SRP, kepykla gali skirti skirtingus vaidmenis skirtingiems asmenims ar komandoms. Pavyzdžiui, gali būti atskiras asmuo ar komanda, atsakinga už atsargų tvarkymą, kitas – už prekių užsakymą, kitas – klientų aptarnavimą, kitas – už kepyklos valymą.

2. Atviro/uždarymo principas

Šis principas teigia, kad Programinės įrangos objektai (klasės, moduliai, funkcijos ir kt.) turėtų būti atviri plėtrai, bet uždaryti modifikavimui o tai reiškia, kad turėtumėte turėti galimybę išplėsti klasės elgesį jo nekeisdami.

Supraskime atvirą / uždarą principą naudodami pavyzdį:

Įsivaizduokite, kad turite klasę pavadinimuPaymentProcessor>kuri apdoroja mokėjimus už internetinę parduotuvę. Iš pradžių,PaymentProcessor>klasė palaiko tik mokėjimų apdorojimą kredito kortelėmis. Tačiau norite išplėsti jo funkcijas ir palaikyti mokėjimų apdorojimą naudojant PayPal.

Arduino duomenų perdavimo sparta

Užuot modifikavęs esamąPaymentProcessor>klasėje, kad pridėtumėte „PayPal“ palaikymą, galite sukurti naują klasę pavadinimuPayPalPaymentProcessor>kuris pratęsiaPaymentProcessor>klasė. Tokiu būdu,PaymentProcessor>klasė lieka uždaryta modifikavimui, bet atvira pratęsimui, laikantis atviro-uždarymo principo

3. Liskovo pakeitimo principas

Principą Barbara Liskov įvedė 1987 m. ir pagal šį principą Išvestinės arba antrinės klasės turi būti pakeistos pagrindinėmis arba pagrindinėmis klasėmis . Šis principas užtikrina, kad bet kuri klasė, kuri yra pagrindinės klasės antrinė klasė, turėtų būti naudojama vietoje savo pirminės klasės be jokio netikėto elgesio.

Supraskime Liskovo pakeitimo principą naudodami pavyzdį:

Vienas iš klasikinių šio principo pavyzdžių yra stačiakampis, turintis keturias puses. Stačiakampio aukštis gali būti bet kokia vertė, o plotis gali būti bet kokia vertė. Kvadratas yra vienodo pločio ir aukščio stačiakampis. Taigi galime pasakyti, kad galime išplėsti stačiakampio klasės savybes į kvadrato klasę.

Norėdami tai padaryti, turite pakeisti antrinę (kvadrato) klasę su pirmine (stačiakampio) klase, kad ji atitiktų kvadrato, turinčio keturias lygias kraštines, apibrėžimą, tačiau išvestinė klasė neturi įtakos pagrindinės klasės elgsenai, taigi, jei tai padarysite kad tai pažeis Liskovo pakeitimo principą.

dvejetainės paieškos algoritmas

4. Sąsajos atskyrimo principas

Šis principas yra pirmasis principas, taikomas sąsajoms, o ne klasėms SOLID ir panašus į vienos atsakomybės principą. Jame teigiama, kad neverskite jokio kliento diegti jam nereikšmingos sąsajos . Čia jūsų pagrindinis tikslas yra vengti riebios sąsajos ir teikti pirmenybę daugeliui mažų, specifinių klientų sąsajų. Turėtumėte teikti pirmenybę daugeliui klientų sąsajų, o ne vienai bendrai sąsajai, o kiekviena sąsaja turėtų būti atsakinga.

Supraskime sąsajos atskyrimo principą naudodami pavyzdį:

Tarkime, jei įeinate į restoraną ir esate grynas vegetaras. To restorano padavėjas davė jums meniu kortelę, kurioje yra vegetariški, ne vegetariški produktai, gėrimai ir saldumynai.

• Tokiu atveju, kaip klientas, turėtumėte turėti meniu kortelę, kurioje būtų tik vegetariški produktai, o ne viskas, ko nevalgote savo maiste. Čia meniu turėtų būti skirtingas skirtingų tipų klientams.
• Visiems skirtą bendrą arba bendrą meniu kortelę galima padalyti į kelias, o ne į vieną. Šio principo naudojimas padeda sumažinti šalutinį poveikį ir būtinų pakeitimų dažnumą.

5. Priklausomybės inversijos principas

Priklausomybės inversijos principas (DIP) yra objektinio dizaino principas, kuriame teigiama Aukšto lygio moduliai neturėtų priklausyti nuo žemo lygio modulių. Abu turėtų priklausyti nuo abstrakcijų . Be to, abstrakcijos neturėtų priklausyti nuo detalių. Išsami informacija turėtų priklausyti nuo abstrakcijų.

• Paprasčiau tariant, DIP siūlo, kad klasės turėtų remtis abstrakcijomis (pvz., sąsajomis arba abstrakčiomis klasėmis), o ne konkrečiais įgyvendinimais.
• Tai leidžia naudoti lankstesnį ir atsietą kodą, todėl lengviau pakeisti diegimą nepažeidžiant kitų kodų bazės dalių.

Supraskime priklausomybės inversijos principą naudodami pavyzdį:

sutrumpinti ir ištrinti skirtumą

Programinės įrangos kūrimo komandoje kūrėjai priklauso nuo abstrakčios versijų valdymo sistemos (pvz., Git), kad galėtų valdyti ir stebėti kodų bazės pakeitimus. Jie nepriklauso nuo konkrečių detalių, kaip „Git“ veikia viduje.

Tai leidžia kūrėjams sutelkti dėmesį į kodo rašymą, nesuvokiant versijos valdymo įgyvendinimo sudėtingumo.