utile leggerlo ogni tanto per acquisire la forma mentis
I principi SOLID sono cinque principi fondamentali della programmazione orientata agli oggetti (OOP) che mirano a rendere il software più manutenibile, flessibile e facile da comprendere. Rappresentano buone pratiche di progettazione del software. I cinque principi sono:
Principio di Responsabilità Unica
- Ogni classe dovrebbe avere una sola responsabilità o un unico motivo per cambiare.
- Questo significa che ogni classe dovrebbe fare solo una cosa e farla bene.
- La separazione delle responsabilità aiuta a evitare il codice monolitico e facilita la manutenzione del software.
Esempio: Se hai una classe
Ordine che gestisce sia la logica di business dell'ordine che la sua persistenza nel database, questo viola il principio di responsabilità unica. Dovresti separare queste responsabilità in diverse classi (GestioneOrdine e RepositoryOrdine).Principio Aperto/Chiuso
- Il codice dovrebbe essere aperto all'estensione ma chiuso alla modifica.
- Questo significa che puoi estendere il comportamento di una classe senza modificarne il codice esistente. Questo può essere fatto usando l'ereditarietà o le interfacce.
Esempio: Se hai una classe
Forma e desideri aggiungere nuove forme (come Cerchio o Quadrato), puoi aggiungere nuove classi derivate piuttosto che modificare la classe Forma esistente.Principio di Sostituzione di Liskov
- Le sottoclassi devono poter essere utilizzate ovunque sia presente la classe base, senza rompere il corretto funzionamento del programma.
- In altre parole, gli oggetti di una sottoclasse devono poter sostituire quelli della classe base senza introdurre errori o comportamenti inattesi.
Esempio: Se
Quadrato eredita da Rettangolo, ma non riesce a comportarsi come un Rettangolo in tutte le situazioni (ad esempio, Quadrato ha larghezza e altezza uguali), ciò viola il principio di Liskov. La sottoclasse dovrebbe comportarsi coerentemente con la classe base.Principio di Segregazione delle Interfacce
- Le interfacce non dovrebbero costringere le classi ad implementare metodi di cui non hanno bisogno.
- È meglio avere più interfacce specifiche e piccole piuttosto che una grande interfaccia generica. Questo aiuta a mantenere il codice più semplice e meno ingombrante.
Esempio: Supponiamo di avere un'interfaccia
Animale con metodi come vola(), nuota(), e cammina(). Se una classe Cane deve implementare vola() senza un significato utile, questa è una violazione del principio. Dovresti avere interfacce specifiche come Volante, Nuotatore, Camminatore, ecc.Principio di Inversione delle Dipendenze
- Le classi di alto livello non dovrebbero dipendere dalle classi di basso livello, entrambe dovrebbero dipendere da astrazioni.
- Le dipendenze dovrebbero essere invertite, cioè il codice non dovrebbe dipendere da implementazioni concrete, ma piuttosto da astrazioni come interfacce o classi astratte.
Esempio: Invece di avere una classe
Ordine che dipende direttamente da una classe DatabaseMySQL, sarebbe meglio che Ordine dipendesse da un'interfaccia Database che può essere implementata da diverse classi (DatabaseMySQL, DatabasePostgreSQL, ecc.). Questo consente di sostituire facilmente l'implementazione del database.Recap: SOLID
- S: Single Responsibility Principle – Una classe, una responsabilità.
- O: Open/Closed Principle – Aperto all'estensione, chiuso alla modifica.
- L: Liskov Substitution Principle – Le sottoclassi possono sostituire le classi base.
- I: Interface Segregation Principle – Interfacce specifiche e piccole.
- D: Dependency Inversion Principle – Dipendenza da astrazioni, non da implementazioni.
Made with Bullet