Üsna sageli kohtan arendajaid, kes pole SOLIDi põhimõtetest kuulnud (me . - Transl.) või objektorienteeritud programmeerimine (OOP), või kuulnud, kuid ei kasuta neid praktikas. Selles artiklis kirjeldatakse OOP põhimõtete eeliseid, mis aitavad arendajat tema igapäevatöös. Mõned neist on hästi tuntud, teised mitte nii palju, nii et artikkel on kasulik nii algajatele kui ka juba kogenud programmeerijatele.
Tuletame meelde: kõigile "Habr" lugejatele - allahindlus 10 000 rubla, kui registreerute mis tahes Skillboxi kursusele, kasutades sooduskoodi "Habr".
Skillbox soovitab: Hariv veebikursus .
KUIV (Ära korda ennast)
Üsna lihtne põhimõte, mille olemus on nimest selge: "Ära korda ennast." Programmeerija jaoks tähendab see vajadust vältida dubleerivat koodi, aga ka võimalust kasutada töös abstraktsiooni.
Kui koodis on kaks korduvat jaotist, tuleks need ühendada üheks meetodiks. Kui kõvakoodiga väärtust kasutatakse rohkem kui üks kord, tasub see teisendada avalikuks konstandiks.
See on vajalik koodi lihtsustamiseks ja hooldamise hõlbustamiseks, mis on OOP põhiülesanne. Te ei tohiks ka ametiühingut kuritarvitada, kuna sama kood ei läbi nii OrderId kui ka SSN-i kontrolli.
Muuda kapseldamist
Enamiku ettevõtete tarkvaratooted arenevad pidevalt. See tähendab, et koodi on vaja muuta, seda tuleb hoida. Kapseldamisega saate oma elu lihtsamaks muuta. See võimaldab teil olemasolevat koodibaasi tõhusamalt testida ja säilitada. .
Kui kirjutate Java keeles, siis .
Avatuse / läheduse põhimõte
See põhimõte jääb kergesti meelde, lugedes järgmist väidet: "Tarkvara olemid (klassid, moodulid, funktsioonid jne) peaksid olema laiendamiseks avatud, kuid muutmiseks suletud." Praktikas tähendab see, et nad saavad lubada oma käitumist muuta ilma lähtekoodi muutmata.
Põhimõte on oluline, kui lähtekoodi muudatused nõuavad muudatusi, üksuse testimist ja muid protseduure. Kood, mis järgib avatud/suletud põhimõtet, ei muutu pikendamisel, seega on sellega palju vähem probleeme.
Siin on näide koodist, mis seda põhimõtet rikub.
Kui peate selles midagi muutma, võtab see palju aega, kuna peate muutma kõiki koodi osi, millel on soovitud fragmendiga seos.
Avatus-sulgus on muide üks SOLIDi põhimõtetest.
Ühtse vastutuse põhimõte (SRP)
Teine põhimõte SOLID komplektist. Seal öeldakse, et "klassivahetuseni on ainult üks põhjus." Klassil on ainult üks ülesanne. Sellel võib olla mitu meetodit, kuid igaüks neist on mõeldud ainult ühise probleemi lahendamiseks. Kõik meetodid ja omadused peaksid ainult seda teenima.
Selle põhimõtte väärtus seisneb selles, et see lõdvendab seost üksiku tarkvara ja koodi vahel. Rohkem kui ühe funktsiooni lisamine klassi loob seose kahe funktsiooni vahel. Seega, kui muudate ühte neist, on suurepärane võimalus rikkuda teine, mis on seotud esimesega. Ja see tähendab testimistsüklite suurendamist, et kõik probleemid eelnevalt tuvastada.
Sõltuvuste inversiooni põhimõte (DIP)
Ülaltoodud on koodinäide, kus AppManager sõltub EventLogWriterist, mis omakorda on tihedalt seotud AppManageriga. Kui vajate teatise kuvamiseks teistsugust viisi, olgu selleks tõuke, SMS või e-kiri, peate muutma AppManageri klassi.
Probleemi saab lahendada DIP-iga. Seega taotleme AppManageri asemel EventLogWriterit, mis sisestatakse raamistiku abil.
DIP võimaldab sõltuvusmoodulit muutes üksikuid mooduleid lihtsalt teistega asendada. See võimaldab muuta üht moodulit teisi mõjutamata.
Pärimise asemel koosseis
Kaks peamist viisi koodi taaskasutamiseks on pärimine ja koostis, millest igaühel on oma eelised ja puudused. Tavaliselt eelistatakse teist, kuna see on paindlikum.
Kompositsioon annab teile võimaluse muuta klassi käitumist käitusajal, määrates selle atribuudid. Liideste realiseerimisel kasutatakse polümorfismi, mis annab paindlikuma teostuse.
Isegi "Tõhus Java" Joshua Bloch soovitab eelistada kompositsiooni pärimisele.
Barbara Liskovi asenduspõhimõte (LSP)
Teine põhimõte SOLID tööriistakomplektist. Selles öeldakse, et alamtüübid peavad olema supertüübi jaoks asendatavad. See tähendab, et meetodid ja funktsioonid, mis töötavad superklassiga, peaksid suutma töötada ilma probleemideta selle alamklassidega.
LSP on seotud nii ühtse vastutuse põhimõtte kui ka vastutuse lahususe põhimõttega. Kui klass pakub rohkem funktsioone kui alamklass, siis viimane ei toeta mõnda funktsionaalsust, rikkudes seda põhimõtet.
Siin on kooditükk, mis on LSP-ga vastuolus.
Pindala (Ristküliku r) meetod arvutab ristküliku pindala. Programm jookseb pärast ruudu käivitamist kokku, kuna ruut ei ole siin ristkülik. LSP põhimõtte kohaselt peaksid funktsioonid, mis kasutavad viiteid baasklassidele, saama kasutada tuletatud klasside objekte ilma täiendavate juhisteta.
Selle põhimõtte, mis on alatüübi spetsiifiline määratlus, pakkus välja Barbara Liskov 1987. aasta konverentsi peaettekandes "Andmete abstraktsioon ja hierarhia" – sellest ka selle nimi.
Liidese eraldamise põhimõte (ISP)
Veel üks SOLIIDE põhimõte. Tema sõnul ei tohiks kasutusele võtta liidest, mida ei kasutata. Selle põhimõtte järgimine aitab süsteemil tööloogikas muudatusi tehes jääda paindlikuks ja ümberkujundatavaks.
Enamasti tekib selline olukord siis, kui liides sisaldab korraga mitut funktsiooni ja klient vajab neist ainult ühte.
Kuna liidese kirjutamine on keeruline ülesanne, on pärast töö lõpetamist selle muutmine ilma midagi purustamata probleemiks.
ISP printsiibi eelis Javas seisneb selles, et kõik meetodid tuleb enne realiseerida ja alles siis saavad neid klassid kasutada. Seetõttu võimaldab põhimõte meetodite arvu vähendada.
Programmeerimine liidese, mitte juurutamise jaoks
Siin on nimest kõik selge. Selle põhimõtte rakendamine viib paindliku koodini, mis võib töötada mis tahes uue liidese rakendamisega.
Muutujate, tagastustüüpide või meetodi argumendi tüübi jaoks peaksite kasutama liidese tüüpi. Näiteks on SuperClassi kasutamine alamklassi asemel.
See on:
Nimekirja numbrid= getNumbers();
Kuid mitte:
ArrayList numbrid = getNumbers();
Siin on ülalöeldu praktiline teostus.
Delegeerimise põhimõte
Levinud näide on Java meetodid equals () ja hashCode (). Kui on vaja võrrelda kahte objekti, delegeeritakse see toiming kliendiklassi asemel sobivale klassile.
Põhimõtte eeliseks on see, et puudub koodi dubleerimine ja käitumist on suhteliselt lihtne muuta. See kehtib ka ürituste delegeerimise kohta.
Kõik need põhimõtted võimaldavad teil kirjutada paindlikumat, ilusamat ja usaldusväärsemat koodi, millel on kõrge sidusus ja madal side. Muidugi on teooria hea, aga selleks, et arendaja omandatud teadmisi päriselt kasutama hakkaks, on vaja praktikat. Järgmine samm pärast OOP põhimõtete omandamist võib olla levinud tarkvaraarenduse probleemide lahendamiseks mõeldud disainimustrite uurimine.
Skillbox soovitab:
- Praktiline kursus .
- Rakendatud veebikursus .
- Kaheaastane praktiline kursus .
Allikas: www.habr.com