Principi SOLID. S: Single responsibility

single responsibility

Single responsibility è il primo principio di SOLID. L’acronimo SOLID si riferisce ai principali 5 principi di buona programmazione ad oggetti descritti da Robert C. Martin nel suo libro Clean architecture, tradotto anche in italiano da Apogeo.

La mia idea è scrivere un articolo per ognuno dei 5 principi, iniziamo oggi con il primo, il principio di Single responsibility.

Definizione

Il principio di single responsibility afferma che “una classe deve avere uno e uno solo motivo per cambiare” o anche “una classe deve essere responsabile di un unico attore“. Genericamente una classe dovrebbe avere una sola responsabilità completamente incapsulata al suo interno, dedicarsi esclusivamente a quella e conseguentemente cambiare solo se tale responsabilità cambia e per nessun altro motivo.

Inoltre una classe dovrebbe rispondere ad un solo “attore” e per attore si intende una entità astratta che ha delle necessità all’interno del mio software.

Perché implementarlo

Come insegna uncle Bob, i requisiti di un software continuano a cambiare nel tempo; conseguentemente devono essere modificare le responsabilità di almeno una classe. Maggiori sono le responsabilità della classe in questione più spesso vi sarà il bisogno di cambiarla.

Il problema è che se una classe ha più di una responsabilità, la modifica di parte del codice di una si riflette automaticamente sull’altra, in quanto appartenente alla stessa classe.

Per esempio se la classe fa X e Y e per modificare X devo, per esempio, aggiungere un parametro al costruttore della classe, questa modifica porterà anche a dei cambiamenti sulle classi che la utilizzano per la responsabilità Y che non centra nulla con X.

Più una classe ha responsabilità più spesso dovrà essere modificata e di riflesso verranno modificate le classi che dipendono da questa ultima, quindi tutte le sue dipendenze.

Queste dovranno essere ricompilate e subiranno delle modifiche anche se non centrano nulla con la responsabilità che è effettivamente cambiata.

Per evitare tutti questi problemi è indispensabile che ogni classe abbia una e una sola responsabilità e, come dice uncle Bob, uno e un solo motivo per cambiare.

Non esagerare

Alcuni programmatori prendono il principio all’estremo e arrivano al punto di implementare classi con una sola funzione. Questo ovviamente porta ad una proliferazione di classi che porta solo confusione all’interno del codice.

Il principio di singola responsabilità deve essere usato con criterio secondo la propria esperienza.

Esempio

Assumiamo di avere una classe “Dipendente” con tre metodi:

  • CalcolaPaga: fornisce la paga da dare al dipendente
  • ReportHours: indica il numero di ore lavorate
  • Save: Salva i dati del dipendente sul database

Questi tre metodi sono responsabili di tre attori differenti: il primo metodo viene usato dal settore contabilità, il secondo dal settore risorse umane e il terzo al direttore tecnico.

Avendo i tre metodi nella stessa classe che dipendono da attori diversi può capitare che una modifica delle esigenze dell’uno si rifletta, senza volerlo, anche sugli altri due.

Per esempio qualora il metodo ReportHours e CalcolaPaga utilizzino lo stesso metodo sottostante per calcolare il numero di ore lavorate, una modifica a questo metodo richiesta dall’ufficio paghe porta, di riflesso, ad una modifica non richiesta al metodo ReportHours gestito dall’ufficio risorse umane.

La soluzione è porre ogni metodo in una sua classe dedicata e la classe Dipendente conterrà solo le interfacce di queste classi, senza quindi alcuna riga di codice al suo interno. Il calcolo delle ore lavorate sarà quindi completamente scorporato

Indice

Share
Ultimi articoli
Join

Newsletter

Nessuno spam, solo articoli interessanti ;)

Focus

Post correlati

semaphoreslim

SmaphoreSlim 101

SemaphoreSlim è una classe che permette la sincronizzazione di n thread che hanno una risorsa (scarsa) condivisa limitandone l’uso ad un numero massimo.

interlocked

Interlocked 101

La sincronizzazione dei thread è un elemento fondamentale nella programmazione asincrona, ne ho infatti parlato in vari post. La soluzione più versatile è sicuramente utilizzare

event

Come testare gli eventi

Testare che degli eventi siano stato effettivamente lanciati in C# non è immediato. Tipicamente è possibile testare che un evento venga lanciato aspettando un ManualResetEvent

Codice Pragmatico

Contatti

Per informazioni, dubbi o consulenze non esitate a contattarmi.

Lascia un messaggio

Ricevi le ultime news

Iscrivi alla newsletter

Solo articoli interessanti, promesso ;)