Какова логика наличия изменяемых и неизменяемых версий классов, таких как NSArray, NSDictionary и т. д., в Objective C?

Неизменяемые версии классов существуют потому, что неизменяемый объект сам по себе является уникальным идентификатором определенного состояния. т.е. если у вас есть NSArray из 100 экземпляров NSString, этот экземпляр NSArray можно рассматривать как идемпотент для любой из этих строк.

Кроме того, неизменность означает, что изменение не может произойти после того, как состояние было продано. Например, метод subviews NSView возвращает неизменяемый массив, таким образом гарантируя, что вызывающая сторона не будет играть в игры с содержимым (и даже не ожидает, что сможет). Внутренне NSView может выбрать возврат [вероятного] NSMutableArray, который содержит подпредставления (поскольку он является внутренне изменяемым), а приведение типа к NSArray означает, что вызывающая сторона не может манипулировать содержимым без злого приведения или плохого предупреждение компилятора. (Это может быть или не быть реальной реализацией, кстати, но этот шаблон используется в другом месте).

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

В общем, для API неизменяемый класс будет потокобезопасным, поэтому вы можете читать его непосредственно в фоновом потоке, не беспокоясь о том, что содержимое изменится...

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

Почему общие классы коллекций в Objective C, такие как NSString, NSArray, NSDictionary и т. д., имеют как изменяемую, так и неизменную версию.

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

Какова логика определения их отдельно?

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

поэтому для класса принято определять неизменность и изменчивость и предоставлять варианты, которые отличают изменчивость.

несколько абстракций также вводят безопасность типов и намерение.

Представление

да. существует несколько оптимизаций, которые может сделать инвариантный объект.

некоторые случаи включают:

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

управление памятью

некоторые случаи включают:

• неизменяемые типы могут делиться своим неизменяемым содержимым.
• они также могут сократить ассигнования. например, реализация copyWithZone: или initWithType: может возвращать сохраненный исходный код, а не глубокую или поверхностную физическую копию.

или что-нибудь еще?

это упрощает написание понятных интерфейсов. вы можете гарантировать и (попытаться) ограничить некоторые вещи. если бы все было изменчивым, было бы гораздо больше ошибок и особых случаев. на самом деле это различие может полностью изменить наш подход к написанию библиотек objc:

[[textField stringValue] appendString:@" Hz"];
[textField stateDidChange];

так что приятно иметь возможность передавать объекты, не беспокоясь о том, что клиент изменится за вашей спиной, избегая при этом копирования повсюду.

По сути, когда вы знаете, что структура данных неизменяема, вы можете сделать множество оптимизаций вокруг этого. Например, если массив является неизменяемым, вы можете исключить весь код, который будет «растить» массив всякий раз, когда вы пытаетесь добавить объект, и вы можете просто сделать свой неизменяемый массив оболочкой вокруг id[].

Помимо ответов, упомянутых выше, есть одно отличие: неизменяемые объекты обычно потокобезопасны. Принимая во внимание, что объекты Mutable не являются потокобезопасными.

Благодарность