Articoli di programmazione
Principi SOLID: datemi una L! Liskov Substitution Principle
I 5 principi SOLID della programmazione a oggetti fungono da base per progettare sistemi robusti e manutenibili. Vediamo il terzo principio: L ovvero Liskov Substitution 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.
Liskov Substitution Principle non indica che Liskov, il terzino della Dynamo Kiev, debba essere sostituito prima della fine del primo tempo! Questo è un principio estremamente chiaro per chi programma ad oggetti: ogni sotto-classe deve essere sostituibile alla propria super-classe e garantire ugualmente il funzionamento del sistema.
Questo implica che ogni sotto-classe nella fase di estensione della propria super-classe, debba garantire alcune cose:
- i metodi pubblici della super-classe, se sovrascritti dalla sotto-classe, devono garantire che la logica applicativa sia rispettata
- le regole di validazione nei metodi sovrascritti nella sotto-classe devono essere ugualmente o meno stringenti di quelli della super-classe, altrimenti si rischia di far lanciare eccezioni dopo la sostituzione
- similarmente al punto precedente, i valori di ritorno degli eventuali metodi sovrascritti devono rispettare le stesse regole o regole più ristrette di quelle della super-classe
- non devono essere introdotte nuove eccezioni non presenti nella super-classe
Anche se sembra pacifico e semplice poter rispettare questo principio, di fatto questo non è così scontato. Si verificano sovente delle situazioni per cui una sotto-classe, per sua natura si veda costretta a contravvenire a questo principio.
Facciamo un esempio con una classe Quadrato che erediti direttamente da una classe Rettangolo. La sola differenza tra le due classi è che nella creazione di Quadrato, impongo la larghezza uguale all'altezza, pena il lancio di un'eccezione. Adesso se sostituisco Quadrato dove era in uso Rettangolo, al momento della creazione della mia istanza ricevo un'eccezione perché le due dimensioni, larghezza ed altezza, non sono uguali.
#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.
Liskov Substitution Principle non indica che Liskov, il terzino della Dynamo Kiev, debba essere sostituito prima della fine del primo tempo! Questo è un principio estremamente chiaro per chi programma ad oggetti: ogni sotto-classe deve essere sostituibile alla propria super-classe e garantire ugualmente il funzionamento del sistema.
Questo implica che ogni sotto-classe nella fase di estensione della propria super-classe, debba garantire alcune cose:
- i metodi pubblici della super-classe, se sovrascritti dalla sotto-classe, devono garantire che la logica applicativa sia rispettata
- le regole di validazione nei metodi sovrascritti nella sotto-classe devono essere ugualmente o meno stringenti di quelli della super-classe, altrimenti si rischia di far lanciare eccezioni dopo la sostituzione
- similarmente al punto precedente, i valori di ritorno degli eventuali metodi sovrascritti devono rispettare le stesse regole o regole più ristrette di quelle della super-classe
- non devono essere introdotte nuove eccezioni non presenti nella super-classe
Anche se sembra pacifico e semplice poter rispettare questo principio, di fatto questo non è così scontato. Si verificano sovente delle situazioni per cui una sotto-classe, per sua natura si veda costretta a contravvenire a questo principio.
Facciamo un esempio con una classe Quadrato che erediti direttamente da una classe Rettangolo. La sola differenza tra le due classi è che nella creazione di Quadrato, impongo la larghezza uguale all'altezza, pena il lancio di un'eccezione. Adesso se sostituisco Quadrato dove era in uso Rettangolo, al momento della creazione della mia istanza ricevo un'eccezione perché le due dimensioni, larghezza ed altezza, non sono uguali.
#programmazione #solid