Властивості під ARC: Завжди або лише для публіки?

Прочитавши статтю з покірною назвою "Команди заповідей: кращі практики кодування об'єктива-C" Роберта МакНіллі трохи менше двох років тому, я прийняв практику використання властивостей майже для кожного члена даних моїх класів Objective-C ( 3-та заповідь станом на травень 2012 року). McNally перераховує ці причини для цього (мій акцент):

1. Властивості застосовують обмеження доступу (наприклад, лише для читання)
2. Властивості застосовують політику управління пам'яттю (сильна, слабка)
3. Властивості надають можливість прозоро реалізовувати власні налаштування та користувачі.
4. Властивості за допомогою спеціальних сетерів або getters можна використовувати для забезпечення стратегії безпеки потоку.
5. Наявність єдиного способу доступу до змінних екземплярів збільшує читабельність коду.

Я розміщую більшість моїх властивостей у приватних категоріях, тому зазвичай №1 та 4, як правило, не є проблемами, в які я стикаюся. Аргументи 3 та 5 є більш "м'якими", і за допомогою правильних інструментів та інших консистенцій вони можуть стати невідповідними. Отже, нарешті, для мене найбільш впливовим з цих аргументів було число 2, управління пам’яттю. Я роблю це з тих пір.

@property (nonatomic, strong) id object; // Properties became my friends.

Протягом останніх кількох моїх проектів я перейшов на використання ARC, що змусило мене сумніватися, чи все ще є хорошою ідеєю створення властивостей для чогось іншого чи, можливо, трохи зайвого. ARC піклується про управління пам'яттю об'єктами Objective-C для мене, що для більшості strongчленів працює чудово, якщо ви просто оголосили ivars. Типи С, яким вам довелося вручну керувати, до і після ARC, а weakвластивості переважно публічні.

Звичайно, я все ще використовую властивості для всього, що потребує доступу з-за класу, але це здебільшого лише декілька властивостей, тоді як більшість учасників даних перелічені як заголовки в заголовку реалізації

@implementation GTWeekViewController
{
    UILongPressGestureRecognizer *_pressRecognizer;
    GTPagingGestureRecognizer *_pagingRecognizer;
    UITapGestureRecognizer *_tapRecognizer;
}

В ході експерименту я робив це трохи більш суворо, і відхід від властивостей до всього має деякі приємні позитивні ефекти.

1. Вимоги ( @property/ @synthesize) для учасників коду даних зменшилися лише до декларації ivar.
2. Більшість моїх self.somethingдовідок очищено до просто _something.
3. Легко розрізнити, які учасники даних є приватними (ivars), а які - загальнодоступними (властивості).
4. Нарешті, це "відчуває" більше, як це було метою, яку Apple призначила властивостями, але це суб'єктивна спекуляція.

Щодо питання : Я повільно ковзаю до темної сторони, використовуючи все менше і менше властивостей на користь реалізації-іварів. Чи можете ви надати мені трохи міркувань, чому я повинен дотримуватися використання властивостей для всього, або підтвердити свій поточний порядок думок щодо того, чому я повинен використовувати більше ivars та менше властивостей лише там, де це потрібно? Найбільш переконлива відповідь будь-якої сторони отримає мій бал.

EDIT: МакНіллі зважує в Twitter, кажучи : "Я думаю, що моя головна причина дотримуватися властивостей полягає в тому, що один із способів робити все, що робить все (включаючи KVC / KVO.)"

Чи можете ви надати мені трохи міркувань, чому я повинен дотримуватися використання властивостей для всього, або підтвердити свій поточний порядок думок щодо того, чому я повинен використовувати більше ivars та менше властивостей лише там, де це потрібно?

Зараз я думаю, що справедливо сказати, що це переважно питання стилю. Як ви кажете, корисність властивостей пам'яті властивостей менш важлива для ARC. З іншого боку, "переваги" повернення до прямого доступу до ivar теж не є переконливими:

1. Декларація властивостей досить схожа на декларацію ivar. Уникнення директиви @synthesize не здається великою виграшею - ми не говоримо про багато коду.

2. foo.somethingСинтаксис, можливо , набагато краще , ніж _something. Синтаксис доступу до властивостей очевидно розроблений так, щоб виглядати і працювати як точковий синтаксис C для доступу до членів структури. Пояснення, до якого об’єкта ви звертаєтесь (чи це selfчи щось інше), може бути корисним. (Деякі люди - не я! - виступають self->somethingза доступ до ivar з цієї причини.) Провідна конвенція підкреслення для ivars є чудовою, але вона не використовується послідовно у всіх кодах Objective-C.

3. Властивості здаються кращим вибором для доступу до даних, що зберігаються в інших об'єктах того ж класу (що дозволено під "приватним" доступом) та для доступу підкласів (наприклад, "захищених" C ++). Тож ідея "властивості == public" дещо розмита.

4. Я відчуваю, що властивості були призначені для спрощення управління пам'яттю та надання деяких інших переваг. Як ви кажете, зі зменшенням переваги управління пам'яттю властивості здаються менш переконливими.

Обраний вами шлях - повернення до прямого доступу до внутрішніх даних - здається дуже розумним вибором, і немає очевидних причин змінити курс. Але дотримання властивостей також є цілком розумним - недоліки не суттєві, і є деякі приємні переваги, такі як відповідність KVO та більш послідовний стиль доступу членів.

Властивості не були останнім кроком в еволюції Objective-C, і я не сподіваюся, що ARC також буде. У мене немає якоїсь конкретної інформації, але здається, гарно здогадується, що в якийсь момент можуть бути додані додаткові функції, які роблять властивості або більш привабливими, або меншими. Доведеться почекати і подивитися, що станеться.

Я також розмірковував над цим питанням. На мою скромну думку, лише використання властивостей для аксесуарів робить код набагато читабельнішим. Ви можете відразу побачити, які змінні мають бути доступними для всіх. І особисто, завжди введення @property (...) перед змінною займає багато часу.