Don't repeat yourself
In ingegneria del software, il principio don't repeat yourself ("non ripeterti"), spesso abbreviato in DRY e noto anche come "Single point of truth" ("singolo punto di verità") è un principio di progettazione e sviluppo software secondo cui andrebbe evitata ogni forma di ripetizione e ridondanza logica nell'implementazione di un sistema software. Il principio venne inizialmente enunciato da Andy Hunt e Dave Thomas nel loro libro The Pragmatic Programmer:
«Ogni elemento di conoscenza deve avere una sola, non ambigua, autorevole rappresentazione all'interno di un sistema.[1]»
Il DRY viene spesso citato in relazione al code smell della duplicazione del codice,[2] ovvero nell'accezione stretta secondo cui il software non dovrebbe contenere sequenze di istruzioni uguali fra loro. Si tratta però di un concetto più ampio, che si applica a ogni parte di un sistema software, inclusi per esempio schemi di database, direttive di build, file di configurazione, e persino alla documentazione.[3] L'applicazione completa del DRY implica logicamente che una modifica a un singolo elemento di un sistema non debba mai comportare la necessità di modificare altre parti di un sistema per replicare in altri luoghi i contenuti della modifica stessa.
L'applicazione del DRY è particolarmente complessa (e significativa) in architetture multi-tier, in cui la stessa informazione è gestita a diversi livelli (per esempio interfaccia utente, logica dell'applicazione, database) attraverso diverse tecnologie. Questo rende particolarmente difficile evitare la duplicazione dell'informazione nei diversi livelli. Gli approcci possibili all'applicazione del DRY in questi contesti prevedono in genere l'uso di strumenti automatici per generare diversi artefatti (per esempio codice in diversi linguaggi e schemi di database) a partire da un'unica rappresentazione di partenza, per esempio un modello dei dati espresso in UML (Model-driven architecture).
Soluzioni DRY vs soluzioni WET modifica
Le violazioni del DRY sono tipicamente indicate come soluzioni WET, che si ritiene stia solitamente a significare "write every time", "write everything twice", "we enjoy typing" o "waste everyone's time". Le soluzioni WET sono comuni nelle architetture multi-livello in cui uno sviluppatore può essere incaricato, ad esempio, di aggiungere un campo di commento su un modulo in un'applicazione web. La stringa di testo "commento" potrebbe essere ripetuta nell'etichetta, nel tag HTML, nella funzione di lettura nome, in una variabile privata, nel database DDL, nelle domande, e così via. Un approccio DRY elimina tale ridondanza utilizzando framework che riducono o eliminano tutte le attività di modifica tranne quelle più importanti, lasciando l'estensibilità di aggiungere nuove variabili di conoscenza invariata.[4][5]
Note modifica
- ^ Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In Hunt e Thomas (1999)
- ^ Code smells Archiviato il 18 gennaio 2013 in Internet Archive. presso CodingHorror
- ^ Orthogonality and the DRY Principle
- ^ Alex Papadimoulis, "The WET Cart", 8 dicembre 2011. URL consultato il 21 maggio 2012.
- ^ Kevin Greer, "FOAM DRY + WET", 5 febbraio 2016. URL consultato il 9 marzo 2016.
Bibliografia modifica
- Andy Hunt e Dave Thomas, The Pragmatic Programmer: From Journeyman to Master, collana The Pragmatic Bookshelf, Pragmatic Programmers, 1999.
