Articoli di programmazione
Principi SOLID: datemi una D! Dependency Inversion Principle
I 5 principi SOLID della programmazione a oggetti fungono da base per progettare sistemi robusti e manutenibili. Vediamo il quinto principio: D ovvero Dependency Inversion 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.
Dependency Inversion Principle afferma che i componenti di alto livello applicativo non dovrebbero essere direttamente dipendenti dai componenti di basso livello. E' consigliabile prima di tutto far dipendere i componenti di alto livello da alcune interfacce astratte, successivamente generare i componenti di basso livello come implementazioni di queste interfacce astratte. L'inversione di dipendenza si ottiene così, semplicemente evitando che nella piramide applicativa i componenti al vertice referenzino quelli alla base. Tutti referenziano le interfacce astratte che di fatto sono un modulo esterno, evitando un flusso di dipendenze che va dall'alto verso il basso.
Per evitare riferimenti circolari tra i progetti che contengono i componenti di alto e basso livello, è consigliato porre le interfacce astratte in un progetto a sé, dedicato esclusivamente alla definizione delle interfacce in uso nel sistema. Entrambi i progetti delle classi di alto e basso livello, dovranno referenziare il progetto esterno delle interfacce astratte: il primo progetto le utilizzerà, mentre il secondo le implementerà.
#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.
Dependency Inversion Principle afferma che i componenti di alto livello applicativo non dovrebbero essere direttamente dipendenti dai componenti di basso livello. E' consigliabile prima di tutto far dipendere i componenti di alto livello da alcune interfacce astratte, successivamente generare i componenti di basso livello come implementazioni di queste interfacce astratte. L'inversione di dipendenza si ottiene così, semplicemente evitando che nella piramide applicativa i componenti al vertice referenzino quelli alla base. Tutti referenziano le interfacce astratte che di fatto sono un modulo esterno, evitando un flusso di dipendenze che va dall'alto verso il basso.
Per evitare riferimenti circolari tra i progetti che contengono i componenti di alto e basso livello, è consigliato porre le interfacce astratte in un progetto a sé, dedicato esclusivamente alla definizione delle interfacce in uso nel sistema. Entrambi i progetti delle classi di alto e basso livello, dovranno referenziare il progetto esterno delle interfacce astratte: il primo progetto le utilizzerà, mentre il secondo le implementerà.
#programmazione #solid