А чем MVC и ему подобные не unidirectional? Данные идут из модели во вью, из вью (если мы говорим про современные интерфейсы) в контроллер передаются действия пользователя, который в свою очередь вызывает методы модели, которые обновляют данные и они идут во вью. Круг замкнулся.
Эти громкие новые названия ничего нового практического не приносят.
Вы же себя искусственно ограничили двумя вещами, как по мне:
Завязка на экраны (я сужу по схеме с названием screen logic) самой логики.
Созданием кучи ненужных классов. Это как в VIPER — много всего, а по факту половина не нужна.
И если судить по диаграмме с data store/actor и прочим — вы себя жестко завязали на хранилище, не использовав инверсию, но тут лишь мое предположение, возможно просто использовали упрощение при визуализации, хотя на мой взгляд это критичный момент для отображения если он имеется.
Ну Xcode был не подарком и до выхода Swift. А по поводу того что Swift выкатили недоделанным и это ужасно, а все радуются все же не соглашусь. Они его показали всем и сказали, хотите — пишите на Swift. Не хотите — не пишите. И стали дорабатывать его по отзывам комьюнити, что, на мой взгляд, весьма разумное решение. Сейчас можно увидеть цели и идеи команды разработчиков и внести свои предложения на обсуждение. Имхо, это гораздо лучше, чем получить сферического коня в вакууме.
Только в тех статьях, а не в реальной жизни. Написать долго компилирующийся код можно на чем угодно ведь. Тот же Kotlin часто ставили в сравнение к Свифту, только вот на андроиде он сейчас хуже Свифта первых версий в плане скорости компиляции. А сливать все в один файл — ну так и в других языках можно, что бы линковщику облегчать работу, тоже станет быстро компайлится. А вообще все их проблемы только потому что надо раз в 2 минуты компилировать и запускать проект, потому что… а черт их знает почему они так делают. И это печально, конечно.
у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проект
Была такая же проблема, в подах чего только не было, когда увидели — были в шоке, за месяц подчистили и перевели. Но давайте будем честными, проблема тут изначально не в том что поменяли что-то в новой версии языка (потому что так же само могло все повалиться с новой SDK, будь у Вас Obj-C проект), а в том что накидали pods без разбору и с этим приходится жить.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышу
Я не слухи рассказываю все же, а что происходит в swift-evolution. Они за все время ни разу не обещали что вот прям в следующей версии все будет идеально, они определяли приоритеты и реализовывали, у них с этим все довольно строго. И изначально сказали когда речь пошла про ABI что они два года будут это делать, чем, собственно, и занимаются. Для них это тоже довольно важная вещь и не только потому что ченджи ломают все. Сейчас уже, кстати, можно в 4-м Свифте 3.2 использовать.
да и там точно такие же ломки апи? ;
Я это упомянул не в плане изменений в С++ (за коим уже давно не слежу и статьи здесь на хабре про новшества нового стандарта честно говоря выглядят жутко в плане кол-ва изменений и нововведений), а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
Проблемы «симплификации» как ее тут назвали преувеличены. Во-первых, сами разработчики придумывают себе проблемы и потом героически их решают и рассказывают на конференциях. Да, были некоторые реальные проблемы со скоростью раньше, но даже они касались скорее вырожденных случаев. Нам, например, хватает писать типы в некоторых местах (что бы компайлер не пытался резолвить их а уже точно знал) и разбивать огромное спагетти из optional chaining (в мире свифта это способ развернуть обьект который может быть nil)
По поводу breaking changes тоже много шуму на ровном месте — было сильно больше изменение между первой и второй версией языка, дальше — никаких проблем. Хватало 1 рабочего дня и 1 разработчика перевести большой проект на свифт 3, потом тот же проект на 4ю версию был переведен за час. Больше проблем доставляют не изменения языка, а изменения SDK, просто получается что язык и сдк обновляются в один момент (релиз новой оси). К следующей версии сделают ABI к тому же.
Кстати, не понимаю проблемы с версиями, у C++ например вообще по годам выпуска версии.
Вы конечно извините, но это ужасно. Ладно что 3-я версия языка, не так много поменялось, но:
— полный хаос в написании — в каждом файле/классе по-разному;
— говорил в комментариях к прошлой статье что force optional unwrapping не доглядели, но тут используете его вовсю, при чем и где не надо тоже;
— lazy var (да еще и в паре с предыдущим пунктом) это просто что-то с чем-то;
— почему все еще не DataTask для простейших запросов не понятно;
Пожалуйста, в следующий раз познакомьтесь с языком ближе, перед тем как писать статью.
Пример с пылу-жару: функционал в чатах hold-to-talk. Можно написать в контроллере это и ругать за «массивность», можно сделать то же самое в размазав логику по презентеру и интерактору, а можно выделить модель которая будет описывать поведение и использовать ее, а то что касается UI части, как и писали выше, описать в отдельном controllere и сделать его чайлдом. Сразу и тестируемость, и распределние по отвественности, и отличная переиспользуемость кода.
Что писать, а что нет — решение сугубо индивидуальное. Можно просто следовать хотя бы только SRP и это уже подскажет что и куда. И не придется себя ограничивать различными реализациями и писать лишние слои, когда можно сделать проще. И от этого не пострадает гибкость и тестируемость кода.
Но то что VIPER говорит КАК выделить слои не делает MVC плохим, ведь MVC не запрещает выделять эти слои. Я не понимаю зачем ругать подход, который ничем не ограничивает разработчика, при этом используя его же.
Что мешает выделить логику из «эпловского view controller-a» в отдельные сущности? Вы сильно привязались к самим названиям, а речь в первую очередь о роли класса. Чем презентер в VIPER не контроллер описанный в MVC? Он как раз является посредником между данными и отображением, вполне себе контроллер.
Почему Вы решили, что VIPER это не MVC? Визуальное представление как было, так и осталось. Контроллер как был, так и остался. В конце концов, без модели вы никак не обойдетесь попросту. Вам не кажется что проблема не в MVC изначально? Ведь VIPER и есть MVC, а точнее один из вариантов реализации MVC.
А чем MVC и ему подобные не unidirectional? Данные идут из модели во вью, из вью (если мы говорим про современные интерфейсы) в контроллер передаются действия пользователя, который в свою очередь вызывает методы модели, которые обновляют данные и они идут во вью. Круг замкнулся.
Эти громкие новые названия ничего нового практического не приносят.
Вы же себя искусственно ограничили двумя вещами, как по мне:
И если судить по диаграмме с data store/actor и прочим — вы себя жестко завязали на хранилище, не использовав инверсию, но тут лишь мое предположение, возможно просто использовали упрощение при визуализации, хотя на мой взгляд это критичный момент для отображения если он имеется.
Была такая же проблема, в подах чего только не было, когда увидели — были в шоке, за месяц подчистили и перевели. Но давайте будем честными, проблема тут изначально не в том что поменяли что-то в новой версии языка (потому что так же само могло все повалиться с новой SDK, будь у Вас Obj-C проект), а в том что накидали pods без разбору и с этим приходится жить.
Я не слухи рассказываю все же, а что происходит в swift-evolution. Они за все время ни разу не обещали что вот прям в следующей версии все будет идеально, они определяли приоритеты и реализовывали, у них с этим все довольно строго. И изначально сказали когда речь пошла про ABI что они два года будут это делать, чем, собственно, и занимаются. Для них это тоже довольно важная вещь и не только потому что ченджи ломают все. Сейчас уже, кстати, можно в 4-м Свифте 3.2 использовать.
Я это упомянул не в плане изменений в С++ (за коим уже давно не слежу и статьи здесь на хабре про новшества нового стандарта честно говоря выглядят жутко в плане кол-ва изменений и нововведений), а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
По поводу breaking changes тоже много шуму на ровном месте — было сильно больше изменение между первой и второй версией языка, дальше — никаких проблем. Хватало 1 рабочего дня и 1 разработчика перевести большой проект на свифт 3, потом тот же проект на 4ю версию был переведен за час. Больше проблем доставляют не изменения языка, а изменения SDK, просто получается что язык и сдк обновляются в один момент (релиз новой оси). К следующей версии сделают ABI к тому же.
Кстати, не понимаю проблемы с версиями, у C++ например вообще по годам выпуска версии.
— полный хаос в написании — в каждом файле/классе по-разному;
— говорил в комментариях к прошлой статье что force optional unwrapping не доглядели, но тут используете его вовсю, при чем и где не надо тоже;
— lazy var (да еще и в паре с предыдущим пунктом) это просто что-то с чем-то;
— почему все еще не DataTask для простейших запросов не понятно;
Пожалуйста, в следующий раз познакомьтесь с языком ближе, перед тем как писать статью.
Пример с пылу-жару: функционал в чатах hold-to-talk. Можно написать в контроллере это и ругать за «массивность», можно сделать то же самое в размазав логику по презентеру и интерактору, а можно выделить модель которая будет описывать поведение и использовать ее, а то что касается UI части, как и писали выше, описать в отдельном controllere и сделать его чайлдом. Сразу и тестируемость, и распределние по отвественности, и отличная переиспользуемость кода.
Что писать, а что нет — решение сугубо индивидуальное. Можно просто следовать хотя бы только SRP и это уже подскажет что и куда. И не придется себя ограничивать различными реализациями и писать лишние слои, когда можно сделать проще. И от этого не пострадает гибкость и тестируемость кода.
Но то что VIPER говорит КАК выделить слои не делает MVC плохим, ведь MVC не запрещает выделять эти слои. Я не понимаю зачем ругать подход, который ничем не ограничивает разработчика, при этом используя его же.
Что мешает выделить логику из «эпловского view controller-a» в отдельные сущности? Вы сильно привязались к самим названиям, а речь в первую очередь о роли класса. Чем презентер в VIPER не контроллер описанный в MVC? Он как раз является посредником между данными и отображением, вполне себе контроллер.
Почему Вы решили, что VIPER это не MVC? Визуальное представление как было, так и осталось. Контроллер как был, так и остался. В конце концов, без модели вы никак не обойдетесь попросту. Вам не кажется что проблема не в MVC изначально? Ведь VIPER и есть MVC, а точнее один из вариантов реализации MVC.