Хоть Вы и не просили, но продолжили диалог ^.^, поэтому
Что ж, это приятно, что беседа получила развитие в более детальной манере, чем тот первый краткий непонятный комментарий
Дальше заметите, что все архитектуры очень похожи и отличаются только нюансами: способами и направлениями взаимодействия компонентов.
В этом отношении я давно и полностью согласен с этой мыслью; большинство паттернов (если говорить именно про паттерны UI) схожи в принципах разделения ответственности между компонентами, а отличаются в основном степенью расщепления на эти самые компоненты и способами коммуникации между таковыми
А следующим этапом научитесь налету преобразовывать одну архитектуру в другую. Да, это совсем не сложно. При правильном понимании можно за пару часов готовый модуль на MVVM преобразовать в VIP и обратно. Подтверждено практикой.
Примечание само по себе вполне дельное, впрочем, для меня оно давно не секрет. Вы уж простите за прямоту, но на мой взгляд ваши реплики пропитаны ароматом предвзятости касательно того, что мне (не)известно или чему я уже/ещё (не)научился?
Попытка для иоса смелая. Но не первая. В серверной разработке этот подход давно известен.
И опять же, я ни разу не сомневаюсь в том, что различные и разнообразные решения уже видели мир, в том числе основанные на схожих принципах.
Особенно учитывая, сколько существует разработчиков на самых разных платформах, а также длительность и темпы развития нашей индустрии.
В итоге, нужно не архитектуры сочинять, а понять, из чего они строятся, на каких базовых принципах, как это помогает упростить код.
Я, наверное, не стану и далее дословно цитировать каждое предложение в этой объёмной реплике, потому как весь текст напоминает просто короткую мысль "сбалансированные архитектуры на самом деле схожи в принципах своего построения, так что уж и чего тут распинаться-то", но которая растянулась на половину экрана.
И если решите эту задачку, она вас поднимет на новый уровень.
И всё-таки, давайте, наверное, не будем делать поспешных за-экранных выводов по поводу того, у кого какой предполагаемый уровень?
----
Ну а теперь, заместо увлекательного режима вопрос-ответ, я добавлю пару слов от себя. Надеюсь, это послесловие поможет вам понять контекст моей публикации.
Итак.
Какой процент людей вам доводилось наблюдать в мобильной сфере, кто выбирал под основу паттерны из числа наиболее распространённых? Если ориентироваться, например, на примерный набор из MVC, MVP, MVVM, MVI, Clean Swift, VIPER?
Уверен, что многие при старте проекта или его рефакторинге (полном, либо частичном) ориентируются либо на них напрямую, либо адаптируют тот или иной паттерн для своей команды, то есть вносят некоторые модификации (что, разумеется, не запрещено).
Эти наборы буковок сами по себе не являются торговыми марками, патентами или изобретениями. Они лишь подсказывают, какой формат разбиения на зоны ответственности и какой способ коммуникации (из многих) предпочтителен в той или иной команде, в том или ином проекте.
То есть, если при онбординге (а в идеале – на этапе вакансии, скрининга или тех-интервью) названы три-четыре буквы, и вот уже ты понимаешь, какую геометрическую (архитектурную) фигуру нужно будет брать за основу при создании нового компонента, чтобы дальнейшее взаимодействие в рамках проекта и команды оказалось максимально гладким.
Каждый из выше перечисленных вариантов в своё время появился "благодаря" тому, что его создателя (хотя мне больше нравится формулировка "идейного вдохновителя") не устраивали другие уже известные на "тот момент" варианты организации компонентов и коммуникации между ними. И тем не менее, каждый последующий из этих появившихся вариантов тоже завоевал своё место под солнцем в тех или иных командах и проектах.
И нашлось у каждого из них это место под солнцем, я думаю, благодаря просто тому, что тот или иной человек (или команда), которые выбирали основу для своего проекта, нашли в том или ином паттерне комфортные для себя способы взаимодействия компонентов, которыми было для них довольно удобно пользоваться.
----
И вот задача этой публикации была схожая:
1) поделиться, что в нашей практике обнаружились некоторые неудобства при использовании широко известных паттернов: неудобства одних приводили к возникновению секций с boilerplate кодом (что очень не нравилось и было некомфортно по мере роста функциональности), неудобства других начали проявляться по мере развития в сторону кросс-платформы (организация общей механики оказалась затруднена по причинам особенностей функционирования той или иной платформы);
2) на фоне имеющихся неудобств уже популярных архитектур сформировать свежее видение, "собрать паттерн по кусочкам" без влияния устоявшихся клише, испытать в бою, затем отшлифовать в течение полгода-год;
3) поделиться успехом, рассказать суть варианта, подготовить примеры (тестовый проект, подобие документации, шаблоны для Xcode) на случай, если у кого-то возникнет желание воспользоваться у себя похожими вариантами;
4) а чтобы не объяснять потом на каждом углу по несколько минут принципы, на которых оказался построен этот паттерн (равно разновидность разбиения на компоненты и их коммуникацию между собой), репозиторий получил местное прозвище Round Table, чтобы потом, возможно, всего в двух словах передать смысл происходящего у него внутри.
----
Надеюсь, мне удалось отшлифовать границу между нашими контекстами восприятия?
Надеюсь, что я вас несильно удивлю, если подмечу: довольно часто продвижениям и открытиям сопутствуют эксперименты и обучение. Где-то менее успешные, где-то более.
Находясь в сфере разработки ПО ощутимое время, уже можно начать замечать те или иные неудобства в тех или иных архитектурных вопросах. Вследствие чего часто возникают альтернативные взгляды и решения (которые, впрочем, и не заявляют себя на пальму единственного первенства).
Когда-то миру был радостно преподнесён и MVC, хотя сейчас от него уже многие воротят нос в крупных проектах.
В этой статье вы имели возможность увидеть еще одну альтернативную пробу архитектурного построения и его жизненный цикл. Таки что вас в итоге смущает, не пойму?
State является персонализированным компонентом для каждого конкретного модуля. Например, для формы входа он может быть таким:
final class LoginModuleState {
var inputLogin = String()
var inputPassword = String()
}
Pipeline это единый для всех модулей generic-компонент (его не надо отдельно писать для каждого модуля), реализация которого на текущий момент выглядит так:
Понимаю вашу настороженность.. Но здесь Pipeline не является совсем уж отдельным динамическим инструментом.
Это рукописная штука (является частью шаблона для Xcode), которая внутри делает несколько последовательных вызовов в сторону компонентов модуля, то есть фактически не является слепым распространителем данных.
Статический Pipeline, если так выразиться. Например, вот часть внутренностей Pipeline, которая передаёт Event из Core к остальным:
Тут вопрос не только в форматировании…
Вернее, про форматирование речи даже и не было.
Упор был на одновременный учёт следующих аспектов:
— если нет искомой информации для той или иной части фразы, то заменять её дефолтной надписью (или надписями, в зависимости от контекста);
— в разных языках разный порядок слов, то есть нужна адаптивность;
— итоговый способ разметки или записи держать по возможности в одном месте для простоты редактирования.
Или какие возможности форматирования в Swift вы подразумеваете?
как вы работаете с маленькими модулями, которые ограничены uiview и производными
Если суть только в пассивном отображении, то я не использую для таких случаев отдельный модуль, ибо совершенно незачем.
типо сильно сложная ячейка таблицы
Если сложность заключается в плотности размещения информации, то я не могу считать это сложной ячейкой: могу назвать ее просто визуально загруженной.
которую стоит выделять в отдельный модуль
Если же попадается часть интерфейса, которая визуально сложна, обладает какой-то дополнительной логикой или же вовсе любит жить своей жизнью, то в этом случае для нее нередко организуется отдельный модуль, да.
как перебрасывать данные из одной точки приложения в другую, то есть допустим у меня есть раздел магазин и есть раздел профиль и какие то действия, влияют на изменения в профиле
Я использую в основном два способа проброса данных (а порой применяю их вместе):
— callback, он показан в том числе в демо-проекте;
— broadcast, при котором тот, кто умеет информацию менять, дает об этом знать, а его слушатели подписываются и реагируют (можно использовать NotificationCenter, но я стараюсь его применять только в тех случаях, когда собственный механизм сложен либо избыточен в пробрасывании вглубь кода).
VIPER я тоже использовал в 3-4 проектах как минимум, но не могу не отметить, что Presenter при классическом подходе часто получается излишне раздутым (часто выполняет роль мостика), если интерактивности много. Поэтому со временем я все-таки отошел от него.
Я не говорю, что пложу новые архитектуры: я лишь заметил, что мне удобнее оказалось пользоваться более упрощенным вариантом построения кода, которым наверняка итак уже пользуются многие.
К тому же, тут добавляет синтаксическое удобство блочность вместо вызова input/output делегатов, на мой взгляд…
Полагаю, одно из самых важных при TDD — это обеспечение уверенности в том, что код работает так, как он должен работать. Выполнять ту задачу, которую на него возлагают.
И если вдруг очередной прогон теста покажет, например, что валидатор Email работает некорректно или не поддерживает ряд правил, то это повод заменить 3party валидатор или сделать форк.
Ибо неважно, свой код дал сбой или чужой.
Главное — обеспечить выполнение логики программы… во всяком случае, так думаю я.
В целом я это и имел в виду, когда писал про усложнение логики своими жестами и прочим.
Если же говорить об использовании компонента, то да, согласен, тоже вариант.
Да и в любом случае, эта статья – не документация, а просто вариант того, как можно справиться подручными средствами в случае необходимости.
Тогда уж на терминале оплаты (и пусть вся очередь подождёт)
А как же, Doom запустить
А как застраховаться от того, что допустил опечатку (случайно либо намеренно), и вписал по факту ящик вообще другого человека?
Что ж, это приятно, что беседа получила развитие в более детальной манере, чем тот первый краткий непонятный комментарий
В этом отношении я давно и полностью согласен с этой мыслью; большинство паттернов (если говорить именно про паттерны UI) схожи в принципах разделения ответственности между компонентами, а отличаются в основном степенью расщепления на эти самые компоненты и способами коммуникации между таковыми
Примечание само по себе вполне дельное, впрочем, для меня оно давно не секрет. Вы уж простите за прямоту, но на мой взгляд ваши реплики пропитаны ароматом предвзятости касательно того, что мне (не)известно или чему я уже/ещё (не)научился?
И опять же, я ни разу не сомневаюсь в том, что различные и разнообразные решения уже видели мир, в том числе основанные на схожих принципах.
Особенно учитывая, сколько существует разработчиков на самых разных платформах, а также длительность и темпы развития нашей индустрии.
Я, наверное, не стану и далее дословно цитировать каждое предложение в этой объёмной реплике, потому как весь текст напоминает просто короткую мысль
"сбалансированные архитектуры на самом деле схожи в принципах своего построения, так что уж и чего тут распинаться-то", но которая растянулась на половину экрана.И всё-таки, давайте, наверное, не будем делать поспешных за-экранных выводов по поводу того, у кого какой предполагаемый уровень?
----
Ну а теперь, заместо увлекательного режима вопрос-ответ, я добавлю пару слов от себя. Надеюсь, это послесловие поможет вам понять контекст моей публикации.
Итак.
Какой процент людей вам доводилось наблюдать в мобильной сфере, кто выбирал под основу паттерны из числа наиболее распространённых? Если ориентироваться, например, на примерный набор из MVC, MVP, MVVM, MVI, Clean Swift, VIPER?
Уверен, что многие при старте проекта или его рефакторинге (полном, либо частичном) ориентируются либо на них напрямую, либо адаптируют тот или иной паттерн для своей команды, то есть вносят некоторые модификации (что, разумеется, не запрещено).
Эти наборы буковок сами по себе не являются торговыми марками, патентами или изобретениями. Они лишь подсказывают, какой формат разбиения на зоны ответственности и какой способ коммуникации (из многих) предпочтителен в той или иной команде, в том или ином проекте.
То есть, если при онбординге (а в идеале – на этапе вакансии, скрининга или тех-интервью) названы три-четыре буквы, и вот уже ты понимаешь, какую геометрическую (архитектурную) фигуру нужно будет брать за основу при создании нового компонента, чтобы дальнейшее взаимодействие в рамках проекта и команды оказалось максимально гладким.
Каждый из выше перечисленных вариантов в своё время появился "благодаря" тому, что его создателя (хотя мне больше нравится формулировка "идейного вдохновителя") не устраивали другие уже известные на "тот момент" варианты организации компонентов и коммуникации между ними. И тем не менее, каждый последующий из этих появившихся вариантов тоже завоевал своё место под солнцем в тех или иных командах и проектах.
И нашлось у каждого из них это место под солнцем, я думаю, благодаря просто тому, что тот или иной человек (или команда), которые выбирали основу для своего проекта, нашли в том или ином паттерне комфортные для себя способы взаимодействия компонентов, которыми было для них довольно удобно пользоваться.
----
И вот задача этой публикации была схожая:
1) поделиться, что в нашей практике обнаружились некоторые неудобства при использовании широко известных паттернов: неудобства одних приводили к возникновению секций с boilerplate кодом (что очень не нравилось и было некомфортно по мере роста функциональности), неудобства других начали проявляться по мере развития в сторону кросс-платформы (организация общей механики оказалась затруднена по причинам особенностей функционирования той или иной платформы);
2) на фоне имеющихся неудобств уже популярных архитектур сформировать свежее видение, "собрать паттерн по кусочкам" без влияния устоявшихся клише, испытать в бою, затем отшлифовать в течение полгода-год;
3) поделиться успехом, рассказать суть варианта, подготовить примеры (тестовый проект, подобие документации, шаблоны для Xcode) на случай, если у кого-то возникнет желание воспользоваться у себя похожими вариантами;
4) а чтобы не объяснять потом на каждом углу по несколько минут принципы, на которых оказался построен этот паттерн (равно разновидность разбиения на компоненты и их коммуникацию между собой), репозиторий получил местное прозвище Round Table, чтобы потом, возможно, всего в двух словах передать смысл происходящего у него внутри.
----
Надеюсь, мне удалось отшлифовать границу между нашими контекстами восприятия?
Надеюсь, что я вас несильно удивлю, если подмечу: довольно часто продвижениям и открытиям сопутствуют эксперименты и обучение. Где-то менее успешные, где-то более.
Находясь в сфере разработки ПО ощутимое время, уже можно начать замечать те или иные неудобства в тех или иных архитектурных вопросах. Вследствие чего часто возникают альтернативные взгляды и решения (которые, впрочем, и не заявляют себя на пальму единственного первенства).
Когда-то миру был радостно преподнесён и MVC, хотя сейчас от него уже многие воротят нос в крупных проектах.
В этой статье вы имели возможность увидеть еще одну альтернативную пробу архитектурного построения и его жизненный цикл. Таки что вас в итоге смущает, не пойму?
State является персонализированным компонентом для каждого конкретного модуля. Например, для формы входа он может быть таким:
Pipeline это единый для всех модулей generic-компонент (его не надо отдельно писать для каждого модуля), реализация которого на текущий момент выглядит так:
https://github.com/JivoChat/RoundTable/blob/main/RoundTable/Modules/RTEModule/RTEModulePipeline.swift
Понимаю вашу настороженность..
Но здесь Pipeline не является совсем уж отдельным динамическим инструментом.
Это рукописная штука (является частью шаблона для Xcode), которая внутри делает несколько последовательных вызовов в сторону компонентов модуля, то есть фактически не является слепым распространителем данных.
Статический Pipeline, если так выразиться.
Например, вот часть внутренностей Pipeline, которая передаёт Event из Core к остальным:
Вернее, про форматирование речи даже и не было.
Упор был на одновременный учёт следующих аспектов:
— если нет искомой информации для той или иной части фразы, то заменять её дефолтной надписью (или надписями, в зависимости от контекста);
— в разных языках разный порядок слов, то есть нужна адаптивность;
— итоговый способ разметки или записи держать по возможности в одном месте для простоты редактирования.
Или какие возможности форматирования в Swift вы подразумеваете?
У меня тоже недавно был такой случай, но с другой их акцией. Описывал его на своей странице, не на этом ресурсе.
https://www.facebook.com/100001011841994/posts/3090511837659181/
Если суть только в пассивном отображении, то я не использую для таких случаев отдельный модуль, ибо совершенно незачем.
Если сложность заключается в плотности размещения информации, то я не могу считать это сложной ячейкой: могу назвать ее просто визуально загруженной.
Если же попадается часть интерфейса, которая визуально сложна, обладает какой-то дополнительной логикой или же вовсе любит жить своей жизнью, то в этом случае для нее нередко организуется отдельный модуль, да.
Я использую в основном два способа проброса данных (а порой применяю их вместе):
— callback, он показан в том числе в демо-проекте;
— broadcast, при котором тот, кто умеет информацию менять, дает об этом знать, а его слушатели подписываются и реагируют (можно использовать NotificationCenter, но я стараюсь его применять только в тех случаях, когда собственный механизм сложен либо избыточен в пробрасывании вглубь кода).
Я не говорю, что пложу новые архитектуры: я лишь заметил, что мне удобнее оказалось пользоваться более упрощенным вариантом построения кода, которым наверняка итак уже пользуются многие.
К тому же, тут добавляет синтаксическое удобство блочность вместо вызова input/output делегатов, на мой взгляд…
Но мою ситуацию может описать картинка:
И если вдруг очередной прогон теста покажет, например, что валидатор Email работает некорректно или не поддерживает ряд правил, то это повод заменить 3party валидатор или сделать форк.
Ибо неважно, свой код дал сбой или чужой.
Главное — обеспечить выполнение логики программы… во всяком случае, так думаю я.
Если же говорить об использовании компонента, то да, согласен, тоже вариант.
Да и в любом случае, эта статья – не документация, а просто вариант того, как можно справиться подручными средствами в случае необходимости.