iOS 개발 에서 논란 (1) 류 의 구성원 변 수 는 어떻게 정의 해 야 합 니까?

글 의 출처:http://www.devtang.com/blog/2015/03/15/ios-dev-controversy-1/
논란 이 되 는 이 야 기 를 나 누고 제 생각 을 표현 하려 고 합 니 다.이것 은 이 시리즈 의 첫 번 째 편 입 니 다. 제 가 토론 하고 싶 은 것 은 클래스 의 구성원 변 수 는 어떻게 정의 해 야 합 니까?
Objective - C 의 언어 초기 에 클래스 의 개인 구성원 변 수 는. h 의 헤더 파일 에 만 정의 할 수 있 었 습 니 다.다음 과 같이:

1
2
3
4

@interface ViewController : UIViewController {  @private  NSInteger _value; }

이후 애플 은 Objective - C 를 개선 하여. m 에 이름 이 없 는 Category 를 추가 하여 클래스 의 구성원 변 수 를 추가 할 수 있 도록 했다.다음 과 같이:

1
2
3
4
5

@interface ViewController ()  @property (nonatomic) NSInteger value;  @end

이러한 장점 은 이 변수 들 이 헤더 파일 에 철저히 숨겨 져 사용자 에 게 노출 되 지 않 아 도 된다 는 것 이다.
이 어 2013 년 WWDC 에서 애플 은 Objective - C 를 개선 하여 m 에 허용 했다.  @implementation 에 클래스 의 개인 구성원 변 수 를 직접 추가 합 니 다.다음 과 같이:

1
2
3

@implementation ViewController {  NSInteger _value; }

그래서 개인 구성원 변 수 를 어떻게 정의 하 느 냐 에 대한 의견 차이 가 생 겼 다.많은 사람들 이 익명 의 Category 방식 으로 개인 구성원 변 수 를 정의 하 는 것 을 좋아한다.하지만 저 는 개인 적 으로 더 추천 합 니 다.  @implementation  클래스 의 개인 구성원 변 수 를 직접 추가 합 니 다.다음은 제 가 설명 을 드 리 겠 습 니 다.
역사적 원인
우선 초기 iOS 프로그래머 들 은 2011 년 ARC 가 출시 되 기 전에 Objective - C 는 인용 수 를 손 으로 관리 해 야 한 다 는 것 을 알 고 있 을 것 이다.클래스 의 모든 개인 구성원 에 게 사용  self.property  컴 파일 러 가 인용 수 를 관리 하 는 코드 를 자동 으로 생 성 할 수 있 는 형식 입 니 다.2012 년 까지 만 해도 이 feature 는 사용 해 야 합 니 다.  @synthesize  키 워드 를 사용 합 니 다.그래서 애플 은 코드 규범 에서 사용 을 추천 하고 강조 했다.  self.property  메모리 관리 에 문제 가 생기 지 않도록 프로 그래 밍 습관 을 사용 합 니 다.한편, ARC 시대 에 이 프로 그래 밍 습관 이 가 져 온 장점 은 더 이상 존재 하지 않 았 다. 컴 파일 러 가 자동 으로 인용 계 수 를 관리 하기 때문에 우 리 는 순환 인용 문 제 를 일 으 키 지 않도록 관심 을 가 져 야 한다.
걱정 을 덜다
방금 말 했 듯 이 클래스 에서 완전히 사용 합 니 다.  _property  개인 구성원 변 수 를 방문 하 는 방식 은 메모리 관리 에 문제 가 없 을 것 입 니 다.하지만 사용  self.property  개인 변 수 를 방문 하 는 것 도 마찬가지 입 니 다. 메모리 관리 에 문제 가 없 지 않 습 니까?그 렇 긴 하지만 주의해 야 할 것 이 있 습 니 다. init 와 dealloc 에서 사용 하지 않 는 것 이 좋 습 니 다.  self.property  구성원 변 수 를 방문 하 는 방식 입 니 다. 이 점 은 애플 의 공식 문서 에 쓰 여 있 습 니 다. 저도 예전 글 에서 소개 한 적 이 있 습 니 다.(참조: init 와 dealloc 함수 에서 accessor 를 사용 하지 마 십시오)
하면, 만약, 만약...  self.property  개인 구성원 변 수 를 물 어 보 러 왔 습 니 다. init 와 dealloc 에 서 는 이런 방식 을 사용 하지 않 는 다 는 점 에 주의 하 셔 야 합 니 다. 프로그래머 에 게 는 부담 이 됩 니 다. 실 수 를 했 는 지 계속 일 깨 워 주 셔 야 합 니 다. 완전한 것 을 사용한다 면.  _property  개인 구성원 변 수 를 방문 하 는 방식 은 이런 문 제 를 생각 할 필요 가 없다.
숨 김 에 대하 여
아시 다시 피 self.property 사실 클래스 를 호출 했 어 요.  [self property]  방법, 그래서 이것 은 사실 한 가지 방법 으로 호출 된 숨겨 진 것 입 니 다. 많은 경우 에 우 리 는 한 가지 구성원 을 초기 화 하 는 것 을 지연 시 켜 야 할 때 이 멤버 의 초기 화 방법 을 여기에 씁 니 다.  [self property]  방법의 실현 중.
그러면 문제 가 생 겼 습 니 다. 다른 사람의 코드 를 읽 을 때 보 았 습 니 다.  self.property  여기 숨겨 진 함수 가 있 지 않 을 까? 그래서 그 방법 으로 찾 아야 한다. 그러나 실제 개발 에서 대부분의 property 는 컴 파일 러 를 사용 하여 자동 으로 생 성 되 는 Getter 와 Setter 방법 이기 때문에 실현 되 지 못 할 것 이다. 이때 서 야 알 게 되 었 다."아, 원래 이 코드 는 사용자 정의 멤버 초기 화 작업 을 하지 않 았 군요."
이 기본 값 은 코드 에 많이 숨겨 져 있 습 니 다. 코드 의 읽 기와 유지 에 영향 을 줄 수 있 습 니 다. 사실 대부분의 클래스 구성원 변 수 는 클래스 초기 화 방법 에 값 을 부여 해 야 합 니 다. 대부분의 UIViewController 의 구성원 변 수 는 필요 합 니 다.  viewDidLoad  방법 에 값 을 부여 합 니 다. 그렇다면 직접 해당 하 는 방법 중 하 나 를 사용 하 는 것 이 좋 습 니 다.  setupProperty  방법 은 직접 초기 화 를 진행 합 니 다. 이러한 장점 은 코드 의 가 독성 이 더욱 좋아 졌 다 는 것 입 니 다. self.property 초사 화 지연 이 필요 한 경우 에 만 사용 된다.
이것 에 대해 또 하나의 작은 이야기 가 있 습 니 다. 저 는 예전 에 한 동료의 iOS 엔 드 코드 를 검토 한 적 이 있 습 니 다. 그 동 료 는 table view 의 데 이 터 를 다른 유형 으로 포장 하 는 것 을 좋아 합 니 다. 그리고 저 는 이 데이터 들 이 사실은 하나의 배열 이 라 고 생각 합 니 다. 이 포장 을 할 필요 가 없다 고 생각 합 니 다. 결국 우 리 는 오랫동안 논쟁 을 했 습 니 다. 제 관점 은 모든 숨겨 진 것 이 코드 의 복잡성 에 대한 증가 라 고 생각 합 니 다.좋 은 점 을 가 져 왔 습 니 다. 예 를 들 어 코드 재 활용, 코드 의 유지 가능성 향상 등 이 있 습 니 다. 그렇지 않 으 면 좋 은 패 키 징 은 코드 읽 기 이해 에 만 비용 을 가 져 다 줄 수 있 습 니 다. 현재 제 경험 에서 대부분의 table view 데 이 터 는 한 배열 에 넣 을 수 있 습 니 다. 이 배열 을 패키지 할 필요 가 없습니다. 이 배열 의 데 이 터 를 조작 하 는 방법 을 따로 제공 합 니 다.
짧 은 코드 가 더 읽 기 쉽다._property  쓰다  self.property  더 짧 고 더 간단 합 니 다. 저 는 이렇게 쓴 코드 가 읽 기 에 더욱 편리 하 다 고 생각 합 니 다.
실행 속도 가 빠 르 고 IPA 부피 가 작 습 니 다.
나 는 이전에 이 둘 사이 의 속도 와 응용 부피 가 매우 큰 차이 가 있 을 것 이 라 고 생각 한 적 이 없다. 그러나 한 동업 자 는 나 에 게 그들 회 사 는 두 사람 이 아직도 적지 않 은 차이 가 있다 는 것 을 발견 했다. 만약 당신들 의 응용 이 심도 있 는 최적화 가 필요 하 다 면 고려 해 볼 수 있다 고 말 했다.  self.property  바꾸다  _property. 그러나 대부분의 응용 은 이런 깊이 있 는 최적화 가 필요 하지 않 을 것 이 라 고 생각 합 니 다.
KVO 와 KVC.
하면, 만약, 만약...  _property  이런 표기 법 은 KVO 와 KVC 를 사용 할 수 없습니다. 그러나 한 가지 내부 에서 KVO 자신의 개인 구성원 변 수 는 좋 은 디자인 이 라 고 할 수 있 습 니까? 우 리 는 유형 을 말 합 니 다.높 은 내부 집적, 낮은 결합 ', KVO 는 관찰자 모드 를 실현 하고 대상 간 에 서로 결합 을 해제 하기 위 한 것 입 니 다. KVO 를 클래스 내부 에 사용 하면 KVO 자신의 개인 구성원 은 사실 좋 은 디자인 이 아니 라 고 생각 합 니 다.
Computed Properties
Swift 에 도입 되 었 습 니 다. Computed Properties 의 개념, 사실 이것 은 Objective - C 에 도 있 습 니 다. 단지 그것 의 이름 을 전문 적 으로 주지 않 았 을 뿐 입 니 다. 만약 하나의 property 가 우리 에 게 대응 하 는 것 을 제공 했다 면.  setter  화해시키다  getter 대응 하 는 property 변 수 를 직접 사용 하지 않 았 다 면 이 property 는 이른바 Computed Properties 입 니 다.
네, 클래스 내부 에서 직접 사용 하면  _property  형식 도 Computed Properties 를 사용 할 수 없습니다. 그러나 저 는 이 영향 이 크 지 않다 고 생각 합 니 다. 사실 Computed Properties 는 데이터 액세스 에 대한 패키지 입 니 다. 우 리 는 두 가지 함 수 를 따로 실현 하여 각각 데이터 에 대응 하 는 것 입 니 다.  setter  화해시키다  getter  기능 은 같은 효 과 를 거 둘 수 있다.
반복 참조 문제
웨 이 보 의 @ 왕 샤 오 레이 는 댓 글 에서 "개인 변수 로 특별히 주의해 야 할 부분 이 있 습 니 다. block 에 직접 쓰 세 요" 라 고 말 했다.  _property  ... 에 해당 하 다  self->_property self 는 쓰 지 않 았 지만 self 에 대한 retain 을 포함 하여 순환 인용 을 초래 하기 쉽다. weakSelf / strongSelf 대 법 을 사용 하 는 것 을 기억 해 야 한다.
이 점 은 확실히 많은 사람들 에 게 무시 당 한 것 이기 때문에 나 도 여기에 함께 써 서 그의 보충 에 감사 한다.
마지막 에 쓰다
사실 제 가 위 에서 언급 한 이 문제 들 은 모두 작은 문제 이 고 영향 이 크 지 않 습 니 다. 그러나 코드 스타일 의 통일 은 큰 문제 입 니 다. 그래서 프로젝트 에서 사용 하 는 것 이 든 간 에...  self.property  스타일  _property  스타일, 문제 가 크 지 않 지만 이 두 가지 스타일 을 동시에 사용 하면 매우 좋 지 않 습 니 다.
저의 이 글 이 여러분 에 게 이 방면 의 논쟁 을 알 릴 수 있 기 를 바 랍 니 다. 그리고 여러분 이 이 점 에서 회사 내부 에서 통일 을 이 룰 수 있 기 를 바 랍 니 다.
Posted by 당 교 Mar 15th, 2015  iOS
오리지널 글, 판권 성명: 자유 전재 - 비상 용 - 비 파생 - 서명 유지 | Creative Commons BY-NC-ND 3.0