Я, как правило, тоже не объявляю ивара. Я часто буду использовать @synthesize foo = foo_;, хотя для предотвращения прямого доступа, когда я имел в виду сквозной метод или наоборот. И я всегда позволяю компилятору автоматически синтезировать ivar с префиксом _ (что предотвращает случайный прямой доступ). доступ, согласно поразил фраза).
И, как сказал Калеб, все еще существуют плавающие ивары, вы просто не объявляете их явно, если вы действительно этого не хотите (чего, на самом деле, нет, поскольку открытые ивары в заголовках бесполезны для клиентов класса, если ваш API разработан соответствующим образом).
Я также обнаружил, что шумиха над «использовать только прямой доступ в init / dealloc, везде использовать setter / getter», чтобы быть в значительной степени раздутой и, таким образом, просто использовать setter / getter везде. Реальность такова, что если у вас есть наблюдатели во время инициализации / освобождения, вы уже в шланге; состояние объекта по определению не определено во время строительства / разрушения, и, таким образом, наблюдатель не может правильно рассуждать о состоянии.
<Ч />
Как указывает Калеб, еще одна причина использовать прямой доступ к ivar в init / dealloc состоит в том, чтобы избегать подклассов, которые реализуют пользовательскую логику сеттера / получателя, которая может нарушить работу из-за неопределенного состояния объекта во время init / dealloc.
Хотя это может быть правдой, я считаю это неприятным архитектурным недостатком для реализации сеттеров / геттеров с настраиваемым поведением. Это хрупко и со временем значительно усложняет рефакторинг кода. Кроме того, такое пользовательское поведение часто будет зависеть от другого состояния в объекте, и эта зависимость затем приводит к зависимостям порядка от изменений состояния, которые вообще не отражаются в кажущемся простом объявлении @property.
т.е. если ваши сеттеры и геттеры написаны так, что foo.bar = bad; не может быть выполнен в любое время при foo, то ваш код отключен.