Quanti principi ci sono nei design pattern?
Categories:
I principi dei design pattern sono stati inizialmente riassunti in 5, ovvero SOLID:
Principio di responsabilità singola (Single Responsibility Principle, SRP): una classe dovrebbe avere una sola ragione di cambiamento, ovvero una sola responsabilità.Principio aperto/chiuso (Open/Closed Principle, OCP): le entità software (classi, moduli, funzioni ecc.) dovrebbero essere aperte all’estensione ma chiuse alla modifica, ovvero si dovrebbe realizzare il cambiamento tramite estensione e non tramite modifica del codice esistente.Principio di sostituzione di Liskov (Liskov Substitution Principle, LSP): i sottotipi devono essere in grado di sostituire i loro tipi base, ovvero le classi derivate devono essere in grado di sostituire le loro classi base senza influire sulla correttezza del programma.Principio di segregazione delle interfacce (Interface Segregation Principle, ISP): i client non dovrebbero essere costretti a dipendere da interfacce che non utilizzano. Le interfacce grandi dovrebbero essere suddivise in interfacce più piccole e specifiche, in modo che i client conoscano solo i metodi che devono utilizzare.Principio di inversione delle dipendenze (Dependency Inversion Principle, DIP): i moduli di alto livello non dovrebbero dipendere dai moduli di basso livello, entrambi dovrebbero dipendere dalle astrazioni. Le astrazioni non dovrebbero dipendere dai dettagli di implementazione, i dettagli di implementazione dovrebbero dipendere dalle astrazioni.
Successivamente sono stati aggiunti due principi, questi ultimi sono più specifici e hanno una maggiore capacità guida. Possiamo vedere dalle spiegazioni dei principi che SOLID descrive “cosa si dovrebbe fare”, mentre i principi aggiunti successivamente descrivono “cosa è preferibile fare”.
Principio di riutilizzo tramite composizione/aggregazione (Composition/Aggregation Reuse Principle, CARP): si dovrebbe dare la priorità all’uso della composizione e aggregazione degli oggetti, piuttosto che dell’ereditarietà, per raggiungere l’obiettivo del riutilizzo del codice.Legge di Demetra (Law of Demeter, LoD): un oggetto dovrebbe conoscere il meno possibile degli altri oggetti, ovvero un oggetto dovrebbe conoscere il meno possibile della struttura interna e dei dettagli di implementazione degli altri oggetti.
Oltre ai principi di progettazione sopra menzionati, ci sono anche altri principi di progettazione che, sebbene non siano così noti come quelli menzionati in precedenza, hanno comunque un importante ruolo guida per la progettazione e l’architettura del software. Alcuni principi proposti successivamente sono un po’ superflui, almeno secondo me non sono controintuitivi e non richiedono un approfondimento.
Principio della conoscenza minima (Principle of Least Knowledge, PoLK): noto anche come estensione della Legge di Demetra, sostiene che un oggetto dovrebbe conoscere il meno possibile delle informazioni degli altri oggetti. L’origine di questo principio può essere fatta risalire alla “legge della comunicazione minima” proposta nel 1987 da Patricia Lago e Koos Visser.Principio della dipendenza stabile (Stable Dependencies Principle, SDP): questo principio afferma che la progettazione software dovrebbe garantire che i componenti stabili non dipendano dai componenti instabili, ovvero i componenti con maggiore stabilità dovrebbero dipendere meno dai componenti con minore stabilità. Questo principio deriva da approfonditi studi sulle relazioni tra i componenti all’interno dei sistemi software.Principio dell'astrazione stabile (Stable Abstraction Principle, SAP): in armonia con il principio della dipendenza stabile, questo principio guida l’allineamento tra astrazione e stabilità, ovvero i componenti stabili dovrebbero essere astratti e i componenti instabili dovrebbero essere concreti. Questo principio aiuta a garantire la stabilità e la flessibilità del sistema software.