Quali sono gli effetti collaterali della programmazione, comunque?

Ogni volta che parliamo di determinati concetti di programmazione, penso che sia importante fare un passo indietro rispetto alle specifiche di cui stiamo discutendo e guardare le cose nel contesto del quadro più ampio.

Alcuni moduli introducono effetti collaterali; alcuni no. Va bene.

Ad esempio, ieri ho accennato brevemente all’idea di programmare gli effetti collaterali, ma l’ho fatto parlando dell’utilizzo dei PSR. E per coloro che sono semplicemente interessati agli aspetti della programmazione in senso più generale, è importante anche capirli.

Ricorda, l’idea degli effetti collaterali come indicato in PSR-1 è:

Un file DOVREBBE dichiarare nuovi simboli (classi, funzioni, costanti, ecc.) e non causare altri effetti collaterali, oppure DOVREBBE eseguire la logica con effetti collaterali, ma NON DOVREBBE fare entrambi.

In questo post, non sono così interessato a discutere di logica con effetti collaterali (perché ci sono momenti in cui si verificheranno effetti collaterali). Invece, sono più interessato a comprendere gli effetti collaterali della programmazione (cosa sono, cosa evitare e così via).

Dopotutto, parlare di effetti collaterali in un contesto può significare una cosa mentre, nella programmazione, può significarne un’altra.

Programmazione degli effetti collaterali

Ok, quindi l’intera idea o definizione di un effetto collaterale generico è semplice, giusto?

un effetto secondario, tipicamente indesiderabile di un farmaco o di un trattamento medico.

Elimina l’intero aspetto del trattamento e ti rimane un "effetto secondario, … indesiderabile". Ok, ecco la parte potenzialmente confusa:

• scegliamo di includere un file,
• sappiamo cosa fa il file,
• quindi, se sappiamo cosa stiamo includendo e cosa fa, come può introdurre qualcosa di indesiderabile?

Almeno, è così che spesso mi viene chiesto quando si tratta di parlare di effetti collaterali. Nella programmazione, ho sempre generalizzato gli effetti collaterali come qualsiasi cosa che alteri lo stato del programma.

Abbastanza facile, giusto?

Effetti collaterali in WordPress

Quindi supponiamo che tu stia lavorando con WordPress, perché è quello che faccio e di cui scrivo 🙂, e abbiamo un file che è responsabile dell’aggiunta di una voce di sottomenu a uno dei menu di primo livello esistenti.

Quella classe potrebbe essere relativamente semplice in quanto avvolge la corretta chiamata API di WordPress, si attiva quando è collegata all’hook [corretto] e quindi aggiunge il sottomenu, come previsto.

Ma diciamo o quella classe, un metodo nella classe, o includendo un file che quella classe aggiunge anche alcuni JavaScript o stili che alterano lo stato della voce del sottomenu in modo tale che sia evidenziato, si comporti come se fosse stato "cliccato" oppure fa qualcosa che il programma o l’utente non intendono.

Questo sarebbe un effetto collaterale in quanto cambia lo stato del programma.

Cosa dovrebbe fare il modulo?

Quella classe stessa dovrebbe fare una cosa :

Il principio della responsabilità unica è un principio di programmazione del computer che afferma che ogni modulo o classe dovrebbe avere la responsabilità su una singola parte della funzionalità fornita dal software e che la responsabilità dovrebbe essere interamente incapsulata dalla classe.

Ma quando introduciamo qualcosa che si aggiunge a quello che dovrebbe fare – quando aggiungiamo alla sua responsabilità o cambiamo l’unica cosa fondamentale che fa – allora abbiamo introdotto un effetto collaterale.

Ricorda, questo non è intrinsecamente negativo (secondo la definizione PSR-1 sopra), ma è importante riconoscere quando lo stiamo facendo e quando non lo siamo.

Quindi, come aggiungiamo funzionalità?

Penso che la domanda naturale sia che se vogliamo aggiungere funzionalità a un programma che ne altera lo stato, come lo facciamo (ed è sbagliato)?

Primo, no, non è sbagliato. Voglio dire, i programmi hanno stati diversi in base a una varietà di cose, giusto? A volte succede quando qualcosa viene scritto su disco o database; a volte succede quando l’utente fa clic su un elemento dell’interfaccia utente e così via.

Ma come si verificano questi stati è dove entra in gioco la natura degli effetti collaterali.

Prendiamo ad esempio l’idea di un sottomenu. Dovrebbe fare una cosa. Non dovrebbe alterare nient’altro che ciò che vediamo sullo schermo.

• Non dovrebbe scrivere nel database,
• Non dovrebbe impostare un listener di eventi per quando un altro oggetto aggiunge un sottomenu,
• Non dovrebbe alterare la presentazione di nulla al di fuori di se stesso.
• E così via.

L’aggiunta di funzionalità funziona allo stesso modo: introduci classi che sono responsabili di fare una cosa specifica e lasci che lo facciano. Quando questi componenti lavorano insieme, allora hai un programma funzionale in cui ogni modulo (classe/funzione/qualunque cosa) rimane nella sua corsia, per così dire.

Che cos’è una regola pratica?

Sono sicuro che molti di voi leggendo questo hanno la vostra opinione su quali sono gli effetti collaterali e cosa non lo sono. E come te, ho il mio.

Pensare in questo modo:

Se chiami un metodo e restituisce un valore, quindi chiami di nuovo un metodo con lo stesso set di dati, dovrebbe restituire lo stesso valore.

È così che sai che la tua funzione, classe o modulo generico non ha effetti collaterali.

E, come per qualsiasi cosa, ho commesso questi errori (e probabilmente continuerò) ma si tratta di cercare di migliorare nel non farlo.

Alla fine, diventerà la nuova normalità.