Connect with us

Разработка

Насколько полезен шаблон Координатор в iOS-приложении?

Цель этой статьи не в том, чтобы объяснить, что такое шаблон координатор и как мы можем его реализовать, а в том, чтобы определить, стоит ли добавлять этот шаблон в наши проекты.

Опубликовано

/

     
     

Шаблон координатор — это новое модное слово из мира iOS. Хотя этот шаблон и существует с 2015 года, но лишь недавно он стал привлекать внимание многих разработчиков. Сегодня мы попытаемся выяснить, насколько ценен этот шаблон для нашего приложения.

Цель этой статьи не в том, чтобы объяснить, что такое шаблон координатор и как мы можем его реализовать, а в том, чтобы определить, стоит ли добавлять этот шаблон в наши проекты.

Шаблон координатор — это новый причудливый термин для шаблона делегирования.

Этот шаблон изолирует контроллер навигации от контроллера представления и берет на себя ответственность за навигацию.

Используя шаблон координатор нам не нужно использовать переходы для навигации, а также не нужно писать весь этот навигационный код внутри контроллера представления.

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

Миссия выполнена! Больше нет связи между контроллером представления и навигацией. Кроме того, теперь один класс управляет навигацией, поэтому реализуется принцип единой ответственности.

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

Самое первое — это потребность в шаблоне. Если кто-то просто реализует паттерн без причины, то это злоупотребление паттерном.

Итак, мой первый вопрос к тем, кто реализует этот шаблон.

В чем проблема с процессом навигации по умолчанию в вашем приложении, что заставило вас реализовать этот шаблон? Какую проблему решает этот шаблон в вашем приложении? Была ли вообще проблема с самого начала?

UIViewController отвечает за обработку событий, связанных с пользовательским интерфейсом, включая навигацию, поэтому, если за что-то уже отвечает контроллер представления, какой смысл его отделять?

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

Если фреймворк что-то обрабатывает за вас, вы не должны пытаться воссоздать то же самое. Если вы это сделаете, вы в конечном итоге переусложните процесс или, как говорят некоторые, заново изобретете колесо.

Некоторые из недостатков шаблона координатора:

1. Сильные ссылки

Одной из самых больших ошибок этого шаблона является использование weak при объявлении делегата координатора, чтобы можно было избежать сильных ссылок.

Насколько полезен шаблон Координатор в iOS-приложении?

Даже самый опытный разработчик забывает написать weak self в closure, поэтому легко можно забыть написать weak при объявлении координатора, что в конечном итоге приведет к созданию сильной ссылки.

Если каким-то образом вы в конечном итоге используете этот шаблон, пожалуйста, проверьте это в ревью кода.

2. Поддержка дочерних координаторов

Этот шаблон вводит дочерние координаторы, где один дочерний координатор обрабатывает навигацию одного контроллера представления. Дочерний координатор будет общаться с главным координатором обо всех своих операциях.

Насколько полезен шаблон Координатор в iOS-приложении?

Если разработчик забудет удалить дочерний координатор из основного после того, как его работа завершена, или удалит дочерний координатор слишком рано, это станет проблемой. Вы сможете оставить объект, живущий в памяти, ИЛИ это может привести к часам и часам отладки.

3. Плотная связь

Этот шаблон обуславливает тесную связь, когда один дочерний координатор знает о других дочерних координаторах.

Насколько полезен шаблон Координатор в iOS-приложении?

На изображении выше один из дочерних координаторов создает другого дочернего координатора и выполняет навигацию. Это приводит к тому, что называется парными координаторами.

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

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

4. Сложность кода

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

Мы можем отделить навигацию от контроллера представления, но стоимость реализации и обслуживания очень высока.

Насколько полезен шаблон

У каждого шаблона есть компромиссы. В конце концов, мы живем с этими компромиссами. Но если нужно добавить такую ​​​​сложность просто для удаления нескольких строк кода, тогда это не добавляет никакой ценности проекту.

Может быть, в 1 из 1000 сценариев этот шаблон может оказаться полезным, но добавление этого шаблона просто ради добавления приведет к появлению связанных координаторов и увеличение сложности кода.

То есть мы решаем одну проблему, но потом порождаем еще несколько.

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

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

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

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

Я надеюсь, что этот пост был полезен. Спасибо, что уделили время чтению статьи.

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: