Is data duplication bad in programming (in contrast to database designing)?

Question

I have three classes: User, Conversation and Message:

Message properties:

User sender;
// Some more

Conversation properties:

List<Message> messages;
List<User> participants;
// Some more

I want to show in the program the creator of the conversation. I wonder if It is bad programming to add a creator property to the Conversation class, so I could access it easily and the code would become more readable.:

List<Message> messages;
List<User> participants;
User creator
{
    get
    {
        return participants[0];
    }
}
// Use of the property:
conversationObj.creator;
// Instead Of:
conversation.participants[0];

Is it considered data duplication because I could get it directly from the participants property? Or data duplication is wrong only when designing a database?

Thanks.

Answer 1

It isn't duplication of data in the sense of denormalization; all it is, is an extra accessor method.

Duplication of data in the sense of denormalization or caching (another way to describe denormalization) would involve an instance field that captures participant[0].

This particular implementation, having an explicit getter and no setter, is not provided with a backing field (automatic by the language or manual by you); the getter code is executed each time. Therefore it is not duplication of data.

---

I would equate arguments for denormalization in the database to caching in code: it is commonly done for performance, but as @Jörg says, makes the system more error prone now and also for future maintenance. Further, caching / denormalization have storage costs and computational costs as well. So, like all optimization, caching / denormalization should be applied when we have measureable tests that demonstrate good understanding of the problem and that the solution results in improvement.

Answer 2

I wouldn't say that there is a definite answer here. In this case, I would definitely agree with that getter, because conversation.creator is semantically more meaningful than conversation.participants[0] and it helps with writing self-documenting code.

Answer 3

There are actually two questions here:

Is this data duplication?

No. No data is being duplicated. You are just providing another reference to already existing data. Think of it this way: it doesn't matter if you tell someone the address to your house or you describe the position of your house relative to some landmark, both descriptions still end up at the same house.

Is data duplication bad?

No. Getting it right is hard, which is why it is commonly avoided, but it is not bad.

Have you ever heard of caching? That's data duplication right there. Database indices? Data duplication.

What is bad is confusing the provenance of the data.

You may have multiple copies of data, but it should always be clear which is the authoritative one. (As soon as you have multiple copies of data, you run into all sorts of trouble, such as keeping them in sync, invalidating them if the authoritative copy changes etc. This is hard, but it is not inherently bad. If you have a lazy evening, try reading up on multi-CPU cache coherency protocols to get a sense of just how really hard it is.)