Прочитав статью Роберта МакНэлли, написанную Робертом МакНэлли чуть менее двух лет назад, смиренно названную «Заповеди кода: лучшие практики для кодирования в Objective-C» , я принял практику использования свойств почти для каждого члена данных в моих классах Objective-C ( 3-я заповедь от мая 2012 года). МакНалли перечисляет эти причины для этого (мой акцент):
- Свойства обеспечивают ограничения доступа (например, только для чтения)
- Свойства применяют политику управления памятью (сильная, слабая)
- Свойства предоставляют возможность прозрачной реализации пользовательских сеттеров и геттеров.
- Свойства с пользовательскими установщиками или получателями могут быть использованы для реализации стратегии безопасности потоков.
- Наличие единственного способа доступа к переменным экземпляра повышает читабельность кода.
Я помещаю большинство своих свойств в частные категории, поэтому номера 1 и 4 обычно не являются проблемами, с которыми я сталкиваюсь. Аргументы 3 и 5 являются более «мягкими», и с правильными инструментами и другими согласованиями они могут стать несущественными. Итак, наконец, для меня наиболее влиятельным из этих аргументов был номер 2, управление памятью. Я делал это с тех пор.
@property (nonatomic, strong) id object; // Properties became my friends.
Для моих последних нескольких проектов я перешел на использование ARC, что заставило меня усомниться в том, что создание свойств для чего-либо еще - хорошая идея или, может быть, немного излишняя. ARC заботится о памяти, управляя объектами Objective-C для меня, что для большинства strong
членов прекрасно работает, если вы просто объявляете ivars. C-типы, которыми вы должны были в любом случае управлять вручную, до и после ARC, а weak
свойства в основном общедоступны.
Конечно, я все еще использую свойства для всего, что требует доступа извне класса, но это в основном лишь несколько свойств, в то время как большинство членов данных указаны в виде ivars под заголовком реализации.
@implementation GTWeekViewController
{
UILongPressGestureRecognizer *_pressRecognizer;
GTPagingGestureRecognizer *_pagingRecognizer;
UITapGestureRecognizer *_tapRecognizer;
}
В качестве эксперимента я делал это немного более строго, и переход от свойств ко всему имеет некоторые положительные побочные эффекты.
- Требования к коду элемента данных (
@property
/@synthesize
) сократились до декларации ivar. - Большинство моих
self.something
ссылок приведено в порядок_something
. - Легко различить, какие члены данных являются частными (ivars), а какие общедоступными (свойства).
- Наконец, кажется, что именно для этого и предназначались свойства Apple, но это субъективное предположение.
На вопрос : я медленно скатываюсь к темной стороне, используя все меньше и меньше свойств в пользу реализации-иваров. Можете ли вы дать мне немного рассуждений о том, почему я должен использовать свойства для всего, или подтвердить свой текущий ход мыслей относительно того, почему я должен использовать больше иваров и меньше свойств только там, где это необходимо? Самый убедительный ответ для обеих сторон получит мою оценку.
РЕДАКТИРОВАТЬ: McNally взвешивает в Твиттере, говоря : «Я думаю, что моя главная причина придерживаться свойств является: один способ сделать все, что делает все (включая KVC / KVO.)»