Поддержание принципа единой ответственности (SRP) с UIViewControllers

Question

Следуя рекомендациям Apple, я создаю один подкласс UIViewController для каждого экрана приложения iPhone.Однако я постоянно нахожу, что эти классы становятся очень большими, как с точки зрения чистых строк кода, так и с точки зрения количества переменных-членов.

По определению они в конечном итоге отвечают за целый ряд различных проблем (например, просмотр жизненного циклапосредничество между представлениями и моделями, иногда обработка касаний, логика управления, управление оповещениями и другие состояния пользовательского интерфейса).

Это не только нарушает принцип единой ответственности, но также приводит к большим объемам кода, которые практически невозможнына модульное тестирование.

Какие обязанности / проблемы вы склонны разделить на новые классы?Как вы думаете, какие обязанности делают хороших кандидатов на чистое разделение в случае подклассов UIViewController?

Answer 1

Это интересный вопрос, и я также борюсь за то, как правильно разделить ответственность. Все зависит от контекста, но так как тестирование подклассов UIVieController может быть трудной задачей, я стараюсь как можно больше перемещаться в классы моделей. В духе Skinny Controller, модель Fat .

Когда дело доходит до таблиц, я создал класс базовой модели для обработки всех элементов табличного представления, в основном инкапсулируя то, что вы получаете при создании нового проекта базовых данных на основе навигации. В контроллере я просто перенаправляю вызовы к моей модели стола.

Я стараюсь, чтобы методы контроллера были как можно меньше. В зависимости от контекста у меня может быть несколько классов моделей, каждый из которых отвечает за определенную часть.

Я также рассмотрел возможность использования заводов контроллеров для получения детальных контроллеров для определенных моделей данных.

UIViewController *detailController = [self.controllerFactory controllerForItem:item];
[self presentModalViewController:detailController animated:YES];

Таким образом, я могу выполнить модульное тестирование, чтобы получить соответствующий контроллер для определенного элемента данных без необходимости задействовать родительский контроллер.

Answer 2

С моей помощью я создаю категории, абстрактных родителей и использую различные шаблоны, которые я изучил в мире Java, чтобы уменьшить сложность и дублирование кода.Но когда дело доходит до этого, у меня все еще есть один контроллер представления на экран, потому что у каждого экрана есть по крайней мере одна вещь, которая уникальна в некотором роде.Возможно, в контроллерах осталось не так много кода благодаря инфраструктуре, которую я разместил вокруг них.