Articoli di programmazione
Principi SOLID: datemi una I! Interface Segregation Principle
I 5 principi SOLID della programmazione a oggetti fungono da base per progettare sistemi robusti e manutenibili. Vediamo il quarto principio: I ovvero Interface Segregation 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.
Interface Segregation principle afferma che un client non dovrebbe dipendere da metodi che non usa, per cui è preferibile creare molte piccole interfacce specializzate, anziché poche interfacce generiche. Di fatto ogni interfaccia deve esporre pochi metodi collegati logicamente tra loro, che servano ad uno scopo comune.
Questo principio si collega al Single Responsibility Principle e sottolinea come anche nelle interfacce si debba sempre seguire la regola dell'isolamento delle logiche e della separazione dei fini.
Certamente un oggetto può decidere di implementare più interfacce e, per certi versi in molti sistemi questo ha senso, ma solo se non cozza con Single responsibility principle.
Di fatto Interface Segregation principle ci invita a scrivere tante piccole interfacce specializzate, invece di poche grandi interfacce generiche. Corollario ne è la regola d'oro: scrivi il minimo indispensabile, usa il minimo indispensabile.
Come sempre: dividi et impera.
#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.
Interface Segregation principle afferma che un client non dovrebbe dipendere da metodi che non usa, per cui è preferibile creare molte piccole interfacce specializzate, anziché poche interfacce generiche. Di fatto ogni interfaccia deve esporre pochi metodi collegati logicamente tra loro, che servano ad uno scopo comune.
Questo principio si collega al Single Responsibility Principle e sottolinea come anche nelle interfacce si debba sempre seguire la regola dell'isolamento delle logiche e della separazione dei fini.
Certamente un oggetto può decidere di implementare più interfacce e, per certi versi in molti sistemi questo ha senso, ma solo se non cozza con Single responsibility principle.
Di fatto Interface Segregation principle ci invita a scrivere tante piccole interfacce specializzate, invece di poche grandi interfacce generiche. Corollario ne è la regola d'oro: scrivi il minimo indispensabile, usa il minimo indispensabile.
Come sempre: dividi et impera.
#programmazione #solid