Представляем Flex Pattern

  Перевод   Ссылка на автора

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

В этой статье я представлю новый шаблон проектирования с именем Flex Pattern, который предлагается в моей магистерской диссертации (Alp, 2019, Разработка высококачественного кода и снижение затрат в мобильной платформе). В этой статье приведены примеры использования языка Swift для платформы IOS. Также этот шаблон может использоваться на всех платформах и языках. Эта статья призвана стать хорошим справочным материалом для данной темы.

Flex Pattern фокусируется на гибком использовании программных компонентов. Это обеспечивается путем разделения слоев друг с другом. В этом паттерне слои могут работать независимо и независимо друг от друга. Все части / слои могут работать самостоятельно независимо. Таким образом, любой слой может снова работать где угодно. Изоляция является наиболее важным правилом этой модели. Независимость обеспечивается изоляцией.

Этот шаблон проектирования разделяется на три независимых раздела. Эти разделы есть; Разделы просмотра, модуля и уровня данных. Раздел View включает в себя Part, View, Field и ViewModel. Раздел модуля включает в себя Маршрутизатор, Ведущий, Интерактор. Раздел Data Layer включает в себя Data Layer. В разделе «Модуль» для предотвращения повторения кода доступны общие помощники модуля. Этот помощник имеет такие вещи, как Shared Present Helper и Shared Interactors. Все подробности будут объяснены в следующей статье.

Flex Pattern улучшен с опытом других шаблонов, таких как VIPER, MVP, MVVM и MVC. Некоторые части шаблона Flex имеют сходство с другими шаблонами. Flex Patterns предлагает лучшие результаты почти одинаковыми способами. Основной целью Flex Pattern является написание гибкого кода с изоляцией слоя между собой. Основная идея заключается в том, что если одна вещь, кажется, используется в одном месте, она также может использоваться в других местах, поэтому все должно быть многоразовым.

Принципы гибкого паттерна

• Части должны быть изолированы. Детали могут работать с входными и выходными параметрами. Другие части не управляют ими напрямую, просто говорит, что делать.
• Секции должны работать независимо и без всякой принадлежности.
• Другие разделы не относятся к разделу Модуль, поэтому другие разделы не должны быть написаны в соответствии с модулем.
• Детали должны быть многоразовыми. Любая часть должна использоваться где угодно снова. Ничто не создано для одного места. Любое представление, любой бизнес-код или любой сетевой код должен работать в любом месте, где мы хотим.
• Код должен быть гибким. Внесение изменений должно быть легким и должно работать в разных местах.
• Все разделы имеют конкретные обязанности и задачи. Работает только в соответствии с этим.
• Повторение кода должно быть уменьшено. Чтобы предотвратить повторение кода, должны быть реализованы общие способы.

Основная цель Flex Pattern

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

Различия между другими паттернами

Традиционно разделы напрямую связаны друг с другом в других шаблонах. Например, в шаблоне MVP Presenter напрямую связан с моделью и представлением. В VIPER ведущий напрямую связан с View и Interactor. Да, он может быть изменен для использования или может использовать некоторые способы, чтобы предотвратить это, но в основном архитектура такая. Традиционное отношение к другим шаблонам приведено в следующем:

В Flex Pattern все секции должны использоваться независимо. Модуль может быть связан с любым представлением и любым уровнем данных. Кроме того, View можно использовать с любым модулем, который использует другой уровень данных. Отношение сечения Flex Pattern дается следующим образом:

Разделы и запчасти

Шаблон состоит из трех разделов: Вид, Модуль и Уровень данных. Разделы будут объяснены в том же порядке. Секции никогда не управляют друг другом, секции только сообщают друг другу, что делать и каковы результаты. Все секции изолированы и связаны друг с другом определенными входными и выходными параметрами. Входные и выходные параметры должны использоваться повторно, поэтому при написании кода, который никогда не будет забыт, параметры раздела должны иметь возможность использовать другой раздел в будущем.

Важные правила:

• Разделы должны быть изолированы. (Разделы модуля должны знать что-то о других, однако изоляция может быть обеспечена с помощью протоколов и делегаций)
• Вид частей должен быть изолированным.
• Детали должны быть многоразовыми. Даже сейчас это не нужно, это может понадобиться в будущем, поэтому все должно быть многократно использовано сейчас.
• Разделы должны использоваться с любыми другими, когда это необходимо. View и Data Layer должны быть готовы к этому. Раздел модуля может быть готов, когда это необходимо.
• Уровень данных должен иметь изолированную модель и иметь неизменные переменные
• Секция просмотра никогда не использует другие модели секций, поэтому Секция просмотра работает с собственными моделями или переменными.
• Раздел модуля является единственным разделом, который знает, как отправлять другим или получать информацию от других. Если какая-либо информация должна быть отображена или должна быть отправлена ​​в веб-службу, раздел «Модуль» отправляет данные с преобразованием их для цели. Это то же самое для получения информации от других. Раздел модуля должен знать, как понимать и преобразовывать информацию. (Протоколы и делегирования могут использоваться для использования нескольких других разделов и нескольких разделов модуля)

Использование Xib напрямую с базовым классом XibView

Чтобы использовать Xib более эффективно и быстро, я поделился с вами одним из методов. Этот метод также используется в этой статье примеры. В этом методе мы сможем использовать другие Xib в любой Xib или раскадровке. Код дается следующим образом:

Посмотреть раздел

Все о представлении (которое может быть экранами, частью страницы, компонентом просмотра и т. Д.) Должно быть записано в разделе «Просмотр». Секция просмотра имеет четыре элемента: вид, деталь, поле и модель вида.

Чтобы показать представление, шаблоны просмотра разделены на три. Это Вид, Часть и Поле. Самая основная и единственная часть называется View. Если вид состоит из более чем одного вида внутри, он называется Part. Если View - это страница или обычное большое поле на странице, оно называется Field. Поле может быть ViewController. Кроме того, все маленькие представления объединяются в Field, поэтому Field управляет связью.

Давайте объясним больше о различиях между View и Part. На следующем снимке экрана я создал простое представление, имеющее только TextView и названное TextFieldView.

Давайте создадим более сложные представления с использованием TextFieldView. Для этого мы будем использовать TextFieldView, поместим над ним кнопку X и назовем новый вид с именем TextFieldWithXButtonPartView. Как вы можете видеть внизу, этот вид имеет более одного вида внутри. Так что это называется как часть.

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

Внизу есть код TextFieldWithXButtonAndTopLabelPartView. TextFiedWithXButtonPartView напрямую добавляется в виде View в это представление Xib с помощью Interface Builder.

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

View Model управляет тем, что показывать, и рассказывает, как показывать представлениям. View Model управляет связью между секцией Module и секцией View. Чтобы связать раздел View и раздел Module, View Model и Presenter связываются друг с другом для этого. Информация поступает из раздела Модуль, и View Model может информировать Модуль. Далее приведен пример детали View Model.

Представления, детали и поля хранятся в отдельных каталогах. Слева размещен пример скриншота каталога проекта.

Раздел модуля

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

Обязанности и принципы работы аналогичны MVP и VIPER. Во Flex Pattern Presenter напрямую не связывается с View, напрямую связывается с ViewModel. Раздел модуля не волнует, как что-то работает, этот раздел заботится только о результатах. Таким образом, мы можем сказать, эти разделы заказов или принимает информацию.

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

Раздел модуля состоит из частей, которые являются Presenter, Interactor и Router. Кроме того, чтобы помочь Presenter и Interactor в предотвращении дублирования кода и обеспечить ассоциированное использование, доступен подраздел с именем помощников общих модулей. Использование помощников общего модуля не требуется, но в некоторых случаях это очень полезно. Помощники Shared Module состоят из частей помощника Shared Presenter, Shared Interactor.

Давайте посмотрим на образец. Мы создадим части раздела модуля для страниц аутентификации. Внизу создается класс AuthLoginPresenter Presenter.

Как видите, Presenter имеет переменные интерактора и ViewModel, которые используются для взаимодействия с Interactor и View Model. Также с sharedPresenterHelperScreenOpenStatistic этот докладчик использует помощник докладчика. Взглянув на переменную ViewModel, мы можем сказать, что этот Presenter использует что-то из раздела view в Login.

В приведенном выше примере кода вы можете видеть, что AuthLoginPresenter расширен за счет реализации LoginFieldViewModelToPresenterProtocol. Это означает, что некоторая информация поступает из раздела View с использованием этого протокола. Пример сценария - это когда представление загрузилось в View Controller, информация отправляется в Presenter через ViewModel и сообщает, что представление загружено и готово. После вызова метода viewDidLoad в докладчике он выполняет работу докладчика. Обратите внимание, что View Model не знает, как называется Presenter и как отправлять информацию. View Model отправляет информацию только по-своему и с использованием делегирования. Докладчик знает только, как читать информацию от других и как отправлять ее другим.

В докладчике мы использовали переменную для Presenter Helper. Как вы можете видеть, внутри есть общий интерактор, и этот докладчик и интерактор выполняют свою публичную работу. Эти помощники могут использоваться везде, они не принадлежат ни одному модулю или чему-либо. В приведенном выше примере ScreenOpenStatisticsSharedPresenterHelper работает для отправки статистики открытия экрана. За исключением написания одних и тех же или похожих кодов во многих докладчиках, таким образом мы можем написать его один раз и использовать его для вызова этой работы из обычного места.

После примера Presenter и Presenter Helper давайте поговорим о Interactor. Этот шаблон имеет сходство с шаблоном VIPER по этому поводу. Управление извлечением данных, манипулирование и подобные операции выполняются в Interactor. Если есть много одной и той же операции, вы можете использовать Interactor Helper для этого.

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

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

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

Как вы можете видеть в приведенном выше примере AuthLoginSecondInteractor, помощник интерактора вызывается из реализованного расширения ScreenOpenStaticsSharedInteractorProtol.

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

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

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

Раздел уровня данных

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

Эта многоуровневая модель принадлежит только для слоя дат и создана для ответа или запроса. За исключением интерактора раздела модуля; эта модель слоя никогда не использовалась в других разделах, а другие модели разделов никогда не используются в уровне данных. При отправке параметров запроса Interactor создает модель уровня данных и отправляет ее на уровень данных. Когда ответ получен, Data Layer возвращает свою собственную модель Interactor. Если Interactor необходимо отправить данные ответа в Presenter, Interactor должен преобразовать модель в новую, не принадлежащую к уровню данных. Модели уровня данных не могут быть изменены, поэтому необходимо использовать неизменные переменные. Модели уровня данных должны быть отделены от других моделей, модели уровня данных должны быть расположены в разных папках, таких как «Модели данных».

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

В приведенных выше примерах используются ложные удаленные источники данных. Модели запросов с именем xxxRequestModel и модели ответов называются xxxResponseModel. Когда ответ получен, данные возвращаются к источнику с завершением обратного вызова.

Вывод

Гибкий шаблон ориентирован на сокращение кодов и повторение одной и той же работы. Делит компоненты и коды на части. Это обеспечивает возможность повторного использования компонентов и кодов. Это облегчает изменения и позволяет вносить изменения в одном месте. Благодаря изоляции это позволяет избежать проблем из-за неправильного использования или ошибок.

Я настоятельно рекомендую Flex Pattern для больших проектов. Как VIPER, этот шаблон также имеет много файлов, и он сложнее, чем другие. Требуется сосредоточенность и опыт в создании хорошей архитектуры Flex Pattern. Хотя иногда это сложнее, а иногда занимает больше времени, вы увидите преимущества в продолжении проекта. Если в вашем проекте много разных видов и экранов, Flex Pattern подойдет вам. Flex Pattern также идеально подходит для часто меняющихся проектов.

Что вы думаете о Flex Pattern? Пожалуйста, поделитесь своими комментариями. Мы можем улучшить Flex Pattern лучше. Мы можем обсудить преимущества и недостатки этого. Я надеюсь, что сообществу понравится этот шаблон. Спасибо всем!

Исходный код:

• https://github.com/devgokhan/DesignPatternsSwift

Referance:

• Nuri Gökhan ALP, Devoloping высококачественный код и снижение затрат на мобильной платформе - Национальный диссертационный центр Турции