Шаблон координатор — это новое модное слово из мира iOS. Хотя этот шаблон и существует с 2015 года, но лишь недавно он стал привлекать внимание многих разработчиков. Сегодня мы попытаемся выяснить, насколько ценен этот шаблон для нашего приложения.
Цель этой статьи не в том, чтобы объяснить, что такое шаблон координатор и как мы можем его реализовать, а в том, чтобы определить, стоит ли добавлять этот шаблон в наши проекты.
Шаблон координатор — это новый причудливый термин для шаблона делегирования.
Этот шаблон изолирует контроллер навигации от контроллера представления и берет на себя ответственность за навигацию.
Используя шаблон координатор нам не нужно использовать переходы для навигации, а также не нужно писать весь этот навигационный код внутри контроллера представления.
Это означает, что с помощью этого шаблона мы отделяем задачу, связанную с навигацией, от контроллера представления и делегируем ответственность за навигацию классу координатора.
Миссия выполнена! Больше нет связи между контроллером представления и навигацией. Кроме того, теперь один класс управляет навигацией, поэтому реализуется принцип единой ответственности.
Но подождите, у каждого шаблона есть компромиссы, и нужно понять, каковы эти компромиссы, прежде чем начать праздновать и внедрять этот шаблон в клиентских проектах.
Самое первое — это потребность в шаблоне. Если кто-то просто реализует паттерн без причины, то это злоупотребление паттерном.
Итак, мой первый вопрос к тем, кто реализует этот шаблон.
В чем проблема с процессом навигации по умолчанию в вашем приложении, что заставило вас реализовать этот шаблон? Какую проблему решает этот шаблон в вашем приложении? Была ли вообще проблема с самого начала?
UIViewController отвечает за обработку событий, связанных с пользовательским интерфейсом, включая навигацию, поэтому, если за что-то уже отвечает контроллер представления, какой смысл его отделять?
Шаблон координатора значительно увеличивает сложность кода, потому что теперь все, от создания навигации до ее обслуживания, переходит в ручной режим, и разработчик несет ответственность за обработку каждой незначительной детали навигации, включая управление памятью.
Если фреймворк что-то обрабатывает за вас, вы не должны пытаться воссоздать то же самое. Если вы это сделаете, вы в конечном итоге переусложните процесс или, как говорят некоторые, заново изобретете колесо.
Некоторые из недостатков шаблона координатора:
1. Сильные ссылки
Одной из самых больших ошибок этого шаблона является использование weak при объявлении делегата координатора, чтобы можно было избежать сильных ссылок.
Даже самый опытный разработчик забывает написать weak self в closure, поэтому легко можно забыть написать weak при объявлении координатора, что в конечном итоге приведет к созданию сильной ссылки.
Если каким-то образом вы в конечном итоге используете этот шаблон, пожалуйста, проверьте это в ревью кода.
2. Поддержка дочерних координаторов
Этот шаблон вводит дочерние координаторы, где один дочерний координатор обрабатывает навигацию одного контроллера представления. Дочерний координатор будет общаться с главным координатором обо всех своих операциях.
Если разработчик забудет удалить дочерний координатор из основного после того, как его работа завершена, или удалит дочерний координатор слишком рано, это станет проблемой. Вы сможете оставить объект, живущий в памяти, ИЛИ это может привести к часам и часам отладки.
3. Плотная связь
Этот шаблон обуславливает тесную связь, когда один дочерний координатор знает о других дочерних координаторах.
На изображении выше один из дочерних координаторов создает другого дочернего координатора и выполняет навигацию. Это приводит к тому, что называется парными координаторами.
Одна из причин, по которой разработчики реализуют этот шаблон, заключается в том, чтобы устранить необходимость добавления ссылок на другие контроллеры представления в том же контроллере в функции подготовки к переходу. Поскольку теперь мы используем шаблон координатора, мы сделали это, но, к сожалению, теперь мы ввели связанные координаторы.
Чтобы решить проблему связанных координаторов, мы можем использовать порождающий шаблон, такой как фабричный метод. Наш шаблон уже увеличил сложность кода для простой задачи, а теперь, добавляя фабричный метод, мы просто еще больше увеличиваем ее.
4. Сложность кода
Этот шаблон увеличивает сложность кода для выполнения простой задачи, такой как навигация, и кажется, что происходит слишком много делегирования, и могут легко возникнуть сильные ссылки.
Мы можем отделить навигацию от контроллера представления, но стоимость реализации и обслуживания очень высока.
Насколько полезен шаблон
У каждого шаблона есть компромиссы. В конце концов, мы живем с этими компромиссами. Но если нужно добавить такую сложность просто для удаления нескольких строк кода, тогда это не добавляет никакой ценности проекту.
Может быть, в 1 из 1000 сценариев этот шаблон может оказаться полезным, но добавление этого шаблона просто ради добавления приведет к появлению связанных координаторов и увеличение сложности кода.
То есть мы решаем одну проблему, но потом порождаем еще несколько.
Спросите себя, какие проблемы вы пытаетесь решить с помощью этого шаблона и чем полезно его добавление в ваше приложение по сравнению с процессом навигации по умолчанию, это наверняка поможет вам принять решение при выборе.
Многие разработчики стараются избегать использования этого шаблона только из-за того, что он усложняет код, и предпочитают использовать навигацию по умолчанию и сохранять простоту.
Я думаю, что в наши дни все пытаются внедрять шаблоны, чтобы сделать свой код более надежным и тестируемым, с чем я согласен и поддерживаю, но использование меча вместо иглы — плохой подход.
Нужно сначала проанализировать необходимость шаблона, а не просто добавлять его ради названия, только потому, что где-то прочитали в блоге или любимый ютубер снял по нему видео.
Я надеюсь, что этот пост был полезен. Спасибо, что уделили время чтению статьи.