Mul puutun sageli kokku arendajatega, kes ei ole kuulnud SOLID põhimõtetest (me . — 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 igapäevases töös. Mõned neist on hästi tuntud, teised mitte niivõrd, seega on artikkel kasulik nii algajatele kui ka kogenud programmeerijatele.
Tuletame meelde: kõigile «Habr» lugejatele — 10 000 rubla allahindlus kõikide Skillboxi kursuste registreerimisel sooduskoodiga «Habr».
Skillbox soovitab: Hariduslik veebikursus .
DRY (Ära Korruta End)
Suhteliselt lihtne põhimõte, mille sisu on arusaadav pealkirjast: «Ära korruta end». Arendaja jaoks tähendab see vajadust vältida dubleerivat koodi ning võimalust kasutada töös abstraktsiooni.
Kui koodis on kaks korduvat lõiku, tuleks need liita ühte meetodisse. Kui fikseeritud väärtust kasutatakse rohkem kui üks kord, tasub see ümber kujundada avalikuks konstandiks.
See on vajalik koodi lihtsustamiseks ja selle haldamise hõlbustamiseks, mis on OOP peamine eesmärk. Liialdada liitmisega ei tasu, kuna sama kood ei saa samaaegselt läbida kontrolli nii OrderId kui ka SSN puhul.
Kasutusekspressimise muutmine
Enamik ettevõtete tarkvaratooteid areneb pidevalt. See tähendab, et koodis tuleb teha muudatusi, seda tuleb toetada. Enda elu lihtsustamiseks võib kasutada kapseldamist. See võimaldab olemasolevat koodibaasi tõhusamalt testida ja hallata. .
Kui kirjutate Java's, siis .
Ava/aitama printsiip
Selle printsiibi saab kergesti meelde jätta, lugedes järgmist väidet: "Tarkvara üksused (klassid, moodulid, funktsioonid jne) peaksid olema avatud laiendamiseks, kuid suletud muutmiseks". Praktikas tähendab see, et nad võimaldavad oma käitumise muutmist ilma algkoodi muutmata.
Põhimõte on oluline, kui lähtekoodi muudatused nõuavad selle ülevaatamist, modulaarset testimist ja muid protseduure. Kood, mis järgib avatud/suletud põhimõtet, ei muutu laiendamise korral, mistõttu on sellega palju vähem probleeme.
Siin on näide koodist, mis rikub seda põhimõtet.
Kui sellega midagi muuta on vaja, võtab see palju aega, kuna tuleb muuta kõiki koodi osi, millel on seos vajaliku fragmentiga.
Muide, avatus-suletus on üks SOLID-i põhimõtteid.
Ühe vastutuse põhimõte (SRP)
Veel üks põhimõte SOLID-i kogumikust. See ütleb, et "on ainult üks põhjus, mis viib klassi muutmiseni". Klass lahendab ainult ühe ülesande. Sellel võivad olla mitu meetodit, kuid igaüht kasutatakse ainult üldise ülesande lahendamiseks. Kõik meetodid ja omadused peavad teenima vaid seda.
Selle printsiibi väärtus seisneb selles, et see nõrgendab seoseid tarkvarakomponentide ja koodi vahel. Kui klassi lisada rohkem kui üks funktsionaalsus, tekib side kahe funktsiooni vahel. Seega, kui muuta ühte neist, on suur oht häirida teist, mis on esimesele seotud. See tähendab, et testimise tsüklite arvu suurenemine on vajalik, et varakult kõiki probleeme avastada.
Sõltuvuste inverteerimise printsiip (DIP)
Ülaltoodud koodinäites sõltub AppManager EventLogWriteri klasist, mis omakorda on tihedalt seotud AppManageriga. Kui on vaja muud viisi teate edastamiseks, olgu see siis push, SMS või e-kiri, tuleb AppManageri klassi muuta.
Probleem saab DIP-i abil lahendatud. Nii et parema lähenemise asemel küsime EventLogWriterit, mis tuuakse sisse raamistiku kaudu.
DIP võimaldab hõlpsasti asendada eraldi mooduleid teistega, muutes sõltuvusmooduli. See annab võimaluse muuta üht moodulit, mõjutamata teisi.
Kompositsioon asemel pärimine
Koodi taaskasutamise põhimeetodeid on kaks: pärimine ja kompositsioon, millest kummalgi on omad eelised ja puudused. Üldiselt eelistatakse teist, kuna see on paindlikum.
Kompositsioon võimaldab muuta klassi käitumist käitamise ajal, seadistades selle omadused. Liideste rakendamisel kasutatakse polümorfismi, mis võimaldab paindlikumat rakendust.
Ieven 'Effective Java' autor Joshua Bloch soovitab eelistada kompositsiooni, mitte pärimist.
Barbara Liskovi asendatavuse põhimõte (LSP)
Veel üks põhimõte SOLID-mudelist. See ütleb, et alamklassid peavad olema asendatavad superklassiga. See tähendab, et meetodid ja funktsioonid, mis töötavad superklassiga, peavad olema sujuvalt kohandatavad ka alamklasside jaoks.
LSP on seotud nii ühte vastutust kui ka vastutuse jagamise põhimõttega. Kui klass annab rohkem funktsionaalsust kui alamklass, siis viimane ei toeta teatud funktsioone, rikkudes seetõttu seda põhimõtet.
Siin on koodilõik, mis on LSP-ga vastuolus.
Meetod area(Rectangle r) arvutab Ristküliku pindala. Programm kukub pärast Square'i täitmist, kuna Square ei ole siin Ristkülik. Vastavalt LSP põhimõttele peaksid funktsioonid, mis kasutavad aluseks olevaid klasse, olema võimelised kasutama ka tuletatud klasside objekte ilma lisainstruktsioonideta.
See põhimõte, mis on spetsiifiline alamliigi määratlemiseks, esitas Barbara Liskov 1987. aastal konverentsil oma peamisel ettekandel, mille pealkiri oli „Andmete abstraktsioon ja hierarhia“ — seetõttu ka selle nimi.
Liidese jagamise põhimõte (ISP)
Veel üks SOLID põhimõte. Selle kohaselt ei peaks liidest, mida ei kasutata, rakendama. Selle põhimõtte järgimine aitab süsteemil jääda paindlikuks ja muudatuste tegemisel refaktooritavaks.
Seda olukorda esineb kõige sagedamini siis, kui liides sisaldab mitmeid funktsionaalsusi, samas kui kliendi jaoks on vajalik vaid üks neist.
Kuna liidese kirjutamine on keeruline ülesanne, on selle muutmine pärast selle lõppemist probleem, mida ei tohiks rikkuda.
ISP printsiip Java's annab selle, et kõik meetodid tuleb esmalt rakendada ja alles seejärel saavad klassid neid kasutada. Seetõttu võimaldab printsiip vähendada meetodite arvu.
Programmeerige liidese, mitte rakenduse jaoks
Siit on kõik selge juba pealkirjast. Selle printsiibi rakendamine viib paindliku koodi loomise, mis suudab töötada iga uue liidese rakendusega.
Tuleb kasutada liidese tüüpi muutujaid, tagastatavaid tüüpe või meetodi argumendi tüüpi. Näide - kasutage SuperClass'i, mitte SubClass'i.
Üks sõna:
List numbers = getNumbers();
Ja mitte:
ArrayList numbers = getNumbers();
Siin on praktiline rakendus, millest ülalpool räägiti.
Delegeerimise printsiip
Levinud näide on Java meetodid equals() ja hashCode(). Kui tuleb võrrelda kaht objekti, delegeeritakse see toiming vastavale klassile, mitte kliendile.
Printsiibi eeliseks on koodi dubleerimise puudumine ja suhteliselt lihtne käitumise muutmine. Samuti on see rakendatav sündmuste delegeerimisele.
Kõik need põhimõtted võimaldavad kirjutada paindlikumat, ilusamat ja usaldusväärsemat koodi, millel on kõrge seotuse ja madala sidumise tase. Loomulikult on teooria tore, kuid et arendaja tõesti omandatud teadmisi rakendaks, on vajalik praktika. Järgmine samm pärast OOP põhimõtete omandamist võiks olla disainimustrite uurimine, et lahendada üldisi tarkvaraarenduse probleeme.
Skillbox soovitab:
- Praktiline kursus .
- Rakenduslik veebikursus .
- Kaheaastane praktiline kursus .
Allikas: habr.com
