-1

There is a strong argument to make objects Immutable. So should we always pine for immutability where possible, or look to the real-world when deciding whether something should be immutable?

Example: A card game. Is a "Deck of Cards" immutable? We have two choices:

  1. Deck is immutable. All methods (shuffle, deal-one) return a reference to a new deck object.
  2. Deck is mutable. All methods mutate the current deck.

It would be nice to make the deck immutable. We would gain the benefits described in the link above. But in the real world, a deck isn't immutable - we shuffle and get "the same" deck of cards but in a different order.

Community
  • 1
  • 1
djcredo
  • 1,147
  • 2
  • 10
  • 14

2 Answers2

2

You should always strive to make the best trade-offs for your scenario. There's no point in 'pining' for a certain style, just because it's in vogue, or is what the cool kids or doing. If you have heard the arguments for and against, you should be able to weigh up both options and making a decision that suits you, your codebase, and your team.

Be wary of blindly following best practices.

In terms of this specific scenario with the deck of cards, I would tend towards immutable by default, but ask myself a couple of questions before I proceed:

  • is there sufficient complexity between one occurrence of shuffling/dealing and the next? (If yes, +1 for immutable, as it can 'take a load of your mind' so to speak, in terms of potential bugs that can be introduced if you share a reference)
  • is the reference to the deck shared across threads? (If yes, +100 for immutable, as the complexity can greatly increase if you can have concurrent modifications)
  • is there memory and/or speed constraints? (If yes, +1 for a mutable deck, if you are truly resource constrained, a deck modified in place is most likely - but not guaranteed - to provide better performance, and as always, be guided by a profiler)
  • is the in-memory deck required to closely map to a real-world deck? E.g. are your users accessing/querying it in their own programs/DSL? (if yes, +1 for mutability, as it's probably closer to your user's mental model. But, that's still a definition you choose, and an immutable deck can still make sense)

It's a weasel answer I'm afraid, but you just always have to judge based on your own scenario. Sometimes designing to match the domain is more important than making your objects immutable. Other times it's not, and it's worth forgetting the domain while you make a programming choice - remember your domain rarely has to care or model a lot of things we programmers deal with on a day-to-day basis. In other scenarios with other constraints you might just have to give up both!

Grundlefleck
  • 124,925
  • 25
  • 94
  • 111
0

Immutability allows an object to be treated and viewed like a value. A card is a good candidate for immutability, since it doesn't really need to be modified after.

See this article to help decide where and when to use mutable/immutable classes IBM - Java theory and practice: To mutate or not to mutate?.

Keldon Alleyne
  • 2,103
  • 16
  • 23