iOS - Аутлеты в файлах реализации категорий

Question

Обзор

• У меня есть проект для iOS, в котором реализация контроллера представления стала крупной и думала, что было бы лучше разбить на категории в зависимости от функциональности
• Выходы в файле реализации контроллера представления недоступны в файле реализации категории.

Примечание - Я использую ARC (автоматический подсчет ссылок)

Вопрос

1. У меня есть выход к текстовому полю, созданному в файле реализации моего контроллера представления. Теперь я могу создать еще один выход для текстового поля того же в файле реализации моей категории контроллера представления?
2. Не приведет ли это к освобождению какой-либо памяти или другим проблемам с памятью (оба выхода будут weak и non atomic)?
3. Это приемлемо с точки зрения дизайна или есть лучший способ сделать это?
4. Можно ли получить доступ к методам категории в реализации контроллера представления? Я могу включить файл заголовка, но я хочу знать, будет ли во время выполнения какое-либо непредсказуемое поведение

Answer 1

Если вам нужен доступ к объявленным IBOutlet свойствам в категориях вашего класса контроллера представления, почему бы не объявить их в заголовочном файле класса, чтобы они были доступны вашим категориям?Возможность объявлять свойства и ivars в файлах реализации теперь предназначена для того, чтобы скрыть грязные детали вашей реализации, но не рискует сделать ваш код неуправляемым.Ваш функциональный дизайн кажется разумным.

Answer 2

1. У вас может быть столько розеток, сколько вы хотите, это указатели, которые позволят вам изменить объект через них.

2. Если вы используете дугу и предполагаете, что использовали Interface Builder для создания текстового поля, то нет, поскольку вы устанавливаете их как слабые, это просто означает, что эти указатели не будут учитываться в счетчике сохранения объекта, поэтому объект будет оставаться в живых до тех пор, пока на него указывает хотя бы 1 сильный указатель. в этом случае представление Интерфейсного строителя сохраняет его, когда это представление освобождается, так будет и объект. Быть не атомарным означает, что это не безопасно, но это не имеет значения для вашей цели.

3. Это действительно зависит от вашей программы, так как я не могу изобразить ее с вашим описанием, я могу лишь посоветовать попытаться придерживаться модели MVC при разработке на iOS. https://developer.apple.com/library/ios/#documentation/General/Conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html