Principi SOLID. O: Open-closed principle

open closed

L’open-closed principle è il secondo 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.

Questo è probabilmente il principio più forte, che racchiude tutti gli altri.

Definizione

Il principio di open-closed afferma che “una classe dovrebbe essere aperta alle estensioni e chiusa alle modifiche“.

Questo significa che uno software dovrebbe poter permettere estensioni del suo comportamento senza dover andare a modificare le classi già esistenti.

Qualora una piccola modifica ai requisiti porti una notevole rivoluzione nel software sottostante, significa che questo principio non è stato rispettato.

Come implementarlo

Come insegna uncle Bob, i requisiti di un software continuano a cambiare nel tempo; conseguentemente il software deve potersi adattare a tali modifiche.

La prima idea di Bertrand Mayer per risolvere la questione è usare l’ereditarità: per estendere il comportamento di un software basta aggiungere una nuova classe figlia che estende il comportamento della classe padre.

Il problema dell’ereditarietà è che questa porta ad un forte accoppiamento tra classe padre e figlia qualora questa ultima dipenda da dei metodi implementati nella classe padre.

Robert Martin infatti definisce il principio usando il polimorfismo e non l’ereditarietà, quindi usando classi figlie di interfacce e il codice può passare da una classe all’altra in base alle sue necessità (pattern Strategy).

Le interfacce sono closed for modifications in quanto non permettono alcuna implementazione al loro interno e obbligano le classi figlie ad implementare quanto serve. Queste sono quindi completamente disaccoppiate in quanto non condividono alcuna riga di codice.

Point of Variations

Un altro modo di vedere il principio OCP è utilizzare i “Point of Variation” cioè il punti del codice che è probabile debbano cambiare in futuro.

Il principio riformulato dice: Identifica i punti dove è probabile che verrà effettuata una modifica al codice e costruisci una interfaccia attorno ad essi.

Quindi per rispettare l’OCP è necessario prima identificare i PV e poi costruirci delle astrazioni attorno.

Il problema di questo approccio è cercare di capire i punti dove il codice probabilmente verrà modificato senza averne certezza. I rischi infatti sono due:

  • Aggiungere astrazioni in punti dove il codice non varierà è un costo. Questo è quanto dice principio YAGNI (You aren’t gonna need it) che suggerisce che un programmatore dovrebbe implementare codice solo quando questo effettivamente gli serve. Aggiungere astrazioni nel codice ha un costo anche di mantenimento e non utilizzarle è un ulteriore costo non necessario.
  • Non trovare i veri Point of Variations: magari le modifiche richieste saranno completamente diverse da quelle che ci aspettiamo portando quindi alla necessità di dover comunque refactorare il codice.

Il giusto approccio è quindi quello di essere consapevoli di non poter prevedere tutti i punti dove potrebbe essere necessaria una modifica al codice ma che una volta identificati, si è in grado di modificare il codice aggiungendo le giuste astrazioni.

Limiti

Come abbiamo visto per poter rispettare qusto principio è necessario utilizzare l’ereditarietà o, ancora meglio, la composizione introducendo vari livelli di astrazione in modo da ridurre l’accoppiamento tra le classi.

Questo porta a due limiti principali:

  • Vi dovrà comunque essere da qualche parte un if o uno switch che permette al software di utilizzare le nuove classi invece delle vecchie e questo switch sarà aggiunto quindi al vecchio codice (un minimo di modifica quindi vi sarà sempre);
  • Difficilmente in sede di scrittura del software andremo a creare tutti i possibili metodi con tutti i possibili parametri delle interfacce in modo che l’estensione del comportamento non porti alla modifica delle astrazioni. E’ probabile quindi che anche il più perfetto dei codici necessiti delle modifiche al vecchio codice come l’aggiunta di un metodo ad una interfaccia o un parametro a una funzione.

In ogni caso seguire il principio permette di sviluppare codice migliore, con accoppiamento minimo e grande scalabilità.

Come procedere nel mondo reale

Abbiamo visto come da un lato sia utile seguire l’OCP, dall’altro come spesso non sia semplice individuare i punti dove introdurlo.

Come procedere quindi? Di seguito qualche suggerimento:

  • Ricorda sempre il principio KISS (Keep It Simple Stupid): prevedere i Point of Variations non è semplice, non perdere tempo nell’introduzione di astrazioni non necessarie;
  • Scrivi test automatizzati: i test hanno il vantaggio che, oltre a verificare il funzionamento del codice, permettono di capire il codice dal punto di vista dell’utilizzatore e non solo del programmatore. Se il tuo codice contiene dei metodi difficilmente testabili, tipicamente questi violano l’OCP. In questi casi l’introduzione di astrazioni sarà naturale. Scrivi sempre codice che sia 100% testabile.
  • Il downcasting (castare una astrazione in una classe concreta) e sintomo di violazione dell’OCP.
  • L’operatore “is” è analogamente sintomo di violazione dell’OCP

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 ;)