Vad är programmeringsbiverkningar egentligen?

När vi pratar om vissa programmeringskoncept tror jag att det är viktigt att ta ett steg tillbaka från de detaljer vi än diskuterar och titta på saker i sammanhanget av den större bilden.

Vissa moduler introducerar biverkningar; vissa gör det inte. Det är okej.

Till exempel igår berörde jag kort idén om att programmera biverkningar, men jag gjorde det när jag pratade om att använda PSR. Och för dem som helt enkelt är intresserade av aspekter av programmering i en mer allmän bemärkelse, är det viktigt att förstå dem också.

Kom ihåg att idén om biverkningar som anges i PSR-1 är:

En fil SKA deklarera nya symboler (klasser, funktioner, konstanter, etc.) och inte orsaka några andra biverkningar, eller så SKA den köra logik med biverkningar, men SKA INTE göra båda.

I det här inlägget är jag inte så intresserad av att diskutera logik med biverkningar (eftersom det finns tillfällen då biverkningar kommer att hända). Istället är jag mer angelägen om att förstå biverkningar av programmering (vad de är, vad man ska undvika och så vidare).

Att prata om biverkningar i ett sammanhang kan trots allt betyda en sak medan det i programmering kan betyda en annan.

Programmeringsbiverkningar

Okej, så hela idén eller definitionen av en generisk biverkning är enkel, eller hur?

en sekundär, typiskt oönskad effekt av ett läkemedel eller medicinsk behandling.

Ta bort hela behandlingsaspekten och du får en "sekundär, … oönskad effekt." Okej, så här är den potentiellt förvirrande delen:

• vi väljer att inkludera en fil,
• vi vet vad filen gör,
• alltså, om vi vet vad vi inkluderar och vad det gör, hur kan det introducera något oönskat?

Åtminstone är det så jag ofta hör att det frågas när det kommer till att prata om biverkningar. I programmering har jag alltid generaliserat biverkningar som allt som förändrar programmets tillstånd.

Lätt nog, eller hur?

Biverkningar i WordPress

Så låt oss säga att du arbetar med WordPress, för det är vad jag gör och skriver om 🙂, och vi har en fil som är ansvarig för att lägga till ett undermenyobjekt till en av de befintliga toppnivåmenyerna.

Den klassen kan vara relativt enkel på så sätt att den omsluter det korrekta WordPress API-anropet, den avfyras när den kopplas till [rätt] krok och sedan lägger till undermenyn som avsett.

Men låt oss säga att antingen den klassen, en metod i klassen eller inkluderar en fil att den klassen också lägger till en del JavaScript eller stilar som ändrar tillståndet för undermenyobjektet så att det är markerat, det beter sig som om det "klickats" eller det gör något som antingen programmet eller användaren inte har för avsikt.

Det skulle vara en bieffekt eftersom det förändrar programmets tillstånd.

Vad ska modulen göra?

Den klassen i sig borde göra en sak :

Principen för ett enda ansvar är en datorprogrammeringsprincip som säger att varje modul eller klass ska ha ansvar över en enskild del av funktionaliteten som tillhandahålls av programvaran, och att ansvaret ska vara helt inkapslat av klassen.

Men när vi introducerar något som lägger till vad det är tänkt att göra – när vi lägger till sitt ansvar eller ändrar den enda kärngrejen det gör – då har vi infört en bieffekt.

Kom ihåg att detta inte i sig är dåligt (enligt PSR-1-definitionen ovan), men det är viktigt att känna igen när vi gör det och när vi inte gör det.

Så hur lägger vi till funktionalitet?

Jag tror att den naturliga frågan är att om vi vill lägga till funktionalitet till ett program som ändrar dess tillstånd, hur gör vi det (och är det fel)?

För det första, nej, det är inget fel. Jag menar att program har olika tillstånd baserat på en mängd olika saker, eller hur? Ibland händer det när något skrivs till disk eller en databas; ibland händer det när användaren klickar på ett element i användargränssnittet, och så vidare.

Men hur dessa tillstånd inträffar är där karaktären av biverkningar spelar in.

Ta till exempel tanken på en undermeny. Det ska göra en sak. Det borde inte förändra något annat än vad vi ser på skärmen.

• Det ska inte skriva till databasen,
• Det bör inte ställa in en händelseavlyssnare för när ett annat objekt lägger till en undermeny,
• Det bör inte förändra presentationen av något utanför sig själv.
• Och så vidare.

Att lägga till funktionalitet fungerar på samma sätt: Du introducerar klasser som är ansvariga för att göra en specifik sak och låter dem göra det. När dessa komponenter fungerar i samverkan med varandra, har du ett funktionsprogram där varje modul (klass/funktion/vad som helst) stannar i sitt körfält, så att säga.

Vad är en tumregel?

Jag är säker på att många av er som läser detta har din syn på vad biverkningar är och vad de inte är. Och precis som du har jag min egen.

Tänk på det så här:

Om du anropar en metod och den returnerar ett värde, och sedan anropar en metod igen med samma uppsättning data, bör den returnera samma värde.

Det är så du vet att din funktion, klass eller generiska modul inte har biverkningar.

Och som med allt annat har jag gjort dessa misstag (och kommer sannolikt att fortsätta) men det handlar om att försöka bli bättre på att inte göra det.

Så småningom kommer det att bli det nya normala.