10 objektorienteeritud programmeerimise põhimõtet, millest iga arendaja peaks teadma

Ma sageli kohtan arendajaid, kes ei ole kuulnud SOLIDi põhimõtetest (me rääkisime neist siin põhjalikult. — Toim.) või objektorienteeritud programmeerimisest (OOP), või on kuulnud, kuid ei kasuta neid praktikas. Selles artiklis käsitletakse OOP põhimõtete eeliseid, mis aitavad arendajal tema igapäevases töös. Mõned neist on hästi tuntud, teised mitte nii väga, seega on artikkel kasulik nii algajatele kui ka kogenenud programmeerijatele.

Tuletame meelde: kõikidele "Habbra" lugejatele — 10 000 rubla allahindlus, kui registreerite end Skillboxi kursusele promokoodiga "Habr".

Skillbox soovitab: Haridusalane veebikursus Java arendaja.

DRY (Ära Korda End)

Suhteliselt lihtne põhimõte, mille olemus on selge juba nimest: "Ära korda end". Programmeerija jaoks tähendab see vajadust vältida dubleeritud koodi ja võimalust kasutada töös abstraktsioone.

Kui koodis on kaks korduvat osa, tuleks need liita üheks meetodiks. Kui kindel väärtus on kasutusel rohkem kui üks kord, tasub see muundada avalikuks konstantsiks.

See on vajalik, et lihtsustada koodi ja teha selle hooldamine kergemaks, mis on OOP põhiline eesmärk. Liialdamine liitmisega ei ole ka soovitatav, kuna sama kood ei saa samaaegselt toimida nii OrderId kui ka SSN-iga.

Muutuste kapseldamine

Enamiku ettevõtete tarkvaraproduktid arenevad pidevalt. See tähendab, et koodi tuleb muuta, seda peab hooldama. Oma elu lihtsustamiseks saab kasutada kapseldamist. See võimaldab tõhusamalt testida ja hooldada olemasolevat koodibaasi. Siin on üks näide.

Kui kirjutate Java keeles, siis määrake privaatsetele meetoditele ja muutujatele vaikimisi private.

Avatuse/suletuse põhimõte

Seda põhimõtet on lihtne meeles pidada, lugedes järgmist väidet: "Tarkvarased üksused (klassid, moodulid, funktsioonid jne) peaksid olema avatud laiendamiseks, kuid suletud muutmiseks". Praktikas tähendab see, et nad võivad võimaldada oma käitumise muutmist ilma algkoodi muutmiseta.

Põhimõte on oluline, kui algkodi muutmine nõuab selle ülevaatamist, moodulitestimist ja muid menetlusi. Kood, mis järgib avatuse/suletuse põhimõtet, ei muutu laiendamisel, seega on selle kasutamisel märgatavalt vähem probleeme.

Siin on kood, mis rikub seda põhimõtet.

Kui on vaja midagi muuta, võtab see palju aega, kuna tuleb muuta kõiki koodilõike, mis on seotud vajaliku fragmentiga.

Muide, avatus-sulgumine on üks SOLID-i põhimõtteid.

Üksikule vastutusele vastav põhimõte (SRP)

Veel üks põhimõte SOLID-i kogumist. See ütleb, et "klassil on vaid üks põhjus, miks seda muuta". Klass täidab ainult ühte ülesannet. Tal võivad olla mitmed meetodid, kuid igaüht kasutatakse üksnes üldise ülesande lahendamiseks. Kõik meetodid ja omadused peavad teenima ainult seda.

Selle põhimõtte väärtus seisneb selles, et see nõrgendab seoseid eraldi tarkvarakomponentide ja koodi vahel. Kui klassis saada rohkem kui üks funktsionaalsus, tekitab see seose kahe funktsiooni vahel. Nii et kui üht neist muuta, on suur tõenäosus, et rikkuda teist, mis on esimesele seotud. See tähendab testimistsüklite arvu suurenemist, et tuvastada kõik probleemid eelnevalt.

Sõltuvuste pööramise põhimõte (DIP)

Ülaltoodud koodinäide, kus AppManager sõltub EventLogWriter'ist, mis on omakorda tihedalt seotud AppManageriga. Kui on vaja teist viisi teavitamiseks, olgu see siis push, SMS või e-mail, tuleb muuta klassi AppManager.

Probleemi saab lahendada DIP abil. Seega, selle asemel, et küsida AppManagerilt, küsime EventLogWriter'ilt, mis viiakse ellu raamistikuga.

DIP võimaldab hõlpsasti asendada üksikuid mooduleid teistega, muutes sõltuvuse moodulit. See võimaldab muuta ühte moodulit, mõjutamata teisi.

Koostamine, mitte pärimine

Peamised viisid koodi taaskasutamiseks on pärimine ja koostamine, kummalgi on oma eelised ja puudused. Tavaliselt eelistatakse teist, kuna see on paindlikum.

Koostamine võimaldab klassi käitumist muuta käitamise ajal, seadistades selle omadusi. Interfaiside rakendamisel kasutatakse polümorfismi, mis annab paindlikuma rakenduse.

Isegi Joshua Bloch "Effective Java"-s soovitab eelistada koostamist mitte pärimist.

Barbara Liskovi asenduspõhimõte (LSP)

Veel üks SOLID tööriistade põhimõte. See ütleb, et alamtüübid peavad olema asendatavad supertüübiga. See tähendab, et meetodid ja funktsioonid, mis töötavad superklassiga, peavad saama probleemideta töötada ka selle alams klassidega.

LSP on seotud nii ühe vastutuse põhimõtte kui ka vastutuse jagamise põhimõttega. Kui klass pakub rohkem funktsionaalsust kui alams klass, siis viimane ei toeta mõningaid funktsioone, rikkudes sellega seda põhimõtet.

Siin on koodilõik, mis rikub LSP-d.

Meetod area(Rectangle r) arvutab nelinurga pindala. Programm ebaõnnestub pärast Square'i täitmist, kuna Square ei ole siin nelinurk. Vastavalt LSP põhimõttele peavad funktsioonid, mis kasutavad põhiklassi viiteid, olema võimelised kasutama ka tuletatud klasside objekte ilma lisainstruktsioonideta.

See põhimõte, mis on alamtüübi spetsiifiline määratlemine, pakkus välja Barbara Liskov 1987. aastal konverentsil, kus tema peaettekanne oli 'Andmete abstraktsioon ja hierarhia' — seetõttu see nime saanud.

Liidese jagamise põhimõte (ISP)

Jälle üks SOLID põhimõte. Selle kohaselt ei tohi liidest, mida ei kasutata, rakendada. Selle põhimõtte järgimine aitab süsteemil jääda paindlikuks ja reguleeritavaks, kui muudetakse tööloogikat.

Seda olukorda esineb kõige sagedamini, kui liides sisaldab mitut funktsionaalsust, kusjuures kliendile on vajalik ainult üks neist.

Kuna liidese kirjutamine on keeruline ülesanne, on pärast töö lõpetamist sellele muutmine, rikkumata midagi, probleem.

ISP põhimõtte eelis Java-s on see, et esmalt peate rakendama kõik meetodid ja alles siis saavad neid kasutada klassid. Seetõttu annab põhimõte võimaluse vähendada meetodite arvu.

Programmeerimine liidese, mitte rakenduse järgi

Siit on kõik arusaadav nime järgi. Selle põhimõtte rakendamine toob kaasa paindliku koodi loomise, mis suudab töötada igasuguste uute liidese rakendustega.

Tuleb kasutada liidese tüüpi muutujaid, tagastatavaid tüüpe või meetodi argumentide tüüpe. Näide — kasutamine SuperClass'i asemel SubClass'i.

Kusjuures:

List numbers= getNumbers();

Ja mitte:

ArrayList numbers = getNumbers();

Siin on praktiline rakendus sellest, millest eelnevalt räägiti.

Delegatsiooni põhimõte

Levinud näide on meetodid equals() ja hashCode() Java-s. Kui tuleb võrrelda kaht objekti, delegeeritakse see toiming vastavale klassile, mitte kliendile.

Põhimõtte eelisteks on koodi dubleerimise vältimine ja suhteliselt lihtne käitumise muutmine. Samuti on see rakendatav sündmuste delegeerimiseks.

Kõik need põhimõtted võimaldavad kirjutada paindlikumat, ilusamat ja usaldusväärsemat koodi, millel on kõrge seos ja madal sidusus. Loomulikult on teooria tore, kuid et arendaja hakkaks tõeliselt kasutama omandatud teadmisi, on vajalik praktika. Järgmine samm pärast OOP põhimõtete omandamist võib olla tarkvaraarenduse levinud probleemide lahendamiseks mõeldud disainimustrite uurimine.

Skillbox soovitab:

• Praktiline kursus «Mobiilne arendaja PRO».
• Rakenduslik veebikursus „Andmeanalüütik Pythonis“.
• Kaks aastat praktilist kursust «Ma olen PRO veebiarendaja».

Allikas: habr.com