Czy każdy ivar musi być własnością?

Chociaż odpowiedź Daniela jest poprawna, myślę, że pomija ważną kwestię. Mianowicie:

Uważam, że używając właściwości zamiast ze zwykłych starych ivarów wystarczy za dużo kod i nie widzę korzyści, jeśli czujesz się komfortowo z zarządzanie pamięcią.

Korzyści to spójność; spójne zarządzanie pamięcią i spójne zachowanie.

Szczególnie, te dwie linie kodu mogą mieć skrajnie różne zachowanie w czas trwania:

iVar = [foo retain];
self.iVar = foo;

Pierwszy jest bezpośrednim ustawieniem zmiennej instancji i nie będzie żadnych powiadomień o zmianach. Drugi przechodzi przez setter i w ten sposób zachowuje wszelkie modyfikacje podklasy po set i zapewnia, że obserwatorzy właściwości są powiadamiani o zmianie.

Jeśli używasz ivars bezpośrednio w swoim kodzie (wewnętrznie do klasy -- jeśli używasz ivars instancji bezpośrednio z poza tej instancji, cóż... każdy wykonawca pracujący na Twoim kodzie powinien podwoić swoje stawki ;), wtedy musisz też obsługiwać powiadomienie o zmianie ręcznie (zazwyczaj dzwoniąc willChangeValueForKey:/didChangeValueForKey) lub jawnie zaprojektuj swoją aplikację, aby uniknąć korzystania z mechanizmów, które opierają się na obserwacji wartości klucza.

I nie obniżaj wartości w centralizacji zarządzania pamięcią; jedno przypadkowe pominięcie w niezliczonej liczbie miejsc połączeń i crash city.

Właściwości są tylko cukrem składni, który pozwala uniknąć pisania tych samych metod w kółko. Z właściwością masz seter, który zwalnia stary obiekt i zachowuje nowy za darmo.

Dla prywatnych pól-sugeruję bezpieczne używanie direct ivars tylko dla prymitywnych typów (BOOL/int / float itp.). Znajduję dobrą praktykę owijania wszystkiego związanego z zarządzaniem pamięcią we właściwościach-nawet rzadko używanych polach. Dodatkową zaletą tego podejścia jest to, że IDE Zwykle inaczej podświetla bezpośredni dostęp do ivars, więc zawsze masz ładny rozdział prostych pól skalarnych i pól typu obiektowego.

@interface BaseControl
...
@end

@interface Label : BaseControl
...
@end

@interface Button : BaseControl {
  @public
    BOOL enabled;
}
@end

I fragment kodu

- (void)enableAllButtons {
    NSArray *buttons = [self getAllButtons];   // expected to contain only Button instances
    for (Button *button in buttons) {
        button->enabled = YES;
    }
} 

Teraz wyobraź sobie, że gdzieś w logice-getAllButtons jest błąd i dostajesz również zwracane etykiety w tej tablicy - więc te instancje klas etykiet będą brakować przypisanego ivar. Fakt, że może być zaskakujące jest to, że-enableAllButtons będzie Nie w takim wypadku. Ale w tym momencie wewnętrzna struktura instancji etykiety jest uszkodzonai to spowoduje niezdefiniowane zachowanie i awarię, gdy zostaną użyte gdzie indziej.

Podobnie jak niektóre popularne problemy z zarządzaniem pamięcią (i ogólnie-z wiszącymi wskaźnikami) - tego rodzaju problemy są trudne do znalezienia i zlokalizowania-ponieważ pojawienie się błędu zwykle jest odległe (pod względem czasu, kodu lub przepływu aplikacji) od miejsca, powodując błąd. Ale z tym szczególny problem nawet nie masz poręcznych narzędzi (takich jak leak/zombies analyzers itp.), aby pomóc Ci zlokalizować i naprawić-nawet gdy nauczysz się, jak go odtworzyć i możesz łatwo zbadać błędny stan.

Oczywiście jeśli użyjesz @property (assign) BOOL enabled; otrzymasz łatwy do zdiagnozowania i naprawienia wyjątek w-enableAllButtons.