В сохраненных свойствах, не содержащих ARC-код, мы по-прежнему заботимся об управлении памятью, используя синтаксис self.property =, поэтому нас научили использовать их практически для всего.
Но теперь с ARC это управление памятью уже не является проблемой, также почему причина использования свойств испарится? есть ли еще какая-то веская причина (очевидно, кроме предоставления публичного доступа к переменным экземпляра), чтобы использовать свойства больше?
Но теперь с ARC это управление памятью уже не проблема, так что причина использования свойств испаряется? есть ли еще какие-либо хорошие причины (очевидно, кроме предоставления открытого доступа к экземпляру переменные) для использования свойств больше?
Да - используя @property и @synthesized getters/setters, вы гарантируете, что:
Даже внутри класса я обычно склоняюсь к использованию свойств и синтаксиса точек для поддержания состояния внутри объекта. Это не универсально - будут некоторые переменные экземпляра, которые я непосредственно манипулирую (исключительно напрямую манипулирую, no @property вообще), если мой дизайн таков, что воздействие в любом случае будет означать массовый рефакторинг.
так ли причина испарения свойств?
С ARC, создающим "владение магией", доступной для иваров, этот конкретный аспект того, почему можно было бы выбрать свойства над иварами, испарится. Однако многие другие остаются:
Я продолжаю использовать свойства как мой способ по умолчанию для сохранения состояния, которое может быть подвержено внешним классам или внутренним классам "родной", поскольку дополнительная гибкость больше, чем перевешивает небольшие дополнительные затраты во время выполнения.
Я не думаю, что когда-либо использовал свойства просто из-за управления памятью, и я не думаю, что вам когда-либо понадобится. Поэтому, чтобы ответить на ваш вопрос, нет, нет причин использовать свойства, отличные от доступа к переменным экземпляра, что, по сути, означает, что они должны использоваться в первую очередь.
Вы говорите о двух разных вещах. ARC предназначен для управления памятью, поэтому вам не нужно обременять избытком dealloc и сохранять заявления.
Свойства, чтобы дать классу возможность контролировать/ограничивать экспозицию своих внутренних iVars, выставляя API для других классов для связи/взаимодействия с.
Помимо сохраненных, существуют и другие модификаторы, которые в некоторых случаях могут стать весьма полезными, например. 'copy' при назначении блоков переменным-членам класса или 'readonly', который гарантирует, что свойство не может быть записано. Также не забывайте о свойствах "dynamic" при работе с Core Data и возможности выполнять собственный код при назначении или извлечении свойства (при определении пользовательских getters/seters вместо использования @synthesize).