iOS - работа с большими и растущими классами UIViewController

У меня есть UIViewController, который со временем добавил в него много делегированных событий, что сделало класс контроллера довольно большим. Класс UIViewController содержит довольно много методов управления представлением, которые вызываются из методов event-delegate для управления UIView, которым управляет контроллер.

Теперь я добавляю в класс дополнительные события делегата UIActionSheet. Мой класс контроллера становится большим, и я думаю, что я должен разбить события делегата UIActionSheet и поместить их в отдельный класс делегата. Затем этому отдельному классу делегатов придется перезванивать в класс контроллера вида, чтобы заставить контроллер представления соответствующим образом настроить представление, используя методы управления представлением в контроллере представления. (Контроллер вида обращается к отдельному объекту модели, который представляет представление).

Я вижу плюсы и минусы для принятия этого подхода. Неправильно добавлять в контроллер все больше делегированных событий, но создание отдельных классов для разных категорий событий, которые затем необходимо перезвонить в контроллер, также, похоже, создает ненужный уровень сложности и обфускации. Большой класс контроллера «прост и понятен», но чувствует себя не так, в то время как использование множества разных классов делегатов будет несколько более сложным и вовлеченным, но приведет к меньшим классам.

Может ли кто-нибудь дать некоторые слова мудрости по этой теме и, возможно, указать мне на некоторые конкретные чтения iOS по этому вопросу?

Большое спасибо.

3

2 ответы

В итоге я создал немало дополнительных классов для работы с конкретными экземплярами UIActionSheet. Я создал базовый класс, а затем подклассифицировал его для каждого требования UIActionSheet в основном контроллере.

Конечный результат выглядит аккуратно и не добавляет слишком много сложности.

0
добавлено

Мой подход к этому вопросу:

  1. Заставьте это работать.
  2. Сделать кливер
  3. Назад к 1. (Или 1 и 2 в том же порядке, если у вас есть опыт в поле)

Поэтому, если приложение работает с кодом хорошо, но вы обнаружите, что у некоторых классов есть 100 методов, попробуйте разные шаблоны дизайна (если вы уже не знаете), и используйте эти идеи cleaver, чтобы сделать разделение кода на разные классы, делегировать, инкапсулировать их, если необходимо и.

http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html

На всякий случай ссылка на предложения шаблона дизайна Cocoa, и я время от времени просматриваю Pro design c шаблоны проектирования для iOS . Возможно, это не лучшая книга, но она основана на книге «Банда из четырех» в ios-контексте.

Надеюсь, это поможет хотя бы как-то,

ура

0
добавлено
Mobile Dev Jobs — вакансии и аналитика
Mobile Dev Jobs — вакансии и аналитика
6 187 участник(ов)

Публикуем вакансии и запросы на поиск работы по направлению iOS, Android, Xamarin и т.д. ВАЖНО: Правила публикации и правила канала: Ссылка – https://telegra.ph/Pravila-oformleniya-vakansij-i-rezyume-11-09-2

iOS Developers — русскоговорящее сообщество
iOS Developers — русскоговорящее сообщество
2 400 участник(ов)

Общаемся на темы, посвященным iOS-разработке, Swift, Objective-C, SDK, Rx, Cocoa и т.д.

Software Design and OOP
Software Design and OOP
1 481 участник(ов)

OOP, software design, architecture, GRASP, GoF, SOLID, separation of concerns, безысходность. Пожалуйста, придерживайтесь указанных тем. https://oopru.github.io More cool stuff: @fp_ru @tdd_ru @coding_interview_ru @coding_ru