Aina kun puhumme tietyistä ohjelmointikonsepteista, mielestäni on tärkeää ottaa askel taaksepäin kaikista keskustelemistamme yksityiskohdista ja tarkastella asioita laajemman kokonaisuuden yhteydessä.
Jotkut moduulit tuovat sivuvaikutuksia; jotkut eivät. Se on okei.
Esimerkiksi eilen kosketin lyhyesti ajatusta sivuvaikutusten ohjelmoinnista, mutta tein niin puhuessani PSR:ien käytöstä. Ja niille, jotka ovat vain kiinnostuneita ohjelmoinnin näkökohdista yleisemmin, on tärkeää ymmärtää myös ne.
Muista, että sivuvaikutusten idea PSR-1:ssä on:
Tiedoston PITÄÄ ilmoittaa uusia symboleja (luokat, funktiot, vakiot jne.) eikä aiheuta muita sivuvaikutuksia, tai sen PITÄÄ suorittaa logiikkaa sivuvaikutuksineen, mutta EI SIDÄ tehdä molempia.
Tässä viestissä en ole niin kiinnostunut keskustelemaan logiikasta sivuvaikutusten kanssa (koska on aikoja, jolloin sivuvaikutuksia tapahtuu). Sen sijaan olen enemmän huolissani ohjelmoinnin sivuvaikutusten ymmärtämisestä (mitä ne ovat, mitä vältetään ja niin edelleen).
Loppujen lopuksi sivuvaikutuksista puhuminen yhdessä yhteydessä voi tarkoittaa yhtä asiaa, kun taas ohjelmoinnissa se voi tarkoittaa toista.
Ohjelmoinnin sivuvaikutukset
Okei, joten koko idea tai määritelmä yleisestä sivuvaikutuksesta on yksinkertainen, eikö?
lääkkeen tai lääkehoidon toissijainen, tyypillisesti ei-toivottu vaikutus.
Ota pois koko hoitonäkökohta, ja sinulle jää "toissijainen, … ei-toivottu vaikutus." Okei, tässä on mahdollisesti hämmentävä osa:
- päätämme sisällyttää tiedoston,
- tiedämme mitä tiedosto tekee,
- Näin ollen, jos tiedämme, mitä sisällytämme ja mitä se tekee, kuinka se voi tuoda esiin jotain ei-toivottua?
Ainakin näin kuulen usein kysyttävän, kun puhutaan sivuvaikutuksista. Ohjelmoinnissa olen aina yleistänyt sivuvaikutukset kaikkeen, joka muuttaa ohjelman tilaa.
Tarpeeksi helppoa, eikö?
Sivuvaikutukset WordPressissä
Oletetaan siis, että työskentelet WordPressin kanssa, koska siitä minä teen ja kirjoitan 🙂, ja meillä on tiedosto, joka vastaa alivalikkokohteen lisäämisestä johonkin olemassa olevista ylätason valikoista.
Tämä luokka voisi olla suhteellisen yksinkertainen siinä mielessä, että se katkaisee oikean WordPress API -kutsun, käynnistyy, kun se on liitetty [oikeaan] koukkuun, ja lisää sitten alivalikon tarkoitetulla tavalla.
Oletetaan kuitenkin, että joko kyseinen luokka, luokassa oleva menetelmä tai tiedosto, joka lisää myös JavaScriptiä tai tyylejä, jotka muuttavat alivalikon kohdan tilaa siten, että se on korostettu, se käyttäytyy kuin "napsautettu" tai se tekee jotain, mitä joko ohjelma tai käyttäjä ei aio.
Se olisi sivuvaikutus, koska se muuttaa ohjelman tilaa.
Mitä moduulin pitäisi tehdä?
Tämän luokan pitäisi itse tehdä yksi asia :
Yksittäisen vastuun periaate on tietokoneohjelmointiperiaate, jonka mukaan jokaisella moduulilla tai luokalla tulee olla vastuu yhdestä ohjelmiston tarjoaman toiminnallisuuden osasta ja että vastuun tulee olla kokonaan luokan sisällä.
Mutta kun esittelemme jotain, joka lisää sen tarkoitusta – kun lisäämme sen vastuuta tai muutamme sen yksittäistä ydinasiaa – olemme ottaneet käyttöön sivuvaikutuksen.
Muista, että tämä ei ole luonnostaan huono (kuten yllä oleva PSR-1-määritelmä), mutta on tärkeää tunnistaa, milloin teemme sitä ja milloin emme.
Joten kuinka lisäämme toimintoja?
Luulen, että luonnollinen kysymys on, että jos haluamme lisätä toiminnallisuutta ohjelmaan, joka muuttaa sen tilaa, miten se tehdään (ja onko se väärin)?
Ensinnäkin, ei, se ei ole väärin. Tarkoitan, että ohjelmilla on erilaisia tiloja useiden asioiden perusteella, eikö niin? Joskus se tapahtuu, kun jotain kirjoitetaan levylle tai tietokantaan; joskus se tapahtuu, kun käyttäjä napsauttaa jotakin käyttöliittymän elementtiä ja niin edelleen.
Mutta miten nämä tilat tapahtuvat, sivuvaikutusten luonne vaikuttaa.
Otetaan esimerkiksi ajatus alivalikosta. Sen pitäisi tehdä yksi asia. Sen ei pitäisi muuttaa mitään muuta kuin sitä, mitä näemme näytöllä.
- Sen ei pitäisi kirjoittaa tietokantaan,
- Sen ei pitäisi määrittää tapahtumaseurainta, kun toinen objekti lisää alivalikon,
- Sen ei pitäisi muuttaa minkään itsensä ulkopuolisen esitystä.
- Ja niin edelleen.
Toimintojen lisääminen toimii samalla tavalla: esittelet luokat, jotka ovat vastuussa tietyn asian tekemisestä, ja annat heidän tehdä sen. Kun nämä komponentit toimivat yhdessä, sinulla on toiminnallinen ohjelma, jossa jokainen moduuli (luokka/toiminto/mikä tahansa) pysyy niin sanotusti omalla kaistallaan.
Mikä on peukalosääntö?
Olen varma, että monet teistä tätä lukevista tietävät, mitä sivuvaikutuksia on ja mitä ne eivät ole. Ja kuten sinulla, minulla on omani.
Ajattele asiaa näin:
Jos kutsut menetelmää ja se palauttaa arvon ja sitten kutsut metodia uudelleen samalla tietojoukolla, sen pitäisi palauttaa sama arvo.
Näin tiedät, että funktiollasi, luokallasi tai yleisellä moduulillasi ei ole sivuvaikutuksia.
Ja kuten missä tahansa, olen tehnyt nämä virheet (ja tulen todennäköisesti jatkamaan), mutta kyse on siitä, että yritän olla parempi tekemättä sitä.
Lopulta siitä tulee uusi normaali.