问题
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?
回答1:
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:
- Immutability in C# Part One: Kinds of Immutability
- Immutability in C# Part Two: A Simple Immutable Stack
- Immutability in C# Part Three: A Covariant Immutable Stack
- Immutability in C# Part Four: An Immutable Queue
- Immutability in C# Part Five: LOLZ!
- Immutability in C# Part Six: A Simple Binary Tree
- Immutability in C# Part Seven: More on Binary Trees
- Immutability in C# Part Eight: Even More On Binary Trees
- Immutability in C# Part Nine: Academic? Plus my AVL tree implementation
- Immutability in C# Part Ten: A double-ended queue
- Immutability in C# Part Eleven: A working double-ended queue
回答2:
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.
回答3:
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.
回答4:
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.
回答5:
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).
回答6:
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.
回答7:
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.
回答8:
You could define your public interface as IEnumerable, but still use a mutable collection in your implementation.
回答9:
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.
回答10:
If you have a collection to which you can add items after constructing it, it is not immutable
来源：https://stackoverflow.com/questions/927181/immutable-collections