Articoli di programmazione
Principi SOLID: datemi una O! Open/Closed Principle
I 5 principi SOLID della programmazione a oggetti fungono da base per progettare sistemi robusti e manutenibili. Vediamo il secondo principio: O ovvero Open/Closed 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.
Open/closed principle è prima di tutto un principio estremamente generico. Non si riferisce solo alle classi, ma a anche ad altri elementi. Asserisce che ogni elemento che si tratti di classe, funzione o modulo, debba essere aperto ad eventuali estensioni, cioè permetta eventualmente di essere riutilizzato o richiamato per contribuire allo svolgimento di operazioni più articolate. Allo stesso tempo questo elemento deve essere chiuso ad eventuali modifiche dall'esterno. Questo implica che l'elemento debba essere imperturbabile, cioè "stare in piedi da solo", ovvero costituisca un sistema chiuso, funzionante di per sé e non permetta ad elementi esterni di interferire con la propria logica interna.
Un esempio di questo principio è visibile nella View in React e React Native.
Ogni View è una funzione chiusa: restituisce gli elementi della UI da visualizzare e non lascia che elementi esterni alla funzione interferiscano con il proprio lavoro. Il suo output non dipende da altri oggetti esterni non referenziati nella funzione.
Allo stesso tempo è possibile combinare più View insieme, assemblandole per costruire interfacce utente più ricche e funzionali. Da sottolineare che queste View sono sistemi chiusi perché non è necessario intervenire nel loro codice interno per fargli supportare questo processo di creazione a mosaico. Ogni singola View è un mattone e contribuisce a creare un muro. Nel processo di creazione di questo muro, qualunque esso sia, il comportamento della singola View non cambia.
Nella programmazione a oggetti si ritrova spesso questo principio collegato all'ereditarietà, dove la Super-Classe costituisce un sistema chiuso, nel senso di ben definito e funzionante: imperturbabile e deterministico. Allo stesso tempo questa Super-Classe è un sistema aperto perché è possibile ereditare da essa ed estenderla. E la cosa più importante è che non deve essere necessario modificare la Super-Classe quando ne implementiamo delle sotto-classi.
#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.
Open/closed principle è prima di tutto un principio estremamente generico. Non si riferisce solo alle classi, ma a anche ad altri elementi. Asserisce che ogni elemento che si tratti di classe, funzione o modulo, debba essere aperto ad eventuali estensioni, cioè permetta eventualmente di essere riutilizzato o richiamato per contribuire allo svolgimento di operazioni più articolate. Allo stesso tempo questo elemento deve essere chiuso ad eventuali modifiche dall'esterno. Questo implica che l'elemento debba essere imperturbabile, cioè "stare in piedi da solo", ovvero costituisca un sistema chiuso, funzionante di per sé e non permetta ad elementi esterni di interferire con la propria logica interna.
Un esempio di questo principio è visibile nella View in React e React Native.
Ogni View è una funzione chiusa: restituisce gli elementi della UI da visualizzare e non lascia che elementi esterni alla funzione interferiscano con il proprio lavoro. Il suo output non dipende da altri oggetti esterni non referenziati nella funzione.
Allo stesso tempo è possibile combinare più View insieme, assemblandole per costruire interfacce utente più ricche e funzionali. Da sottolineare che queste View sono sistemi chiusi perché non è necessario intervenire nel loro codice interno per fargli supportare questo processo di creazione a mosaico. Ogni singola View è un mattone e contribuisce a creare un muro. Nel processo di creazione di questo muro, qualunque esso sia, il comportamento della singola View non cambia.
Nella programmazione a oggetti si ritrova spesso questo principio collegato all'ereditarietà, dove la Super-Classe costituisce un sistema chiuso, nel senso di ben definito e funzionante: imperturbabile e deterministico. Allo stesso tempo questa Super-Classe è un sistema aperto perché è possibile ereditare da essa ed estenderla. E la cosa più importante è che non deve essere necessario modificare la Super-Classe quando ne implementiamo delle sotto-classi.
#programmazione #solid