La duplicazione dei dati è errata nella programmazione (a differenza della progettazione di database)?

Non è una duplicazione di dati nel senso di denormalizzazione; tutto ciò che è, è un metodo accessorio aggiuntivo.

La duplicazione di dati nel senso di denormalizzazione o memorizzazione nella cache (un altro modo per descrivere la denormalizzazione) coinvolgerebbe un campo di istanza che cattura participant[0] .

Questa particolare implementazione, con un getter esplicito e nessun setter, non è fornita con un backing field (automatico dalla lingua o dal manuale dell'utente); il codice getter viene eseguito ogni volta. Pertanto non è la duplicazione dei dati.

Vorrei equiparare gli argomenti per la denormalizzazione nel database al caching nel codice: è comunemente fatto per le prestazioni, ma come dice @ Jörg, rende il sistema più incline agli errori ora e anche per la manutenzione futura. Inoltre, il caching / denormalizzazione ha costi di storage e costi computazionali. Quindi, come tutte le ottimizzazioni, la caching / denormalizzazione dovrebbe essere applicata quando abbiamo test misurabili che dimostrano una buona comprensione del problema e che la soluzione risulta in miglioramento.

Non direi che c'è una risposta definitiva qui. In questo caso, sarei sicuramente d'accordo con quel getter, perché conversation.creator è semanticamente più significativo di conversation.participants[0] e aiuta a scrivere il codice di auto-documentazione.

Ci sono in realtà due domande qui:

Is this data duplication?

No. Nessun dato viene duplicato. Stai solo fornendo un altro riferimento a dati già esistenti. Pensaci in questo modo: non importa se dici a qualcuno l'indirizzo di casa tua o descrivi la posizione della tua casa rispetto a qualche punto di riferimento, entrambe le descrizioni finiscono comunque nella stessa casa.

Is data duplication bad?

No. La cosa giusta è difficile , motivo per cui è comunemente evitato, ma non è male.

Hai mai sentito parlare di cache? Questa è la duplicazione dei dati proprio lì. Indici del database? Duplicazione dei dati.

Ciò che è cattivo sta confondendo la provenienza dei dati.

Potresti avere più copie di dati, ma dovrebbe sempre essere chiaro che è autorevole . (Non appena hai più copie di dati, ti imbatti in tutti i tipi di problemi, come tenerli sincronizzati, invalidarli se la copia autorevole cambia, ecc. Questo è difficile , ma non è intrinsecamente cattivo. Se hai una serata pigra, prova a leggere su protocolli di coerenza della cache multi-CPU per avere un'idea di quanto sia veramente difficile.)