Когда мне нужно создать подкласс UIViewController и когда я могу просто создать его экземпляр?

Question

Я изучаю программирование на iOS с помощью руководства Big Nerd Ranch, разработанного Хиллегасом и Конвеем.Я пишу свое собственное приложение, когда прохожу книгу, и один из вопросов, который меня беспокоил, касается именно того, когда мне нужно создать подкласс UIViewController (и тому подобное), и когда я могу просто создать его экземпляр.

Например, мое приложение состоит из общих строительных блоков: интерфейс имеет вкладки, а вкладки ведут к UITableView, UINavigationController, который создает UITableView, и так далее.Следуя инструкциям книги, я создал подкласс UITableViewController для создания табличных представлений.Однако при создании UITabBarController, который содержит весь контент моего приложения, кажется достаточным создать экземпляр UITabBarController, а затем добавить к нему несколько представлений.(Все это делается в приложении: didFinishLaunchingWithOptions: метод моего делегата приложения. Поскольку большая часть моего приложения состоит из простых комбинаций базовых частей пользовательского интерфейса, я стараюсь по возможности создавать программный интерфейс.)

У меня складывается впечатление, что я должен создать подкласс UIViewController (или UITableViewController или чего-либо еще) для каждого интерфейса в моем проекте.Это кажется мне странным, так как большинство этих классов будут созданы только один раз.Я просто неправильно понимаю, как использовать ОО в этом случае?(У меня большой опыт программирования, но относительно мало было с ООП.) Должен ли я создавать подкласс для каждого экрана, который увидит пользователь?

Answer 1

Должен ли я создавать подкласс для каждого экрана, который увидит пользователь?

Если для каждого представления требуется разная логика, да.

Не стесняйтесь создавать новые классы для концептуально отдельных вещей. Программисты, переходящие с не-ООП на ООП, могут почувствовать, что файл с небольшим количеством кода является пустой тратой. Подавить это чувство. Занятия дешевы и очень помогают организовать ваше мышление.

Answer 2

Итак, у вас есть два типа контроллеров UIViewController в iOS. «Контейнерные» viewControllers и «Контентные» viewcontrollers. Оба являются подклассами UIViewController, но имеют очень разные цели.

Тип Контейнера - это UINavigationController и UITabController. Они редко делятся на подклассы и обычно используются как есть (на самом деле, я считаю, что Apple вообще не допускает подклассы UINavigationController). Эти «Контейнеры» заботятся о перемещении контроллера представления «Контент». У них нет особого контента, кроме добавления таких вещей, как панель вкладок или панель навигации.

Контроллер представления «Контент» - это те, которые вы создаете большую часть времени. Вы редко сможете использовать UIViewController как есть, потому что он не будет иметь никакой функциональности. Вот почему вы подкласс их. Они предназначены для представления одного «экрана» контента. Таким образом, каждый «экран», который видит пользователь, должен управляться подклассом UIViewController.

UITableViewController - это просто специализированный подкласс UIViewController, который уже содержит некоторые методы для управления таблицами.

Способ, которым была разработана инфраструктура UIKit, заключался в том, чтобы использовать подклассы UIViewController для отображения содержимого и использовать встроенные контроллеры «Контейнера» для облегчения управления подклассами UIViewController.

Answer 3

Вам необходим подкласс UIViewController, если вы хотите выполнить любое из следующих действий (не исчерпывающий список, но некоторые примеры)

• настроить иерархию представления при загрузке иерархии представления (в viewDidLoad)
• обеспечивает некоторое поведение, когда представления контроллера представления становятся видимыми (или нет) (в viewWillAppear:, viewDidAppear:, viewWillDisappear: и т. Д.)
• убирайте за собойпри необходимости в viewDidUnload
• создайте выходы для представлений в иерархии, чтобы их можно было настроить по мере необходимости в описанных выше методах жизненного цикла

Answer 4

Мои рассуждения о подклассах UIViewController и других классах таковы:

1. Почти всегда вы должны инициализировать переменные и присваивать значения экземплярам классов.Вы добавляете подпредставления и устанавливаете их кадры, определяете действия для экземпляра UIViewController и т. Д. Если этот экземпляр UIViewController находится непосредственно в базовом классе, его инициализация должна выполняться вне его.Если эта инициализация требуется в разных местах несколько раз, вам, возможно, придется иметь дело с повторяющимся процессом инициализации.

2. Итак, вы скомпилировали эти процессы в метод, что делает его многоразовым изгде бы этот экземпляр UIViewController не использовался.Но куда ты хочешь это поставить?Не кажется ли вам, что гораздо лучше поместить его в подкласс UIViewController?Кроме того, вам даже не нужно придумывать конкретное имя для этого метода инициализации.Просто переопределите значение по умолчанию -(id)init для суперкласса.

3. Хотя вы можете подумать, что пока достаточно использовать UIViewController без его подкласса, так как ваш проект растет, он будет испытывать трудностииметь дело с вопросами повторного использования.Потратьте некоторое время, чтобы посмотреть на ваши коды.Проверьте, не слишком ли много повторений для инициализации объекта или присвоения ему значений.Если вы делаете одни и те же вещи с экземпляром класса в нескольких местах, скомпилируйте их в метод для повторного использования.И по мере роста числа таких методов вы обнаружите необходимость использовать подкласс, который будет содержать эти соответствующие методы для экземпляра.

4. Независимо от размера вашего проекта, используйте классы для различенияразные предметы важны.Почти всегда базовая существенная классификация выполняется структурой, поэтому нет необходимости вводить новую концепцию для класса.Однако это не означает, что фреймворк также знает, как можно классифицировать ваш проект и его объекты.Используя подкласс, вы можете использовать все преимущества, которые может предоставить среда разработки, и при этом сохранять объекты в вашем проекте как можно более уникальными в зависимости от предназначенной для них цели.

Answer 5

Ну насчет UITabBarController вы правы. Нет никакой причины для чего-либо создавать подкласс, если достаточно поведения по умолчанию. Однако, как только вам нужно будет сделать что-то нестандартное, вам нужно будет создать его подкласс ..

Кроме того, почему вы пытаетесь построить графический интерфейс программно? Для кривой обучения? Нет реальной причины не использовать InterfaceBuilder, это экономит ваше время.

Вы должны создать подкласс UITableViewController для того, чтобы получить ваши данные в представлении, именно так работает модель MVC. Реализация по умолчанию ничего не предлагает для того, чтобы получить ваши данные в представлении, я не думаю, что они когда-либо сделают это, чтобы убедиться, что ничего не потеряно, их «соединение» с объектом модели может отличаться тот, который вы хотите, и в итоге вы написали бы адаптер, если ваш объект модели несовместим.

Надеюсь, это немного вам поможет.

И веселого Рождества.