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 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:
.mw-parser-output .citazione-table{margin-bottom:.5em;font-size:95%}.mw-parser-output .citazione-table td{padding:0 1.2em 0 2.4em}.mw-parser-output .citazione-lang{vertical-align:top}.mw-parser-output .citazione-lang td{width:50%}.mw-parser-output .citazione-lang td:first-child{padding:0 0 0 2.4em}.mw-parser-output .citazione-lang td:nth-child(2){padding:0 1.2em}
«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).
Note |
^ Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In Hunt e Thomas (1999)
^ Code smells presso CodingHorror
^ Orthogonality and the DRY Principle
Bibliografia |
- Andy Hunt e Dave Thomas, The Pragmatic Programmer: From Journeyman to Master, in The Pragmatic Bookshelf, Pragmatic Programmers, 1999.
Voci correlate |
- Debito tecnico
- Riuso di codice
Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica
