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
        return participants[0];
// Use of the property:
// Instead Of:

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?


  • 1
    There is no data duplication in your example. It's just a helper function, which is a good idea in this case, since it ensures that the assumption "the first participant is the creator" is only specified in one place. May 15, 2016 at 17:37
  • There can be a meeting scheduled by a person that can't attend.
    – Basilevs
    May 16, 2016 at 4:28
  • @Basilevs - What do you mean? May 16, 2016 at 5:39
  • Is the List<User> participants private?
    – JeffO
    May 16, 2016 at 8:01
  • 1
    Your assumption is wrong. The database equivalent of the above code is a View, and different Views to the same data source are not bad in database design.
    – Doc Brown
    May 16, 2016 at 9:56

3 Answers 3


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.

  • I would add that there's an extra important factor when considering denormalisation (as opposed to caching in code): data is persistent, and denormalisation can introduce enormous risks of future data corruption, which are extremely difficult to clean up once they occur. I've suffered too much from bad DB designs decided on by neglecting this factor!!
    – SebTHU
    May 16, 2016 at 11:45

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.

  • Thanks. I would wait to see other answers before I choose the best one. Thanks again, May 15, 2016 at 10:26

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.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.