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:

«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 WETModifica

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][6]

NoteModifica

  1. ^ Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In Hunt e Thomas (1999)
  2. ^ Code smells presso CodingHorror
  3. ^ Orthogonality and the DRY Principle
  4. ^ Justin Lee (2006-03-08)., 4.. URL consultato il 31 agosto 2013.
  5. ^ Alex Papadimoulis (2011-12-08), "The WET Cart". URL consultato il 21 maggio 2012.
  6. ^ Kevin Greer (2016-02-05), "FOAM DRY + WET". URL consultato il 9 marzo 2016.

BibliografiaModifica

  • Andy Hunt e Dave Thomas, The Pragmatic Programmer: From Journeyman to Master, in The Pragmatic Bookshelf, Pragmatic Programmers, 1999.

Voci correlateModifica

  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica