DK
не понимаю зачем задавать вопрос а потом скатываться в холивар
Size: a a a
2021 April 19
В
А как ты VM инжектишь в свои VC?
Д
Ок, я расскажу подробнее - метод foo(), он указан в публичном интерфейсе, но другого протокола. Этот протокол, среди прочих, реализуется
ConcreteVC’ом. То, что ты называешь зависимостью от реализации по сути не является зависимостью, ибо она опциональна. Дефолтная имплементация может быть (при совпадении условий, требуемых ею), либо отсутствовать, тогда реализуй сам этот метод foo().В
Я вижу в экстеншене протокола метод print, а не foo.
Д
Я упростил, чтобы было понятнее и не загромождать лишней информацией
В
Ты меня совсем запутал.
Ты подключаешь 2 протокола, в втором есть реализация метода из 1 протокола?
Ты подключаешь 2 протокола, в втором есть реализация метода из 1 протокола?
Д
Сейчас у меня проект, где верстка польностью идет кодом, поэтому да, я могу задженерить VC, но придется довольно много переколбасить. Да и сложность проекта, когда все обмазано дженериками растет экспоненциально. Хотелось бы раз и навсегда разобраться во всем этом associatedtype
В
Ты сейчас экспоненту на экспоненту положил вот этой выдуманной схемой.
В
Почему ты просто не сделаешь протокол для описания VM?
Д
Вот более точный пример
ConcreteVC должен реализовать метод printAll() ибо того требует протокол AllPrintable. Дефолтная реализация для протокола PrintingViewController может предоставить дефолтную реализацию этого метода, если viewModel умеет в Printable. Если viewModel другого типа - реализуй printAll() как считает нужным самВ
Окей, задам-таки вопрос: Зачем тебе у конкретного VC VM под протоколом?
Д
И все это работает, но только если viewModel является классом/структурой/enum. Но не протоколом
Д
Вопрос в том, зачем закрывать виью модели протоколами и абстрагироваться от их конкретных реализаций?
Д
Ответ - в проекте есть unit тесты, которые под видом viewModels кидают mock объекты
В
Ну и второй вопрос: зачем тебе в притабл протоколе viewModel под ассоциацией ?
В
Окей, с этим разобрались. Главное что не “ради протокола".
В
Я прост хочу помочь задавая вопросы уже. Вдруг у тебя мысль поменяется. Так как рил задачка упирается в сториборд))
Д
Ну не только в сториборд. Не все любят проекты, где VC на дженериках. Просто я когда каждый раз хочу избавиться от дублирования кода, и не уходить в ООП, все это сводится к дженерикам, которые уходят в другие дженерики и далее по всему проекту. И это если только верстка идет без сторибордов. А такой проект мне впервые достался.
Немного изменил пример, может будет казаться более понятным:
Немного изменил пример, может будет казаться более понятным:
Д
Printable это лишь протокол, который реализует viewModel внутри VC. VC не знает ничего об ассоциации. Ассоциация нужна для того, чтобы подмешать это дефолтное поведение разным VC, которых объединяет лишь одно - их viewModel (не важно какой у нее тип в итоге) реализует Printable. Пометка любой VC этим протоколом может дать ей дефолтное поведение (а может и не дать, если viewModel вообще левая)