2 년 전에 Robert McNally 의 "코드 명령 : Objective-C 코딩 모범 사례" 라는 기사를 읽은 후 Objective-C 클래스의 거의 모든 데이터 멤버에 대해 속성을 사용하는 방법을 채택했습니다 ( 2012 년 5 월 현재 제 3 계명). McNally는 다음과 같은 이유를 설명합니다 (내 강조).
- 속성은 액세스 제한 (예 : 읽기 전용)을 시행합니다
- 속성은 메모리 관리 정책을 시행합니다 (강함, 약함)
- 속성은 사용자 지정 세터 및 게터를 투명하게 구현할 수있는 기회를 제공합니다.
- 사용자 정의 setter 또는 getter가있는 특성을 사용하여 스레드 안전성 전략을 시행 할 수 있습니다.
- 단일 방법으로 인스턴스 변수에 액세스하면 코드 가독성이 향상됩니다.
내 속성의 대부분을 개인 범주에 넣었으므로 1 번과 4 번은 일반적으로 문제가되지 않습니다. 인수 3과 5는 더 '부드럽고', 올바른 도구와 기타 일관성으로 인해 문제가되지 않을 수 있습니다. 마지막으로, 나에게 가장 큰 영향을 미치는 논점은 메모리 관리였습니다. 나는 그 이후로 이것을 해왔다.
@property (nonatomic, strong) id object; // Properties became my friends.마지막 몇 가지 프로젝트에서 ARC를 사용하기로 전환했습니다.이를 통해 거의 모든 것에 대한 속성을 만드는 것이 여전히 좋은 아이디어인지 아니면 약간 불필요한 지 의심 스럽습니다. ARC는 나를 위해 Objective-C 객체를 관리하는 메모리를 관리 strong합니다. ivar을 선언하면 대부분의 회원에게 잘 작동합니다. 어쨌든 ARC 전후에 수동으로 관리해야하는 C 유형이며 weak속성은 대부분 공용 유형입니다.
물론 클래스 외부에서 액세스 해야하는 항목에는 여전히 속성을 사용하지만 대부분은 소수의 속성에 불과하지만 대부분의 데이터 멤버는 구현 헤더 아래에 ivar로 나열됩니다.
@implementation GTWeekViewController
{
UILongPressGestureRecognizer *_pressRecognizer;
GTPagingGestureRecognizer *_pagingRecognizer;
UITapGestureRecognizer *_tapRecognizer;
}실험으로 나는 이것을 좀 더 엄격하게 해왔으며 모든 속성에서 벗어나는 것은 긍정적 인 부작용이 있습니다.
- 데이터 멤버 코드 요구 사항 (
@property/@synthesize)은 ivar 선언으로 축소되었습니다. - 내
self.something참조의 대부분은 그냥 정리했다_something. - 어떤 데이터 멤버가 개인 (ivars)이고 어떤 데이터 멤버 (public)인지 쉽게 구별 할 수 있습니다.
- 마지막으로, 이것이 애플이 의도 한 목적인 것 같은 느낌이 들지만, 주관적인 추측입니다.
질문에 : 나는 구현 측면 을 선호하여 점점 더 적은 속성을 사용하여 어두운 쪽으로 천천히 미끄러 져 가고 있습니다. 왜 모든 것에 속성을 사용해야하는지에 대한 약간의 추론을 제공 할 수 있습니까, 아니면 필요한 경우에만 더 많은 ivar와 적은 속성을 사용해야하는 이유에 대한 현재의 생각을 확인할 수 있습니까? 어느 쪽이든에 대한 가장 설득력있는 대답은 나의 표를 받게 될 것입니다.
편집 : McNally는 트위터에서 다음과 같이 말합니다 . "속성을 고수하는 주된 이유는 모든 것을 수행하는 한 가지 방법 (KVC / KVO 포함)입니다."