Неизменные наборы?

Мой любимый трюк с коллекциями - просто никогда не передавать их. Если они существуют только внутри одного объекта, то сделать их неизменяемыми в большинстве случаев не имеет значения (пока ваш содержащий объект не меняет их, они не изменятся).

Обычно ваша коллекция что-то представляет, не так ли? Это собрание собак или собрание счетов-фактур ...

Обычно есть что-то, что можно сделать со сбором собак (стадо? Кастрированный?) Или сбором счетов-фактур (оплата?). Практически всегда есть операции, которые применять ко всему списку объектов - операции, функциональность которых выходит за рамки единственного invoice.pay () (например, обеспечение того, чтобы в первую очередь были оплачены наиболее важные счета), без класса вокруг вашей коллекции действительно некуда поместить те операции.

Я согласен с комментариями Эрика о выборе правильного инструмента для решения проблемы. Неизменяемость повышает ценность, когда в ваши цели входит обеспечение четкой семантики идентичности или упрощение работы с вашей реализацией в среде параллельных вычислений. Неизменяемость также может помочь повысить производительность, допуская такие оптимизации, как кэширование или прозрачное проксирование.

С другой стороны, неизменяемость также может повлечь за собой снижение производительности, особенно когда вы используете шаблон «копирование при записи» для моделирования »изменений. ".

Вы должны решить , почему вы хотите, чтобы ваши сущности / коллекции были неизменными - и это поможет вам решить, делать это или нет.

Если вы добавляете / удаляете только в начале или в конце, вы можете обмануть - но в целом; да: подразумевается, что вам нужно создавать новую коллекцию для каждого изменения.

Итак: вам нужно (эффективно) изменять коллекции? Если это так, и учитывая их размер: у меня возникнет соблазн взглянуть на синхронизацию доступа (вместо того, чтобы сделать их должным образом неизменяемыми). Посмотрите на замок (он же Монитор ).

Таблица поиска могла бы создать приличную неизменяемую коллекцию. Его не нужно менять в размере, и вы хотите, чтобы он был статичным, чтобы можно было быстро выполнять сложные вычисления. Если вам понадобится что-то добавить позже, я бы не стал беспокоиться о неизменности, это противоречит цели.

Если у вас есть коллекция, в которую вы можете добавлять элементы после ее создания, она не является неизменной

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.

Все зависит от того, кто использует коллекции одновременно. Строки неизменяемы, чтобы предотвратить попытки двух потоков одновременно удалить первый символ.