Ho iniziato a giocare con il PHP quasi dieci anni fa, mentre Laravel l’ho conosciuto nel 2012. Da questa esperienza ho imparato che linguaggio e framework hanno un aspetto molto rilevante in comune: lasciano tanta, tantissima libertà d’azione.
Ora, come il caro Zio Ben ricorda al suo famoso nipote in una scena abbastanza famosa, “da grandi poteri derivano grandi responsabilità”. Può sembrare buffo, ma il principio si applica perfettamente al nostro ambiente. La libertà di cui disponiamo è massima, gli strumenti tanti… ma che succede se non conosciamo tutti i concetti “fondamentali” di riferimento?
Un bel casino. Ecco perché, oggi, mi ritrovo qui a scrivere queste righe.
In questa mini-serie di cinque articoli, cercherò di spiegare cosa sono i Principi S.O.L.I.D. nel design orientato agli oggetti, e come possono aiutare (in modo anche piuttosto considerevole) nel nostro lavoro.
S.O.L.I.D. (?)
Partiamo dalle basi. Innanzitutto, S.O.L.I.D. è un acronimo che sta, precisamente, per:
- S ingle Responsiblity Principle;
- O pen/Closed Principle;
- L iskov Substitution Principle;
- I nterface Segregation Principle;
- D ependency Inversion Principle;
Ognuno di questi principi cerca di sintetizzare al meglio un modo giusto di scrivere software. Giusto non perché c’è qualche
entità ultraterrena che lo decide, ma perché ogni singolo principio, nella sua individualità, indirizza lo sviluppatore in una
specifica direzione, arrivando all’obiettivo prefissato: scrivere codice leggibile e facilmente manutenibile, estendibile nel
tempo senza (troppe) complicazioni.
Questi principi sono tutti legati tra loro. Prova a fare caso al fatto che, applicandone uno, ti ritroverai anche ad applicarne un altro o altri due, in modo quasi involontario. L’ideale per te sarà capire come trovare il modo, nel lavoro di tutti i giorni, di applicarli tutti.
Ok, Come si Fa?
Scriverò quindi un articolo, uno per ogni principio. Come forse qualcuno avrà già immaginato, questa non sarà una serie esclusivamente dedicata a Laravel.
Lo sarà, non in modo esclusivo ma direi più in modo inclusivo: conoscere questi principi sarà utile a comprendere dove il framework arriva e dove no, e come si può organizzare al meglio il proprio progetto.
Ogni articolo avrà una struttura ben precisa. Innanzitutto, verrà enunciato il principio in modo più “formale”. Subito dopo, quindi, seguirà una spiegazione dettagliata del principio in termini più comprensibili e semplici. Perché le formalità, sotto sotto, non ci fanno impazzire. Infine, concluderemo con uno o più esempi di applicazione effettiva del principio per fissare definitivamente le idee.
Detto questo basta con le chiacchiere: iniziamo dal primo principio, il Single Responsibility Principle (o Principio di Isolamento delle Responsabilità).
