Tapaan melko usein kehittäjiä, jotka eivät ole kuulleet SOLID-periaatteista (me . — Transl.) tai olioohjelmointia (OOP), tai olet kuullut niistä, mutta et käytä niitä käytännössä. Tässä artikkelissa kuvataan OOP-periaatteiden hyödyt, jotka auttavat kehittäjää hänen päivittäisessä työssään. Jotkut niistä ovat hyvin tunnettuja, toiset eivät niin paljon, joten artikkeli on hyödyllinen sekä aloittelijoille että kokeneille ohjelmoijille.
Muistutamme sinua: kaikille Habrin lukijoille - 10 000 ruplan alennus ilmoittautuessaan mille tahansa Skillbox-kurssille Habr-tarjouskoodilla.
Skillbox suosittelee: Kouluttava verkkokurssi .
KUIVA (älä toista itseäsi)
Melko yksinkertainen periaate, jonka ydin käy selväksi nimestä: "Älä toista itseäsi." Ohjelmoijalle tämä tarkoittaa tarvetta välttää päällekkäistä koodia sekä mahdollisuutta käyttää abstraktiota työssään.
Jos koodissa on kaksi toistuvaa osaa, ne tulee yhdistää yhdeksi menetelmäksi. Jos kovakoodattua arvoa käytetään useammin kuin kerran, se kannattaa muuntaa julkiseksi vakioksi.
Tämä on välttämätöntä koodin yksinkertaistamiseksi ja sen ylläpidon helpottamiseksi, mikä on OOP:n päätavoite. Älä myöskään käytä liiallista liittoa, koska sama koodi ei läpäise vahvistusta sekä OrderId:n että SSN:n kanssa.
Muutosten kapselointi
Useimpien yritysten ohjelmistotuotteet kehittyvät jatkuvasti. Tämä tarkoittaa, että koodiin on tehtävä muutoksia, sitä on tuettava. Voit helpottaa elämääsi käyttämällä kapselointia. Näin voit testata ja ylläpitää nykyistä koodipohjaasi tehokkaammin. .
Jos kirjoitat Javalla, niin .
Avoin/kiinni -periaate
Tämä periaate voidaan helposti muistaa lukemalla seuraava lause: "Ohjelmistokokonaisuuksien (luokat, moduulit, funktiot jne.) tulee olla avoinna laajentamista varten, mutta suljettuja muokkauksille." Käytännössä tämä tarkoittaa, että he voivat sallia käyttäytymisensä muuttamisen muuttamatta lähdekoodia.
Periaate on tärkeä, kun lähdekoodin muutokset vaativat koodin tarkistamista, yksikkötestausta ja muita toimenpiteitä. Avoin/kiinni -periaatetta noudattava koodi ei muutu laajennettaessa, joten siinä on paljon vähemmän ongelmia.
Tässä on esimerkki koodista, joka rikkoo tätä periaatetta.
Jos sinun on muutettava siinä jotain, se vie paljon aikaa, koska kaikki koodin osat, joilla on yhteys haluttuun fragmenttiin, on vaihdettava.
Muuten, avoimuus-suljetus on yksi SOLIDin periaatteista.
Yhden vastuun periaate (SRP)
Toinen periaate SOLID-sarjasta. Siinä sanotaan, että "on vain yksi syy, joka aiheuttaa muutoksen luokassa". Luokka ratkaisee vain yhden ongelman. Sillä voi olla useita menetelmiä, mutta jokaista niistä käytetään vain yhteisen ongelman ratkaisemiseen. Kaikkien menetelmien ja ominaisuuksien tulee palvella vain tätä.
Tämän periaatteen arvo on, että se löysää yksittäisen ohjelmistokomponentin ja koodin välistä kytkentää. Jos lisäät luokkaan useamman kuin yhden toiminnallisuuden, se luo yhteyden näiden kahden funktion välille. Näin ollen, jos muutat yhtä niistä, on suuri mahdollisuus pilata toinen, joka liittyy ensimmäiseen. Tämä tarkoittaa testausjaksojen lisäämistä kaikkien ongelmien tunnistamiseksi etukäteen.
Riippuvuuden inversioperiaate (DIP)
Yllä on esimerkki koodista, jossa AppManager on riippuvainen EventLogWriteristä, joka puolestaan on tiiviisti yhdistetty AppManagerin kanssa. Jos tarvitset toisen tavan näyttää ilmoitus, olipa se push, tekstiviesti tai sähköposti, sinun on vaihdettava AppManager-luokka.
Ongelma voidaan ratkaista käyttämällä DIP:tä. Joten AppManagerin sijaan pyydämme EventLogWriteriä, joka syötetään kehyksen avulla.
DIP mahdollistaa yksittäisten moduulien vaihtamisen helposti muilla vaihtamalla riippuvuusmoduulia. Tämä mahdollistaa yhden moduulin vaihtamisen vaikuttamatta muihin.
Koostumus perinnön sijaan
On kaksi päätapaa käyttää koodia uudelleen: perinnöllinen ja kokoonpano, joilla molemmilla on omat etunsa ja haittansa. Yleensä toinen on parempi, koska se on joustavampi.
Koostumus antaa sinulle mahdollisuuden muuttaa luokan käyttäytymistä ajon aikana asettamalla sen ominaisuuksia. Rajapintoja toteutettaessa käytetään polymorfismia, joka antaa joustavamman toteutuksen.
Joshua Blochin Jopa Effective Java neuvoo valitsemaan koostumuksen perinnön sijaan.
Barbara Liskovin korvausperiaate (LSP)
Toinen periaate SOLID-työkalusarjasta. Siinä sanotaan, että alatyyppien on voitava korvata supertyyppi. Toisin sanoen superluokan kanssa toimivien menetelmien ja funktioiden pitäisi pystyä toimimaan ilman ongelmia sen alaluokkien kanssa.
LSP liittyy sekä yhden vastuun periaatteeseen että yhteisvastuun periaatteeseen. Jos luokka tarjoaa enemmän toimintoja kuin alaluokka, jälkimmäinen ei tue osaa toiminnoista, mikä rikkoo tätä periaatetta.
Tässä on koodinpätkä, joka on ristiriidassa LSP:n kanssa.
Pinta-ala (Rectangle r) -menetelmä laskee suorakulmion alueen. Ohjelma kaatuu Squaren suorittamisen jälkeen, koska neliö ei ole suorakulmio tässä. LSP-periaatteen mukaan funktioiden, jotka käyttävät viittauksia perusluokkiin, tulee pystyä käyttämään johdettujen luokkien objekteja ilman lisäkäskyjä.
Tätä periaatetta, joka on alatyypin erityinen määritelmä, ehdotti Barbara Liskov vuoden 1987 konferenssin pääpuheenvuorossaan nimeltä "Data Abstraction and Hierarchy", mistä se nimikin.
Interface Separation Principle (ISP)
Toinen KIINTEÄ periaate. Sen mukaan käyttämätöntä rajapintaa ei tulisi toteuttaa. Tämän periaatteen noudattaminen auttaa järjestelmää pysymään joustavana ja soveltuvana refaktorointiin, kun toimintalogiikkaan tehdään muutoksia.
Useimmiten tämä tilanne tapahtuu, kun käyttöliittymä sisältää useita toimintoja kerralla, ja asiakas tarvitsee vain yhden niistä.
Koska käyttöliittymän kirjoittaminen on vaikea tehtävä, sen muuttaminen työn valmistuttua rikkomatta mitään on haaste.
Javan ISP-periaatteen etuna on, että kaikki menetelmät on ensin otettava käyttöön, ja vasta sitten niitä voidaan käyttää luokittain. Siksi periaate mahdollistaa menetelmien määrän vähentämisen.
Käyttöliittymän ohjelmointi, ei toteutus
Kaikki täällä on selvää nimestä. Tämän periaatteen soveltaminen johtaa joustavan koodin luomiseen, joka toimii minkä tahansa uuden käyttöliittymän toteutuksen kanssa.
Sinun tulee käyttää käyttöliittymätyyppiä muuttujien, palautustyyppien tai metodiargumentin tyyppiä varten. Esimerkki on SuperClassin käyttäminen alaluokan sijaan.
Eli:
Listanumerot= getNumbers();
Mutta ei:
ArrayList numerot = getNumbers();
Tässä on käytännön toteutus siitä, mitä edellä on käsitelty.
Delegoinnin periaate
Yleinen esimerkki on Java-menetelmät equals() ja hashCode(). Kun on tarpeen vertailla kahta objektia, tämä toiminto delegoidaan vastaavalle luokalle asiakasluokan sijaan.
Periaatteen etuna on, että koodia ei ole päällekkäin ja käyttäytymistä on suhteellisen helppo muuttaa. Koskee myös tapahtuman delegointia.
Kaikki nämä periaatteet antavat sinun kirjoittaa joustavampaa, kauniimpaa ja luotettavampaa koodia korkealla koheesiolla ja alhaisella kytkennällä. Tietysti teoria on hyvä asia, mutta jotta kehittäjä voisi todella käyttää hankittua tietoa, tarvitaan käytäntöä. Kun olet oppinut OOP-periaatteet, seuraava askel saattaa olla suunnittelumallien oppiminen yleisten ohjelmistokehitysongelmien ratkaisemiseksi.
Skillbox suosittelee:
- Käytännön kurssi .
- Sovellettu verkkokurssi .
- Kahden vuoden käytännön kurssi .
Lähde: will.com