ARC를 사용하는 Objective-C 속성

Question

현재 ARC를 사용하는 현재 iOS 프로젝트를 리팩터링하려고합니다. 그리고 "Refactor to ARC"도구를 사용하여 현재 코드를 ARC로 마이그레이션하기위한 변경 사항을 미리 본 후 xCode를 사용하면 현재 코드 규칙이 ARC에 적합하지 않을 수 있습니다. 왜냐하면 그것은 __weak/__strong 등등을 내 ivars에 많이 추가했기 때문입니다.

내 현재의 규칙은 Heres는 방법 :

내가 개인 또는 보호 된 인스턴스 변수 등 모든 인스턴스 변수를 정의합니다. 모든 공용 변수는 @property를 만듭니다.

@interface TestClass 
{ 
@private 
NSMutableArray* mArray; 
NSString* mString; 
BOOL mMyBoolean; 
} 

@property (retain, nonatomic) NSString* string; // public 
@end 

모든 개체를 항상 다시 @property와 난, 난 그냥 구현의 범주를 만들, 내가 참조입니다 개인 변수가 있다면 그렇게 유지/해제를 처리 방지 할 수 있습니다. 구조체 (예 : mMyBoolean) 저는 정의를 ivar로 남겨 둡니다.

@interface TestClass() 
@property (retain, nonatomic) NSmutableArray* mArray; 
@end 

@implementation TestClass 
@synthesize string = mString; 
@synthesize mArray; 

@end; 

그러나 새로운 ARC 릴리스/유지 돌보는 때문에 내가 제대로 private 변수를 필요가없는

는 @property에 의해 뒷받침된다.

그래서 어떤 코드 규칙이 더 적절할까요? 필자는 다음과 같은 인터페이스에서 속성을 정의에 대해 생각하고 :

@interface TestClass 
{ 
@private 
NSMutableArray* mArray; 
BOOL myBoolean; 
} 

@property (strong, nonatomic) NSString* string; 
@end 


@implementation TestClass 
@synthesize string; 
@end 

그리고 개인 속성에 대한 이용 카테고리의 속성을 해달라고. (또한 "m"접두어를 제거한) @property가 사용해야하는 백업 ivar을 정의하지 않고 대신 xcode가 자동 생성되도록 사용하겠습니까?

Answer 1

이 질문은 스타일에 관한 질문 일 뿐이므로 객관적으로 대답하기는 어렵지만 필자는 두 센트를 던질 것입니다. 내가 볼 수있는 한 당신이하는 일에는 아무런 문제가 없습니다. 당신의 목표가 당신이 더 깨끗한 코드를 갖기 위해 할 수있는 것을 보는 것이라면, 나는 나의 명명 규칙을 공유 할 것이다. (한 남자의 쓰레기는 다른 남자의 보물이지만, 당신이 그걸 좋아하지 않는다면, 그것에서 무엇이든을 가지고 가야한다).

1) iVars는 m으로 시작하며 결코 공개되지 않습니다.

2) 상속 된 클래스가 내부적으로 읽기 전용 변수를 수정할 수 있어야하는 경우가 아니면 명시적인 보조 변수가 아닌 밑줄 (_)로 시작하는 변수 이름으로 합성되는 속성입니다.이 경우 공개로 이동해야합니다. 인터페이스 (그리고 여전히 속성 변수라는 것을 내 자신에게 알리기 위해 언더 바를 사용하여 이름을 짓습니다). 속성은 인터페이스를 통해 일부 정보를 노출하기위한 것이지만 구현이 의미가 없기 때문에 구현이 모든 것에 액세스 할 수 있으므로 다음 경우를 제외하고는 개인 인터페이스에서 속성을 사용하지 않습니다.

3) 그렇지 않으면 간단하게 변수에 할당하는 것 이외의 논리를가집니다. 이 경우 getter 또는 setter (둘 다 아님) 만 재정의하면 (_)로 합성되고 원하는 메서드를 재정의합니다 (명시 적 변수가 필요 없음). 만약 내가 두 가지를 모두 오버라이드한다면, 나는 명시 적으로 뒷받침 변수를 필요로한다. (KVO 메서드를 호출하는 것을 잊지 마라 ^^).

내가 상상하는 이런 종류의 작업을 수행하는 "올바른"방법은 없습니다 ...보편적 인 것 같다 유일한 지침은이의 경우)

3 지속적으로 수행)

1) 당신 과 당신의 팀 쉽게

이 이해할 수있는 방법으로 그것을 할 수 있습니다 API는 헤더 파일 만보고 쉽게 이해할 수 있습니다.