CODEWITHSUNDEEP
c#.netimmutability
Joan Venge
Joan Venge

Reputation: 331052

Immutable collections?

I am making most of my basic types in my app, immutable. But should the collections be immutable too? To me, this seems like a huge overhead unless I am missing something.

I am talking about collections to hold Point3 values, etc which can be added as it goes at different times. So if there are 1M values in a collection, and you needed to delete 1 of them, you would have to create the same collection all over again, right?

Upvotes: 26

Views: 20100

Answers (10)

Joel Coehoorn
Joel Coehoorn

Reputation: 415820

Eric Lippert has a series on Immutability in C#, and if you read it all the way through he implements a couple different immutable collections:

  1. Immutability in C# Part One: Kinds of Immutability
  2. Immutability in C# Part Two: A Simple Immutable Stack
  3. Immutability in C# Part Three: A Covariant Immutable Stack
  4. Immutability in C# Part Four: An Immutable Queue
  5. Immutability in C# Part Five: LOLZ!
  6. Immutability in C# Part Six: A Simple Binary Tree
  7. Immutability in C# Part Seven: More on Binary Trees
  8. Immutability in C# Part Eight: Even More On Binary Trees
  9. Immutability in C# Part Nine: Academic? Plus my AVL tree implementation
  10. Immutability in C# Part Ten: A double-ended queue
  11. Immutability in C# Part Eleven: A working double-ended queue

Upvotes: 36

Bill K
Bill K

Reputation: 62769

My favorite trick with collections is simply to never pass them around. If they only exist inside a single object, then making them immutable is mostly irrelevant (As long as your containing object doesn't change them then they won't change).

Usually your collection represents something, right? It's a collection of dogs or a collection of invoices...

Usually there is a thing you can do with a collection of dogs (Herd? neuter?) or a collection of invoices (pay?) There are virtually always operations that apply to the whole list of objects--operations that have functionality beyond the singular invoice.pay() (for instance, ensuring that the most important invoices are paid first), without a class around your collection, there is really no where to put those operations.

It also usually makes sense to have a few variables associated with your collection--and again without a wrapper you always end up putting those variables in some strange unnatural location.

It may seem strange at first but try it a couple times before you judge.

Upvotes: 9

Andrew Arnott
Andrew Arnott

Reputation: 81801

Immutable collections are great, especially if your app already leverages immutable types or semantics.

.NET just shipped their first immutable collections, which I suggest you try out.

Upvotes: 16

James L
James L

Reputation: 16864

You could define your public interface as IEnumerable, but still use a mutable collection in your implementation.

Upvotes: 1

Dario
Dario

Reputation: 49218

It depends on the style your program is written/designed.

Immutable collection do only make sense when you're programming in a functional-programming-influenced style (Imperatively designed programs shouldn't use them).

And like in functional languages, you should use Linked Lists then which can be built up in O(1) per element (cons) and process them functionally (recursions, building new lists from lists).

When your program requires imperative collections (arrays, vectors/lists), keep them mutable.

Upvotes: 0

Marc Gravell
Marc Gravell

Reputation: 1062855

If you only ever add/remove from the start or end you might be able to cheat - but in general; yes: the implication is that you need to create a new collection for every change.

So: do you need to (effectively) mutate collections? If so, and given their size: I'd be tempted to look at synchronizing access (rather than making them properly immutable). Look at lock (aka Monitor).

Upvotes: 2

LBushkin
LBushkin

Reputation: 131676

I agree with Eric's comments about choosing the right tool for the problem. Immutability adds value when your goals include providing clear identity semantics, or making your implementation easier to work with in a parallel computing environment. Immutability can also help improve performance by allowing optimizations such as caching or transparent proxying.

On the flip-side, immutability can also incur a performance cost - particularly when you use the "copy-on-write" pattern to model "changes".

You have to decide why you want your entities/collections to be immutable - and that will help drive your decision of whether to do so or not.

Upvotes: 2

Dan Blair
Dan Blair

Reputation: 2381

A look up table would make for a decent immutable collection. It doesn't need to change in size and you want it static so it's quick to look up tricky calculations. If you need to add something later then I wouldn't bother with immutability, it defeats the purpose.

Upvotes: 0

Steef
Steef

Reputation: 34665

If you have a collection to which you can add items after constructing it, it is not immutable

Upvotes: -2

n8wrl
n8wrl

Reputation: 19765

It all depends on who is using the collections at the same time. Strings are immutable to prevent boo-boo's like two threads trying to remove the first char at the same time.

Upvotes: -1

Related Questions