Articoli di programmazione
Principi SOLID: datemi una S! Single Responsibility Principle
I 5 principi SOLID della programmazione a oggetti fungono da base per progettare sistemi robusti e manutenibili. Vediamo il primo principio: S ovvero Single Responsibility Principle
L'acronimo SOLID si riferisce ai "cinque principi" dello sviluppo del software orientato agli oggetti. Ecco di seguito lo schema riassuntivo di tutti e cinque i principi:
S: Single responsibility principle o principio di singola responsabilità.
Ogni classe dovrebbe avere una ed una sola responsabilità, interamente incapsulata al suo interno.
O: Open/closed principle o principio aperto/chiuso.
Un'entità software dovrebbe essere aperta alle estensioni, ma chiusa alle modifiche.
L: Liskov substitution principle o principio di sostituzione di Liskov
Gli oggetti dovrebbero poter essere sostituiti con dei loro sottotipi, senza alterare il comportamento del programma che li utilizza.
I: Interface segregation principle o principio di segregazione delle interfacce.
Sarebbero preferibili più interfacce specifiche, che una singola generica.
D: Dependency inversion principle o principio di inversione delle dipendenze.
Una classe dovrebbe dipendere dalle astrazioni, non da classi concrete.
Single responsibility principle afferma che una classe deve avere un solo compito. Molti programmatori alle prime armi amano le classi "coltellino svizzero", come mi piace definirle, cioè classi che siano in grado di eseguire più logiche. Sembra una astuzia rendere una classe potente e ricca di funzionalità, perché sembra di risparmiare in scrittura di codice e di aver tutto sotto controllo, visto che tutto il codice risiede in un singolo file, in una singola classe, in una singola schermata. Inoltre sembra comodo perché basta istanziare una sola classe per fare tutto, senza bisogno di andarsi ad invischiare nella creazione di altri oggetti.
Di fatto questo anti-pattern è il male assoluto e rappresenta la via più rapida per la rovina dell'applicazione ed ecco. cos porta:
Ingestibilità
La classe cresce a dismisura e diventa illeggibile. Nella mia vita lavorativa ho visto classi da migliaia di righe, divenute ormai ingestibili: occorre molto tempo anche solo per leggerle velocemente e capire a grandi linee che logiche contengano.
Scarsa manutenibilità
La classe, facendo molte cose, ha molte dipendenze che la rendono scarsamente manutenibile: ogni cambiamento ad una singola dipendenza si riflette sull'intera classe, su tutto il suo corposo codice, che va rivisto, modificato, testato di nuovo e rilasciato ancora.
Scarse prestazioni
Una grande classe occupa più risorse di una piccola. Anche per eseguire un semplice metodo di questa mega-classe, dobbiamo crearla tutta e pagarne il prezzo computazionale.
Ho visto cose che voi umani non potreste immaginarvi; enormi classi in fiamme al largo dei bastioni di Orione, con innumerevoli dipendenze, che durante la creazione dell'istanza si connettevano ad un database, utilizzate solo per fare una semplice validazione sintattica di una stringa.
Di fatto Single responsibility principle ci invita a scrivere tante piccole classi specializzate, invece di poche grandi classi generiche. Corollario ne è la regola d'oro: scrivi il minimo indispensabile, usa il minimo indispensabile.
Da oggi quindi non scrivere più le logiche di Creazione, Validazione e Inserimento nel Database in una singola classe. Avrai bisogno di una classe per creare i tuoi oggetti.
Allo stesso modo dovrai creare una classe Validator, per le tue validazioni.
Ti servirà inoltre una classe per incapsulare le logiche di inserimento nel Database.
Dividi et impera.
#programmazione #solid
S: Single responsibility principle o principio di singola responsabilità.
Ogni classe dovrebbe avere una ed una sola responsabilità, interamente incapsulata al suo interno.
O: Open/closed principle o principio aperto/chiuso.
Un'entità software dovrebbe essere aperta alle estensioni, ma chiusa alle modifiche.
L: Liskov substitution principle o principio di sostituzione di Liskov
Gli oggetti dovrebbero poter essere sostituiti con dei loro sottotipi, senza alterare il comportamento del programma che li utilizza.
I: Interface segregation principle o principio di segregazione delle interfacce.
Sarebbero preferibili più interfacce specifiche, che una singola generica.
D: Dependency inversion principle o principio di inversione delle dipendenze.
Una classe dovrebbe dipendere dalle astrazioni, non da classi concrete.
Single responsibility principle afferma che una classe deve avere un solo compito. Molti programmatori alle prime armi amano le classi "coltellino svizzero", come mi piace definirle, cioè classi che siano in grado di eseguire più logiche. Sembra una astuzia rendere una classe potente e ricca di funzionalità, perché sembra di risparmiare in scrittura di codice e di aver tutto sotto controllo, visto che tutto il codice risiede in un singolo file, in una singola classe, in una singola schermata. Inoltre sembra comodo perché basta istanziare una sola classe per fare tutto, senza bisogno di andarsi ad invischiare nella creazione di altri oggetti.
Di fatto questo anti-pattern è il male assoluto e rappresenta la via più rapida per la rovina dell'applicazione ed ecco. cos porta:
Ingestibilità
La classe cresce a dismisura e diventa illeggibile. Nella mia vita lavorativa ho visto classi da migliaia di righe, divenute ormai ingestibili: occorre molto tempo anche solo per leggerle velocemente e capire a grandi linee che logiche contengano.
Scarsa manutenibilità
La classe, facendo molte cose, ha molte dipendenze che la rendono scarsamente manutenibile: ogni cambiamento ad una singola dipendenza si riflette sull'intera classe, su tutto il suo corposo codice, che va rivisto, modificato, testato di nuovo e rilasciato ancora.
Scarse prestazioni
Una grande classe occupa più risorse di una piccola. Anche per eseguire un semplice metodo di questa mega-classe, dobbiamo crearla tutta e pagarne il prezzo computazionale.
Ho visto cose che voi umani non potreste immaginarvi; enormi classi in fiamme al largo dei bastioni di Orione, con innumerevoli dipendenze, che durante la creazione dell'istanza si connettevano ad un database, utilizzate solo per fare una semplice validazione sintattica di una stringa.
Di fatto Single responsibility principle ci invita a scrivere tante piccole classi specializzate, invece di poche grandi classi generiche. Corollario ne è la regola d'oro: scrivi il minimo indispensabile, usa il minimo indispensabile.
Da oggi quindi non scrivere più le logiche di Creazione, Validazione e Inserimento nel Database in una singola classe. Avrai bisogno di una classe per creare i tuoi oggetti.
Allo stesso modo dovrai creare una classe Validator, per le tue validazioni.
Ti servirà inoltre una classe per incapsulare le logiche di inserimento nel Database.
Dividi et impera.
#programmazione #solid