"Без такого адаптера "Вид" в VIP будет все знать о бизнес-логике".
Не всё. Вид является источником команд для интерактора. Он осуществляет управляющие воздействия на интерактор, ничего не зная о том, как интерактор будет реагировать на управляющие воздействия.
Просто, похоже, что VIP – это не "чистая архитектура" от дяди Боба.
Сама концепция чистой архитектуры от Мартина, помимо чистых компонент, подразумевает неизбежное присутствие и грязных. В архитектурном шаблоне SVIP чистым является интерактор. Именно на изоляцию бизнес-логики в интеракторе, и его тестируемость (и только его) были направлены усилия при создании шаблона SVIP. Презентер и вид не являются чистыми компонентами. Обоснование этого решения развернуто изложено в статье.
Вы не считаете это ошибкой реализации VIP относительно описанных у дяди Боба колец с адаптерами?
Не считаю. Само наличие концентрических колец в схеме Мартина указывает с одной стороны направление зависимостей, а с другой на ослабление чистоты уровней от центра вовне.
У Мартина контроллер приведен для примера как сущность за пределами вариантов использования. Не следует связывать контроллер с картинки Мартина с какой-то конкретной сущностью в iOS. С точки зрения Мартина контроллер это то что формирует запросы в интерактор. То есть, у нас это Вид.
А причем тут "чистая функция"? Мы тут вроде бы о "чистой архитектуре" рассуждаем, которая вообще никак к с чистой функцией не пересекается. Это вообще разные понятия.
Например в чистой архитектуре нельзя просто так взять и подгрузить данные по мере выполнения бизнес-логики. Сущность ничего не должна знать о БД.
Почему нельзя? В моём прдставлении, для чистой бизнес-логики фронтенда есть понятие абстрактного источника данных (как он реализован - внешняя деталь). Берите из этого источника и подгружайте данные. И даже внутри бизнес-логики фронтенда можно различать источник данных и кэш данных (персистентный и, опять же абстрактный). Выбирать откуда, когда и какие данные брать и что показывать - это бизнес-логика. А вот реализация кэша данных или источника данных - это внешняя деталь за пределами бизнес-логики. И даже обработка ошибок при получении данных - это тоже внешняя деталь за пределами бизнес-логики.
Кажется, SL имеет право на существование. Но применение его лучше ограничить. В моей практике (на iOS), архитектурный модуль разбивается на две части: Чистую и Грязную (термины Роберта Мартина). Чистая содержит всю логику и обладает свойствами чистой архитетуры (SOLID). Грязная часть занимается конфигурированием чистой (называется <Module>Configurator>) и передачей управления в другой модуль (называется <Module>Router). Вот в конфигуратор и роутер вполне уместно передавать SL. Конфигуратор применя стратегию Pull вытягивает все внешние зависимости и применяя стратегию Push собирает (конфигурирует) архитектурный модуль. Таким образом, вся информация о внешних зависимостях модуля локализуется в конфигураторе. А SL из роутера одного модуля передаётся в конфигуратор другого (который SL передаёт в свой роутер и т.д)
Set прекрасен, но требует чтобы добавляемые в него элементы были Hashable. К сожалению, функции, замыкания и методы классов нельзя хэшировать. Что делает его непригодным для применения в нашем случае.
KVO да, но им пользоваться крайне неудобно и к тому же вы ограничены только objc классами. И не ко всем свойствам применимо KVO, а только к KVO compliant. Property Wrappers и Property Observers имеют весьма отдалённое отношение к обсуждаемой теме.
Статья на которую вы ссылаетесь описывает возможности функций в Swift. B качестве иллюстрации там приведён полуфункциональный пример add(target:, action). Без возможности удаления слушателей как в UIControl и без поддержки responder chain. Да ещё с избыточной заумью. В статье target.map(action)?(view) можно заменить на target?.action(view). Всем моим критериям пример из статьи не удовлетворяет. (Например нет возможности удаления слушателей - а если добавить она будет неэффективной). В моей статье есть краткое сравнение с UIControl и NotificationCenter. Кажется, этого достаточно. Моя статья не имела целью раскрывать возможности функций в языке Swift. Этому посвящено множество других метриалов, в том числе тот на который вы ссылаетесь.
Непонятна ваша настойчивость. Observer - универсальный шаблон проектирования. Из набора GOF. Если Responder Chain (тоже из GOF) прекрасно работала и без моего Observer, зачем пытаться натягивать Сову на Глобус Observer на ResponderChain? Уже писал: подумайте об Observer когда вам нужен NotificationCenter или что-то похожее.
Совершенно необоснованный вывод о заточке под "конкретно работу с responder chain" - в UIControl вполне успешно работает классический подход. Представленное решение скорее децентрализованная альтернатива для NotificationCenter. У NC - есть ещё один минус. Либо использовать @obj-c методы либо обязательная ручная отписка. Основной же прицел был представить качественную альтернативу самописным MulticastDelegate. Я несколько раз с ними встречался в различных проектах и каждый раз это было унылым г-кодом.
Вероятно у вас даже получилось бы примерно то же самое, но с массивной и сравнительно медленной (backpressure management) инфраструктурой и внешней зависимостью от Combine. Если вам нужна backpressure, пожалуйста - пользуйтесь Combine.
Вы не поняли. У тётеньки возникли проблемы с тем чтобы уложить кодовую базу в 150 мегабайт. Это я ошибся. И вопрос был не в ресурсах, а именно в кодовой базе — я специально уточнял у неё этот момент.
На MBLTDev18 слушал доклад Тимлида Uber — тётенька рассказывала что делать если проект по причине Huge Codebase не влазит в отведённые Эплом максимальные размеры скачиваемого дистирибутива (вроде 60Mb). Одна из первых рекомендаций была «отказ от Swift».
Доклад называется «Ellie Shin, Uber Putting Your App on a Diet» Лежит здесь
Опечатки:
"вместо этого, вот так: [0-9]{3}.[0-9]{4}"
В оригинале
[0-9]{3}.*[0-9]{4}"Swift должен парсиьб строку"
Исправьте пожалуйста.
Не всё. Вид является источником команд для интерактора. Он осуществляет управляющие воздействия на интерактор, ничего не зная о том, как интерактор будет реагировать на управляющие воздействия.
Сама концепция чистой архитектуры от Мартина, помимо чистых компонент, подразумевает неизбежное присутствие и грязных. В архитектурном шаблоне SVIP чистым является интерактор. Именно на изоляцию бизнес-логики в интеракторе, и его тестируемость (и только его) были направлены усилия при создании шаблона SVIP. Презентер и вид не являются чистыми компонентами. Обоснование этого решения развернуто изложено в статье.
Не считаю. Само наличие концентрических колец в схеме Мартина указывает с одной стороны направление зависимостей, а с другой на ослабление чистоты уровней от центра вовне.
У Мартина контроллер приведен для примера как сущность за пределами вариантов использования. Не следует связывать контроллер с картинки Мартина с какой-то конкретной сущностью в iOS. С точки зрения Мартина контроллер это то что формирует запросы в интерактор. То есть, у нас это Вид.
А причем тут "чистая функция"? Мы тут вроде бы о "чистой архитектуре" рассуждаем, которая вообще никак к с чистой функцией не пересекается. Это вообще разные понятия.
Почему нельзя? В моём прдставлении, для чистой бизнес-логики фронтенда есть понятие абстрактного источника данных (как он реализован - внешняя деталь). Берите из этого источника и подгружайте данные. И даже внутри бизнес-логики фронтенда можно различать источник данных и кэш данных (персистентный и, опять же абстрактный). Выбирать откуда, когда и какие данные брать и что показывать - это бизнес-логика. А вот реализация кэша данных или источника данных - это внешняя деталь за пределами бизнес-логики. И даже обработка ошибок при получении данных - это тоже внешняя деталь за пределами бизнес-логики.
Кажется, SL имеет право на существование. Но применение его лучше ограничить. В моей практике (на iOS), архитектурный модуль разбивается на две части: Чистую и Грязную (термины Роберта Мартина). Чистая содержит всю логику и обладает свойствами чистой архитетуры (SOLID). Грязная часть занимается конфигурированием чистой (называется <Module>Configurator>) и передачей управления в другой модуль (называется <Module>Router). Вот в конфигуратор и роутер вполне уместно передавать SL. Конфигуратор применя стратегию Pull вытягивает все внешние зависимости и применяя стратегию Push собирает (конфигурирует) архитектурный модуль. Таким образом, вся информация о внешних зависимостях модуля локализуется в конфигураторе. А SL из роутера одного модуля передаётся в конфигуратор другого (который SL передаёт в свой роутер и т.д)
Спасибо за перевод
Вместо animator.isReversed = !animator.isReversedможно писатьanimator.isReversed.toggleSet прекрасен, но требует чтобы добавляемые в него элементы были Hashable. К сожалению, функции, замыкания и методы классов нельзя хэшировать. Что делает его непригодным для применения в нашем случае.
KVO да, но им пользоваться крайне неудобно и к тому же вы ограничены только objc классами. И не ко всем свойствам применимо KVO, а только к KVO compliant. Property Wrappers и Property Observers имеют весьма отдалённое отношение к обсуждаемой теме.
Статья на которую вы ссылаетесь описывает возможности функций в Swift. B качестве иллюстрации там приведён полуфункциональный пример add(target:, action). Без возможности удаления слушателей как в UIControl и без поддержки responder chain. Да ещё с избыточной заумью.
В статье
target.map(action)?(view)можно заменить наtarget?.action(view). Всем моим критериям пример из статьи не удовлетворяет. (Например нет возможности удаления слушателей - а если добавить она будет неэффективной). В моей статье есть краткое сравнение с UIControl и NotificationCenter. Кажется, этого достаточно. Моя статья не имела целью раскрывать возможности функций в языке Swift. Этому посвящено множество других метриалов, в том числе тот на который вы ссылаетесь.Непонятна ваша настойчивость. Observer - универсальный шаблон проектирования. Из набора GOF. Если Responder Chain (тоже из GOF) прекрасно работала и без моего Observer, зачем пытаться натягивать
Сову на ГлобусObserver на ResponderChain?Уже писал: подумайте об Observer когда вам нужен NotificationCenter или что-то похожее.
Совершенно необоснованный вывод о заточке под "конкретно работу с responder chain" - в UIControl вполне успешно работает классический подход. Представленное решение скорее децентрализованная альтернатива для NotificationCenter. У NC - есть ещё один минус. Либо использовать @obj-c методы либо обязательная ручная отписка. Основной же прицел был представить качественную альтернативу самописным MulticastDelegate. Я несколько раз с ними встречался в различных проектах и каждый раз это было унылым г-кодом.
Вероятно у вас даже получилось бы примерно то же самое, но с массивной и сравнительно медленной (backpressure management) инфраструктурой и внешней зависимостью от Combine. Если вам нужна backpressure, пожалуйста - пользуйтесь Combine.
Доклад называется «Ellie Shin, Uber Putting Your App on a Diet»
Лежит здесь