Комментарии 8
Ох внимательно смотрите за Pipeline… В Android есть либа EventBus, применять которую считается нехорошей практикой.
Понимаю вашу настороженность..
Но здесь Pipeline не является совсем уж отдельным динамическим инструментом.
Это рукописная штука (является частью шаблона для Xcode), которая внутри делает несколько последовательных вызовов в сторону компонентов модуля, то есть фактически не является слепым распространителем данных.
Статический Pipeline, если так выразиться.
Например, вот часть внутренностей Pipeline, которая передаёт Event из Core к остальным:
func notifyPresenterJoint(event: CoreEvent) {
linkedPresenter?.handleCore(event: event)
linkedJoint?.handleCore(event: event)
}State является персонализированным компонентом для каждого конкретного модуля. Например, для формы входа он может быть таким:
final class LoginModuleState {
var inputLogin = String()
var inputPassword = String()
}Pipeline это единый для всех модулей generic-компонент (его не надо отдельно писать для каждого модуля), реализация которого на текущий момент выглядит так:
SILVER, RoundTable...
А что если дело не в архитектуре?.. 🤔
Нет, извините, показалось!
Надеюсь, что я вас несильно удивлю, если подмечу: довольно часто продвижениям и открытиям сопутствуют эксперименты и обучение. Где-то менее успешные, где-то более.
Находясь в сфере разработки ПО ощутимое время, уже можно начать замечать те или иные неудобства в тех или иных архитектурных вопросах. Вследствие чего часто возникают альтернативные взгляды и решения (которые, впрочем, и не заявляют себя на пальму единственного первенства).
Когда-то миру был радостно преподнесён и MVC, хотя сейчас от него уже многие воротят нос в крупных проектах.
В этой статье вы имели возможность увидеть еще одну альтернативную пробу архитектурного построения и его жизненный цикл. Таки что вас в итоге смущает, не пойму?
Нет, ничего не смущает. Вы молодец, что пытаетесь разобраться. Я лишь пытался сказать, что возможно, дело не в архитектурах, раз они все вам не подходят. Возможно, что дело в том, как вы их понимаете?
Хоть Вы и не просили, но продолжили диалог ^.^, поэтому попробуйте в первую очередь понять, а что же скрывается за понятием масштабируемости, расширяемости и гибкости, которые и являются критериями хорошей архитектуры. Вот быстрая, но очень хорошая ссылка на Хабре.
Поняв что за ними кроется, вы поймете, как нужно организовывать код по ответственностями, и как организовывать эти ответственности во что-то большее. Дальше заметите, что все архитектуры очень похожи и отличаются только нюансами: способами и направлениями взаимодействия компонентов. При этом все они пытаются уменьшить число связей между компонентами своей системы.
А следующим этапом научитесь налету преобразовывать одну архитектуру в другую. Да, это совсем не сложно. При правильном понимании можно за пару часов готовый модуль на MVVM преобразовать в VIP и обратно. Подтверждено практикой. Точно так же этот модуль можно было бы преобразовать и в MVC, и в VIPER (хоть с классическим вайпером было бы и чуточку сложнее – ребятам там слегка нарушили базовые принципы).
В частности в Вашей архитектуре вы просто меняете способ общения компонентов: попытались убрать оркестрирование и заменить его на хореографию. Попытка для иоса смелая. Но не первая. В серверной разработке этот подход давно известен. Насколько успешно вы это сделали, вы можете проверить сами. Тест в конце этого комментария.
В итоге, нужно не архитектуры сочинять, а понять, из чего они строятся, на каких базовых принципах, как это помогает упростить код. Какие еще критерии должны быть у архитектуры (да и у кода, собственно). Ну, а дальше вы можете называть это как угодно, итог у вас будет гибок, изменяем, масштабируем и дальше по критериям необходимым архитектуре.
Кстати, хотите быстрый тест своей архитектуры? Можно ли ее за пару часов преобразовать в MVVM, VIP, VIPER, MVC? а обратно?
Ну, и задача со звездочкой. А сможете реализовать MVC так, чтобы его можно было преобразовать в VIP за пару часов? а MVVM, а MVP, а любую другую архитектуру? А это возможно, как я уже говорил. И если решите эту задачку, она вас поднимет на новый уровень.
Хоть Вы и не просили, но продолжили диалог ^.^, поэтому
Что ж, это приятно, что беседа получила развитие в более детальной манере, чем тот первый краткий непонятный комментарий
Дальше заметите, что все архитектуры очень похожи и отличаются только нюансами: способами и направлениями взаимодействия компонентов.
В этом отношении я давно и полностью согласен с этой мыслью; большинство паттернов (если говорить именно про паттерны UI) схожи в принципах разделения ответственности между компонентами, а отличаются в основном степенью расщепления на эти самые компоненты и способами коммуникации между таковыми
А следующим этапом научитесь налету преобразовывать одну архитектуру в другую. Да, это совсем не сложно. При правильном понимании можно за пару часов готовый модуль на MVVM преобразовать в VIP и обратно. Подтверждено практикой.
Примечание само по себе вполне дельное, впрочем, для меня оно давно не секрет. Вы уж простите за прямоту, но на мой взгляд ваши реплики пропитаны ароматом предвзятости касательно того, что мне (не)известно или чему я уже/ещё (не)научился?
Попытка для иоса смелая. Но не первая. В серверной разработке этот подход давно известен.
И опять же, я ни разу не сомневаюсь в том, что различные и разнообразные решения уже видели мир, в том числе основанные на схожих принципах.
Особенно учитывая, сколько существует разработчиков на самых разных платформах, а также длительность и темпы развития нашей индустрии.
В итоге, нужно не архитектуры сочинять, а понять, из чего они строятся, на каких базовых принципах, как это помогает упростить код.
Я, наверное, не стану и далее дословно цитировать каждое предложение в этой объёмной реплике, потому как весь текст напоминает просто короткую мысль "сбалансированные архитектуры на самом деле схожи в принципах своего построения, так что уж и чего тут распинаться-то", но которая растянулась на половину экрана.
И если решите эту задачку, она вас поднимет на новый уровень.
И всё-таки, давайте, наверное, не будем делать поспешных за-экранных выводов по поводу того, у кого какой предполагаемый уровень?
----
Ну а теперь, заместо увлекательного режима вопрос-ответ, я добавлю пару слов от себя. Надеюсь, это послесловие поможет вам понять контекст моей публикации.
Итак.
Какой процент людей вам доводилось наблюдать в мобильной сфере, кто выбирал под основу паттерны из числа наиболее распространённых? Если ориентироваться, например, на примерный набор из MVC, MVP, MVVM, MVI, Clean Swift, VIPER?
Уверен, что многие при старте проекта или его рефакторинге (полном, либо частичном) ориентируются либо на них напрямую, либо адаптируют тот или иной паттерн для своей команды, то есть вносят некоторые модификации (что, разумеется, не запрещено).
Эти наборы буковок сами по себе не являются торговыми марками, патентами или изобретениями. Они лишь подсказывают, какой формат разбиения на зоны ответственности и какой способ коммуникации (из многих) предпочтителен в той или иной команде, в том или ином проекте.
То есть, если при онбординге (а в идеале – на этапе вакансии, скрининга или тех-интервью) названы три-четыре буквы, и вот уже ты понимаешь, какую геометрическую (архитектурную) фигуру нужно будет брать за основу при создании нового компонента, чтобы дальнейшее взаимодействие в рамках проекта и команды оказалось максимально гладким.
Каждый из выше перечисленных вариантов в своё время появился "благодаря" тому, что его создателя (хотя мне больше нравится формулировка "идейного вдохновителя") не устраивали другие уже известные на "тот момент" варианты организации компонентов и коммуникации между ними. И тем не менее, каждый последующий из этих появившихся вариантов тоже завоевал своё место под солнцем в тех или иных командах и проектах.
И нашлось у каждого из них это место под солнцем, я думаю, благодаря просто тому, что тот или иной человек (или команда), которые выбирали основу для своего проекта, нашли в том или ином паттерне комфортные для себя способы взаимодействия компонентов, которыми было для них довольно удобно пользоваться.
----
И вот задача этой публикации была схожая:
1) поделиться, что в нашей практике обнаружились некоторые неудобства при использовании широко известных паттернов: неудобства одних приводили к возникновению секций с boilerplate кодом (что очень не нравилось и было некомфортно по мере роста функциональности), неудобства других начали проявляться по мере развития в сторону кросс-платформы (организация общей механики оказалась затруднена по причинам особенностей функционирования той или иной платформы);
2) на фоне имеющихся неудобств уже популярных архитектур сформировать свежее видение, "собрать паттерн по кусочкам" без влияния устоявшихся клише, испытать в бою, затем отшлифовать в течение полгода-год;
3) поделиться успехом, рассказать суть варианта, подготовить примеры (тестовый проект, подобие документации, шаблоны для Xcode) на случай, если у кого-то возникнет желание воспользоваться у себя похожими вариантами;
4) а чтобы не объяснять потом на каждом углу по несколько минут принципы, на которых оказался построен этот паттерн (равно разновидность разбиения на компоненты и их коммуникацию между собой), репозиторий получил местное прозвище Round Table, чтобы потом, возможно, всего в двух словах передать смысл происходящего у него внутри.
----
Надеюсь, мне удалось отшлифовать границу между нашими контекстами восприятия?
Round Table: архитектурный UI паттерн для iOS платформы