Alati, kui me räägime teatud programmeerimiskontseptsioonidest, on minu arvates oluline astuda samm tagasi mis tahes spetsiifikast, mida me arutame, ja vaadata asju laiema pildi kontekstis.
Mõned moodulid tutvustavad kõrvaltoimeid; mõned mitte. See on korras.
Näiteks eile puudutasin põgusalt kõrvalmõjude programmeerimise ideed, kuid tegin seda PSR-ide kasutamisest rääkides. Ja neile, kes on lihtsalt huvitatud programmeerimise aspektidest üldisemas mõttes, on oluline ka neid mõista.
Pidage meeles, et PSR-1-s kirjeldatud kõrvaltoimete idee on järgmine:
Fail PEAKS deklareerima uusi sümboleid (klassid, funktsioonid, konstandid jne) ega põhjusta muid kõrvalmõjusid või PEAKS täitma kõrvalmõjudega loogikat, kuid EI TOHI teha mõlemat.
Selles postituses ei ole ma nii huvitatud kõrvalmõjudega loogika üle arutlemisest (sest on aegu, kus kõrvalmõjud tekivad). Selle asemel tegelen rohkem programmeerimise kõrvalmõjude mõistmisega (mis need on, mida vältida jne).
Lõppude lõpuks võib kõrvalmõjudest rääkimine ühes kontekstis tähendada üht, programmeerimisel aga teist.
Programmeerimise kõrvalmõjud
Olgu, nii et kogu üldise kõrvalmõju idee või määratlus on lihtne, eks?
ravimi või ravi teisene, tavaliselt ebasoovitav toime.
Eemaldage kogu ravi aspekt ja teile jääb "teisene, … soovimatu mõju". Olgu, siin on potentsiaalselt segadusttekitav osa:
- valime faili kaasamise,
- me teame, mida fail teeb,
- Seega, kui me teame, mida me kaasame ja mida see teeb, siis kuidas saab see tuua midagi ebasoovitavat?
Vähemalt nii kuulen seda sageli küsimas, kui rääkida kõrvalmõjudest. Programmeerimisel olen alati üldistanud kõrvalmõjusid kui kõike, mis muudab programmi olekut.
Piisavalt lihtne, eks?
WordPressi kõrvalmõjud
Oletame, et töötate WordPressiga, sest see on see, mida ma teen ja kirjutan 🙂 ning meil on fail, mis vastutab alammenüü üksuse lisamise eest mõnda olemasolevasse tipptaseme menüüsse.
See klass võib olla suhteliselt lihtne, kuna see murrab õige WordPressi API kutse, käivitub, kui see on ühendatud [õige] konksuga, ja lisab seejärel alammenüü, nagu ette nähtud.
Kuid oletame, et see klass, klassi meetod või fail, mis lisab ka JavaScripti või stiile, mis muudavad alammenüü üksuse olekut nii, et see on esile tõstetud, käitub nii, nagu oleks sellel "klõpsatud" või see teeb midagi, mida programm või kasutaja ei kavatse.
See oleks kõrvalmõju, kuna see muudab programmi olekut.
Mida peaks moodul tegema?
See klass ise peaks tegema ühte asja :
Ühtse vastutuse põhimõte on arvutiprogrammeerimise põhimõte, mis sätestab, et iga moodul või klass peaks vastutama tarkvara pakutava funktsionaalsuse ühe osa eest ja see vastutus peaks olema täielikult klassifitseeritud.
Aga kui me tutvustame midagi, mis täiendab seda, mida see peaks tegema – kui lisame selle vastutust või muudame selle põhilist asja –, siis oleme kasutusele võtnud kõrvalmõju.
Pidage meeles, et see ei ole oma olemuselt halb (vastavalt ülaltoodud PSR-1 määratlusele), kuid on oluline ära tunda, millal me seda teeme ja millal mitte.
Niisiis, kuidas me funktsionaalsust lisame?
Ma arvan, et loomulik küsimus on selles, et kui tahame lisada programmile funktsionaalsust, mis muudab selle olekut, siis kuidas me seda teeme (ja kas see on vale)?
Esiteks, ei, see pole viga. Ma mõtlen, et programmidel on erinevatel asjadel erinevad olekud, eks? Mõnikord juhtub see siis, kui midagi kirjutatakse kettale või andmebaasi; mõnikord juhtub see siis, kui kasutaja klõpsab kasutajaliidese elemendil jne.
Kuid see, kuidas need seisundid juhtuvad, mängib kõrvaltoimete olemust.
Võtke näiteks alammenüü idee. See peaks tegema ühte asja. See ei tohiks muuta midagi muud peale selle, mida me ekraanil näeme.
- See ei tohiks andmebaasi kirjutada,
- See ei tohiks seadistada sündmuste kuulajat, kui mõni muu objekt lisab alammenüü,
- See ei tohiks muuta millegi endast väljaspool oleva esitusviisi.
- Ja nii edasi.
Funktsionaalsuse lisamine toimib samamoodi: tutvustate klasse, mis vastutavad konkreetse asja tegemise eest, ja lasete neil seda teha. Kui need komponendid töötavad koos, on teil funktsionaalne programm, milles iga moodul (klass/funktsioon/mis iganes) jääb nii-öelda oma rajale.
Mis on rusikareegel?
Olen kindel, et paljud teist, kes seda loevad, teavad, millised on kõrvaltoimed ja millised mitte. Ja nagu teil, on ka minul oma.
Mõelge sellele järgmiselt:
Kui kutsute meetodit ja see tagastab väärtuse ja seejärel kutsute meetodi uuesti sama andmekomplektiga, peaks see tagastama sama väärtuse.
Nii teate, et teie funktsioonil, klassil või üldisel moodulil pole kõrvalmõjusid.
Ja nagu iga asjaga, olen ma neid vigu teinud (ja tõenäoliselt jätkan), kuid see on küsimus, et püüan seda mitte teha.
Lõpuks saab sellest uus normaalsus.