UIView의 서브 클래 싱을위한 적절한 근거는 무엇입니까?

Question

OOP 및 MVC를 준수한다는 의미입니다.

특히, 사용자가 무언가를 선택할 때마다 동적으로 업데이트되는 UILabels가 두 개인 타임 스탬프, 두 개의 재생 시간 및 두 개의 이름이있는 UIView XIB 파일을 계획했습니다. 이것은 사용자가보고있는 인터페이스의 "헤더"섹션입니다.

약간의 옵션을 참조하십시오. 1.보기 컨트롤러에서 모든 것을 만들고 UIView를 하위보기로 기본보기에 추가하고 속성이있는 UILabel 하위보기를 추적합니다. 하지만이 때문에 View Controller에 많은 속성을 추가해야합니다. 2. UIView의 서브 클래스를 만들고 UILabels를 UIView의 속성으로 추가하여 컨트롤러를 "더 깨끗하게"유지합니다. 3. XIB 파일을 사용합니다 (프로그래밍 방식으로이 작업을 수행한다고 가정 해 보겠습니다).

UIView가 "사용자 지정 드로잉"을 위해 서브 클래 싱되어야한다는 인상을 계속 받기 때문에 나는 이것을 묻습니다. 나의 이론적 근거는 "6 개의 UILabel 속성없이 내 컨트롤러를 깨끗하게 유지하십시오."

Answer 1

UIView를 서브 클래 싱하지 마십시오. 커스텀 드로잉이나 어떤 경우에는 터치에 대한 커스텀 핸들링을 위해 uIView를 서브 클래스 화해야합니다 (그러나 터치를 다루는 더 좋은 방법이 종종 있습니다).

보기 컨트롤러에 모든 것을 넣고 UIView를 서브 클래 싱하는 것이 유일한 옵션은 아닙니다. 헤더를 구성하는보기 그룹을 관리하는 클래스를 만들 수 있습니다. 개념적으로 뷰 컨트롤러가되지만 NSObject에서 상속받은 UIViewController의 하위 클래스는 만들지 않습니다.

Answer 2

개인적으로 UILabels를 UIView의 속성으로 만들려고합니다. 따라서 옵션 2를 사용하면보기에서 컨트롤러를 통해 쉽게 액세스 할 수 있습니다.

이것은 또한보기에서 모든 컨트롤러에 대한 재사용의 이점을 제공하며, dealloc은 UIView의 재사용을 제거하므로 사용자는 한 번만 정리할 수 있습니다!