Зависит от правил и структуры игры. Выделение памяти для любого мидла в геймдеве решить не проблема. Массивы-списки это ещё не плохо. Сейчас не редко реактивку пихают. Поля ID вообще тут при чём? Обычно это появляется при подключении БД.
Геймдев уровня mov [edx],ebx умер больше 30 лет назад. На уровне движков в случае особых оптимизаций это ещё можно встретить, и то, не мала вероятность что за такой код тебя побьют. И правильно, т.к. компиляторы не плохо работают.
Флаги и проверки посреди, в стиле, а всё ли ок с данными, их надо отсортировать, проверить вообще есть ли подходящие и т.д. - признак плохого проектирования в ООП.
Монструозные циклы не редко то же самое) Но тут не всегда, иногда всё же бывают большие циклы, но скорее там, где надо сложную обработку данных и быстродействие, например, обработку мешей.
А, ну и ECS с функциональщиной ничего общего не имеет. По структуре методов это считай процедурка. Вероятно, тебе проще структурировать информацию в ECS. В таком подходе это структурирование является обязательной частью работы, поэтому её не пропустишь - код вообще не будет правильно работать. В ООП в некотором роде схоже нужно структурировать, но можно забить и писать в процедурки
Что мешает без RX на эвентах то же самое сделать? А чтобы проще была сортировка сделать с аргументом по хешу. И тогда кто угодно сможет подписаться и получать данные. Правда, обработка будет идти параллельно, если подписчика 2. Но там уж можно как угодно вертеть под свои нужды
Не сарказм ли это? 90% связующего кода и 10 логики - это прям эталон того, что делается что-то не так.
И это как раз очень плохой код на больших системах, который ещё и разрастается быстро и бесконтрольно. Как минимум, в нём всегда будет ещё много-много строчек кода условий, которые будут говорить как именно перемножать и надо ли это вообще делать, так же там появятся досрочные выходы, и выходы посреди метода(break посреди циклов и return посреди и в начале метода). Это всё как раз ошибки проектирования в OOP. В норме (почти) не должно быть выходов посреди методов, лишних связей, как и управляющих объектов так же минимально - логика внутри объекта.
Я уже десятки команд встречал и соглашусь насчёт ECS полностью. Простые действия в несколько строк в COP(OOP) делаются через создание нескольких файлов. ECS был бы удобен именно как внутренний слой в циклах обработки - почему так не сделали с теми же MB совсем не понимаю.
В большинстве случаев, когда говорят о том, что в ООП плохо, не получается и т.д, и тп = команды просто не могут в ООП. Не могут заранее спроектировать и поддерживать продукт в случае изменений, не умеют этого. Далее опишу основные встречаемые проблемы/
Вот буквально недавно ещё 2 "закатных" проекта видел за последние 3 месяца. В 1 MVP. Во 2 "чистая архитектура" + MVP + ещё message bus на все вызовы(методы) бизнес логики... И вот одна из самых криповых и очень распространённых практик во всех подходах разделения кода на M - M остаётся без логики, чисто данные(или почти так). Это слабоумие преследует команды уже 15 лет! Не так давно я думал, что это уже ушло в прошлое, но нет, это всё ещё часто даже у разрабов с опытом в 5 лет встречается, что другого они и не видели.
Вторая проблема - подходы из других областей. Приходит очередной вебщик, CRM-щик и т.п. И тащат свои системы в Unity. Контроллеры на каждый чих? MVC в худшем его извращённом представлении, где M данных, а С логики. Или просто контроллёры всего подряд, что фактически PP. Видел это десятки раз.
Сейчас ещё почти повсеместно использование DI. Но про контейнеры даже не слышали. Как сделать массовое создание объектов. Вместо удобного управления зависимостями выходит god-контекст. Портянки зависимостей на сотни using. И так почти все проекты. Т.е. люди не научились с ООП зависимостями работать, а тут им подогнали крутой инструмент где их вообще вертеть можно как угодно. Вот они и вертят. Пока не встречал ни 1 проект, где с зависимостями хорошо работали в Unity. Часто наоборот, это было ужасно. Чуть в стороне, но не менее часто ломающий логику ООП и производительность - повсеместно используемый UniRx. Каки другие плюшки из других систем, которые влияют на связи между методами и тем более классами.
А, ну и не достаточно просто сказать - мы делаем M***. Так не работает - нужно нормально проводить дизайн фич, проектировать. Это надо в любой парадигме. А ООП, похоже, сильнее чем прочие зависит от этого. Буквально, всё только в это и упирается - не провели дизайн/проектирование классов и зависимостей, то считайте у вас и не ООП. Да, с опытом можно это делать на ходу, но сначала нужно этот опыт получить.
Логика разная, но интерфейсы одинаковые. Каждый в армии может работать по командам армии, а не, например, игрока. Но при этом действовать как отдельная единица по тем же командам, которые даёт 1 игрок. То же со сражением.
Не понятно при чём тут композиция вообще. Новую логику так или иначе придётся отдельно реализовать, она само по себе не появится.
Ни разу. Это чушь про мотивацию. Вообще, это крайне плохой подход. Отсев по "мотивации", которая не статична во времени, является просто очередным барьером. На деле же говорит только о том, кто может выделить достаточно ресурсов в жесткой форме требований. А люди не просто разные, а ещё и в разных условиях и по разному способны на адаптацию. В то же время какой-то чел забрасывает эти ваши ВУЗ-ы и создаёт теорию эволюции. Да, он проучился в колледже, но так же не особо занимаясь. Однако доступ к знаниям имел. Без этого доступа не было бы знаний. Но с жесткой структурой и без "мотивации" он бы там вообще не учился и теорию скорее всего не создал.
А всё потому, как человек несколько сложнее кем-то выдуманных представлений и о мотивации, и об эффективности. И на деле таких случаев очень много. А такой подход, фактически является, не более, чем инструментом классового расслоения. Большинство молодых людей не знают хотят ли работать по профе, в которой учатся, что в ЮК, что у нас, что в других странах
Никто не мешает повысить ЗП джуну и он не уйдёт, либо вернётся через некоторое время. Часть времени будет уходить на джуна, а джун будет делать задачи, которые иначе бы делал, скажем, мидл, и пусть задача более проста, но после обучения во 2 раз джун будет делать её ни чуть не хуже мидла за ЗП в 2-3 раза меньше. В т.ч. очень простые задачи, которые мидлу надоели и он не хочет ими заниматься. А если таких задач много, и скидываются они на перспективного мидла, то такой мидл уходит. Сколько стоит искать такого мидла?
Единственная причина не брать +- подходящих спецов на задачи уровня джуна именно джуна(и далее по такой же схеме), а брать только сеньоров - невозможность нормального использования в команде(1.5 землекопа в команде) или слабое руководство, что не может наладить процессы и компенсирует это высоким уровнем спецов на любой чих
Тут прям целый набор ошибок дизайна/проектирования) Патроны использующие оружие..Почему сделано ровно наоборот? В норме пушка использует патроны. И это приведёт к проблемам, например, если нужны будут несколько пушек, и, как и тут, они смогут работать с разными патронами. Код придётся переписывать большей частью. Это так же тянет дополнительную связь. Патроны относятся к пушке, и их не должно быть у машины, если это не требуется. Замтен обход реального условия - для определённых пушек или всё же калибра? "Снаряд одного калибра не выстрелит из пушки другого калибра". Что, если из пушки можно будет стрелять другими патронами? Явное указание тут точно не к месту. Вообще, если к каждой пушке планируется только 1 вид патрона на пушку, то стоит ограничится 1 классом - пушкой. А уже для нанесения урона передавать либо данные, либо снаряд/пулю, но никак не патрон.
Так же как и код: public Ammo Shoot() { if (*) Clone(); if (*) return firedAmmo; else return null; else return null; }
Такое использование с выходами посреди метода в целом крайне плохо для читаемости и стоит считать ошибкой. Обычно это вызвано как раз неправильным дизайном. Часто это значит, что условия должны быть в вызывающем методе.
Ну и, замечу, что тут совсем лишнее выделение памяти. Зачем вообще? Если это для задания соответствия, то надо передавать ссылку - мы же запускаем тот же снаряд. Тогда и создавать надо, например, при заряжании, т.е. что зарядили, тем и выстрелили. Это позволит задать, например, условия для мокрой боеукладки у открытой САУ.
По мне так можно сделать дистант дешёвым и даже эффективнее, чем сейчас. Но на деле выходит так, что получается не то чтобы дёшево, и бесполезно. И проблема в том, что идею не могут реализовать правильно
Пока сложность вырастает не более чем на уровень средней сложности запроса к БД это работает. Как только сложность вырастает ещё выше, то рефакторить и поддерживать удобнее систему. А ошибки прошлых этапов описанные тут в этом случае невозможно зарефакторить вообще - только переписывать полностью. К тому времени как это замечает не особо внимательное начальство, весь проект будет уже полностью забит костылями "быстрого рефакторинга внесения изменений". И часто это бывает к моменту релиза) И тут начальство начинает гонять кругами и искать спецов за большие деньги и с большим опытом.
В таких системах нужен план. И это никак не мешает работать по аджайлу, по спринтам, делать код который проще рефакторить и т.п. Нужно сначала разобраться что нужно делать и куда идти, в т.ч. с технической стороны проекта. Заметьте так же, что почти любой проект в норме имеет план реализации продукта, хотя бы просто как список крупных блоков фич. И даже больше нужно для планирования программ сложнее сайтиков полуфабрикатов, чтобы хоть как-то начать. И план этот должен обновляться постоянно, на это надо тратить ресурсы не жалея.
Часто делается совсем не неделю, месяцы. И так же в начале прибыль ничтожная, а ожидается где-то через год+. Быстрое решение, одно за другим, наростает функционал, работа идёт дальше и... В какой-то момент все силы уходят на регресс. Кроме того, переписывание того, что работает? Крайне редко. Никто не будет ждать - конкуренты обгонят пока будешь переписывать всё приложение.
Всё же важен баланс. Ну и часто не стоит отдавать центральную часть проекта "на аутсорс"
Очень простой вопрос прям с конкретным решением по справке. Все по сути то же самое, но чуть удобнее: С гугломAI надо будет написать запрос, перейти по ссылке, найти на сранице в тексте похожие ответы, понять, что это то, что нужно, и потом уже пробовать. Т.е. экономия всего в 1 шаг. AI действительно отличный поисковик)
Пробовать обязательно, потому как далеко не всегда даёт верный ответ, да ещё и обосновать может его верность. Вот пример с гитом был. Изменения в ветке сделаны на несколько коммитов, нужно сделать из них 1, перед этим обновив ветку с удалённого репозитория. Несколько не смогли ответить верно вообще
Разница по покупке ДМС "оптовой" и "в розницу" очень большая. Когда смотрел, на семью выкладывать около 400к нужно было. Если через компанию, которая является только неким агрегатором(загупщиком), то на 30-40% дешевле. Про вычет не знал. С ним получается уже +- нормальная цена и для среднего разраба
Из-за народа. СССР сыпался по всем фронтам. И сыпался он в т.ч. по той простой причине, что народу был не нужен и даже враждебен. Не сами идеи даже, а то, как их извратили. Этому как раз тупые способствовали. И даже не политики, а номенклатура целиком, весь правящий класс.
Емнип, в случае связанности товаров, можно запросить возврат всей суммы чека. Это работает и в иных случаях, без обмана. Например, купил трактор, к нему инвентарь. Трактор сломан. Инвентарь так же подлежит возврату, т.к. представляет ценность только вместе с трактором.
А вот мне не понятно как документировать проверку. Например, идёт плохой запах от устройства(жжёная проводка). Продавец говорит, что запаха нет. Ты говоришь есть. И что?
И 2-ое, как присутствовать на экспертизе, если товар забирают за 1к км от тебя? Фактически этого права лишают же
Э, нет. Тут уже чушь несёшь! Ну или может закон поменялся, разрешили произвол, а я и не знаю? Когда я покупаю в инете я не читаю договор и не заключаю его но каждую покупку. Т.е. все покупки проходят по публичной оферте. И тут конкретный продавец - маркет. Он не является посредником в сделке. Он назначает цену, является тем кому я перевожу деньгия, является тем, кто устанавливает правила получения товара и его описание. Т.е. по всем признакам является продавцом. Точно таким же как продавец в обычном магазине. А все претензии решает магазин, а не завод, например. В случае публичной оферты - магазин может идти со своими договором подтираться. И уж никак это не соответствует духу закона! По крайней мере того закона, который был до 22 года. Есть и примеры решения таких ситуаций, например, с такси, который тоже "всего лишь агрегатор"(нет). Впрочем, не удивлюсь, что после 22 и тут на закон положили
Зависит от правил и структуры игры. Выделение памяти для любого мидла в геймдеве решить не проблема. Массивы-списки это ещё не плохо. Сейчас не редко реактивку пихают. Поля ID вообще тут при чём? Обычно это появляется при подключении БД.
Геймдев уровня mov [edx],ebx умер больше 30 лет назад. На уровне движков в случае особых оптимизаций это ещё можно встретить, и то, не мала вероятность что за такой код тебя побьют. И правильно, т.к. компиляторы не плохо работают.
Флаги и проверки посреди, в стиле, а всё ли ок с данными, их надо отсортировать, проверить вообще есть ли подходящие и т.д. - признак плохого проектирования в ООП.
Монструозные циклы не редко то же самое) Но тут не всегда, иногда всё же бывают большие циклы, но скорее там, где надо сложную обработку данных и быстродействие, например, обработку мешей.
А, ну и ECS с функциональщиной ничего общего не имеет. По структуре методов это считай процедурка. Вероятно, тебе проще структурировать информацию в ECS. В таком подходе это структурирование является обязательной частью работы, поэтому её не пропустишь - код вообще не будет правильно работать. В ООП в некотором роде схоже нужно структурировать, но можно забить и писать в процедурки
Что мешает без RX на эвентах то же самое сделать? А чтобы проще была сортировка сделать с аргументом по хешу. И тогда кто угодно сможет подписаться и получать данные. Правда, обработка будет идти параллельно, если подписчика 2. Но там уж можно как угодно вертеть под свои нужды
MVC, MVP, MVVM и все прочие с выделением модели
Не сарказм ли это?
90% связующего кода и 10 логики - это прям эталон того, что делается что-то не так.
И это как раз очень плохой код на больших системах, который ещё и разрастается быстро и бесконтрольно. Как минимум, в нём всегда будет ещё много-много строчек кода условий, которые будут говорить как именно перемножать и надо ли это вообще делать, так же там появятся досрочные выходы, и выходы посреди метода(break посреди циклов и return посреди и в начале метода). Это всё как раз ошибки проектирования в OOP. В норме (почти) не должно быть выходов посреди методов, лишних связей, как и управляющих объектов так же минимально - логика внутри объекта.
Это ни разу не ООП, это как раз вариация ПП.
Я уже десятки команд встречал и соглашусь насчёт ECS полностью. Простые действия в несколько строк в COP(OOP) делаются через создание нескольких файлов. ECS был бы удобен именно как внутренний слой в циклах обработки - почему так не сделали с теми же MB совсем не понимаю.
В большинстве случаев, когда говорят о том, что в ООП плохо, не получается и т.д, и тп = команды просто не могут в ООП. Не могут заранее спроектировать и поддерживать продукт в случае изменений, не умеют этого. Далее опишу основные встречаемые проблемы/
Вот буквально недавно ещё 2 "закатных" проекта видел за последние 3 месяца. В 1 MVP. Во 2 "чистая архитектура" + MVP + ещё message bus на все вызовы(методы) бизнес логики... И вот одна из самых криповых и очень распространённых практик во всех подходах разделения кода на M - M остаётся без логики, чисто данные(или почти так). Это слабоумие преследует команды уже 15 лет! Не так давно я думал, что это уже ушло в прошлое, но нет, это всё ещё часто даже у разрабов с опытом в 5 лет встречается, что другого они и не видели.
Вторая проблема - подходы из других областей. Приходит очередной вебщик, CRM-щик и т.п. И тащат свои системы в Unity. Контроллеры на каждый чих? MVC в худшем его извращённом представлении, где M данных, а С логики. Или просто контроллёры всего подряд, что фактически PP. Видел это десятки раз.
Сейчас ещё почти повсеместно использование DI. Но про контейнеры даже не слышали. Как сделать массовое создание объектов. Вместо удобного управления зависимостями выходит god-контекст. Портянки зависимостей на сотни using. И так почти все проекты. Т.е. люди не научились с ООП зависимостями работать, а тут им подогнали крутой инструмент где их вообще вертеть можно как угодно. Вот они и вертят. Пока не встречал ни 1 проект, где с зависимостями хорошо работали в Unity. Часто наоборот, это было ужасно.
Чуть в стороне, но не менее часто ломающий логику ООП и производительность - повсеместно используемый UniRx. Каки другие плюшки из других систем, которые влияют на связи между методами и тем более классами.
А, ну и не достаточно просто сказать - мы делаем M***. Так не работает - нужно нормально проводить дизайн фич, проектировать. Это надо в любой парадигме. А ООП, похоже, сильнее чем прочие зависит от этого. Буквально, всё только в это и упирается - не провели дизайн/проектирование классов и зависимостей, то считайте у вас и не ООП. Да, с опытом можно это делать на ходу, но сначала нужно этот опыт получить.
Логика разная, но интерфейсы одинаковые. Каждый в армии может работать по командам армии, а не, например, игрока. Но при этом действовать как отдельная единица по тем же командам, которые даёт 1 игрок. То же со сражением.
Не понятно при чём тут композиция вообще. Новую логику так или иначе придётся отдельно реализовать, она само по себе не появится.
Ни разу. Это чушь про мотивацию. Вообще, это крайне плохой подход. Отсев по "мотивации", которая не статична во времени, является просто очередным барьером. На деле же говорит только о том, кто может выделить достаточно ресурсов в жесткой форме требований. А люди не просто разные, а ещё и в разных условиях и по разному способны на адаптацию. В то же время какой-то чел забрасывает эти ваши ВУЗ-ы и создаёт теорию эволюции. Да, он проучился в колледже, но так же не особо занимаясь. Однако доступ к знаниям имел. Без этого доступа не было бы знаний. Но с жесткой структурой и без "мотивации" он бы там вообще не учился и теорию скорее всего не создал.
А всё потому, как человек несколько сложнее кем-то выдуманных представлений и о мотивации, и об эффективности. И на деле таких случаев очень много. А такой подход, фактически является, не более, чем инструментом классового расслоения. Большинство молодых людей не знают хотят ли работать по профе, в которой учатся, что в ЮК, что у нас, что в других странах
Никто не мешает повысить ЗП джуну и он не уйдёт, либо вернётся через некоторое время. Часть времени будет уходить на джуна, а джун будет делать задачи, которые иначе бы делал, скажем, мидл, и пусть задача более проста, но после обучения во 2 раз джун будет делать её ни чуть не хуже мидла за ЗП в 2-3 раза меньше. В т.ч. очень простые задачи, которые мидлу надоели и он не хочет ими заниматься. А если таких задач много, и скидываются они на перспективного мидла, то такой мидл уходит. Сколько стоит искать такого мидла?
Единственная причина не брать +- подходящих спецов на задачи уровня джуна именно джуна(и далее по такой же схеме), а брать только сеньоров - невозможность нормального использования в команде(1.5 землекопа в команде) или слабое руководство, что не может наладить процессы и компенсирует это высоким уровнем спецов на любой чих
Тут прям целый набор ошибок дизайна/проектирования)
Патроны использующие оружие..Почему сделано ровно наоборот? В норме пушка использует патроны. И это приведёт к проблемам, например, если нужны будут несколько пушек, и, как и тут, они смогут работать с разными патронами. Код придётся переписывать большей частью. Это так же тянет дополнительную связь. Патроны относятся к пушке, и их не должно быть у машины, если это не требуется.
Замтен обход реального условия - для определённых пушек или всё же калибра? "Снаряд одного калибра не выстрелит из пушки другого калибра". Что, если из пушки можно будет стрелять другими патронами? Явное указание тут точно не к месту.
Вообще, если к каждой пушке планируется только 1 вид патрона на пушку, то стоит ограничится 1 классом - пушкой. А уже для нанесения урона передавать либо данные, либо снаряд/пулю, но никак не патрон.
Так же как и код:
public Ammo Shoot() {if (*)
Clone();if (*)return firedAmmo;elsereturn null;elsereturn null; }Такое использование с выходами посреди метода в целом крайне плохо для читаемости и стоит считать ошибкой. Обычно это вызвано как раз неправильным дизайном. Часто это значит, что условия должны быть в вызывающем методе.
Ну и, замечу, что тут совсем лишнее выделение памяти. Зачем вообще? Если это для задания соответствия, то надо передавать ссылку - мы же запускаем тот же снаряд. Тогда и создавать надо, например, при заряжании, т.е. что зарядили, тем и выстрелили. Это позволит задать, например, условия для мокрой боеукладки у открытой САУ.
PS: "Когда в руках молоток..."
По мне так можно сделать дистант дешёвым и даже эффективнее, чем сейчас. Но на деле выходит так, что получается не то чтобы дёшево, и бесполезно. И проблема в том, что идею не могут реализовать правильно
Пока сложность вырастает не более чем на уровень средней сложности запроса к БД это работает. Как только сложность вырастает ещё выше, то рефакторить и поддерживать удобнее систему. А ошибки прошлых этапов описанные тут в этом случае невозможно зарефакторить вообще - только переписывать полностью. К тому времени как это замечает не особо внимательное начальство, весь проект будет уже полностью забит костылями "быстрого
рефакторингавнесения изменений". И часто это бывает к моменту релиза) И тут начальство начинает гонять кругами и искать спецов за большие деньги и с большим опытом.В таких системах нужен план. И это никак не мешает работать по аджайлу, по спринтам, делать код который проще рефакторить и т.п. Нужно сначала разобраться что нужно делать и куда идти, в т.ч. с технической стороны проекта. Заметьте так же, что почти любой проект в норме имеет план реализации продукта, хотя бы просто как список крупных блоков фич. И даже больше нужно для планирования программ сложнее сайтиков полуфабрикатов, чтобы хоть как-то начать. И план этот должен обновляться постоянно, на это надо тратить ресурсы не жалея.
Часто делается совсем не неделю, месяцы. И так же в начале прибыль ничтожная, а ожидается где-то через год+. Быстрое решение, одно за другим, наростает функционал, работа идёт дальше и... В какой-то момент все силы уходят на регресс.
Кроме того, переписывание того, что работает? Крайне редко. Никто не будет ждать - конкуренты обгонят пока будешь переписывать всё приложение.
Всё же важен баланс. Ну и часто не стоит отдавать центральную часть проекта "на аутсорс"
Очень простой вопрос прям с конкретным решением по справке. Все по сути то же самое, но чуть удобнее:
С
гугломAI надо будет написать запрос,перейти по ссылке,найтина сраницев тексте похожие ответы, понять, что это то, что нужно, и потом уже пробовать.Т.е. экономия всего в 1 шаг. AI действительно отличный поисковик)
Пробовать обязательно, потому как далеко не всегда даёт верный ответ, да ещё и обосновать может его верность. Вот пример с гитом был. Изменения в ветке сделаны на несколько коммитов, нужно сделать из них 1, перед этим обновив ветку с удалённого репозитория. Несколько не смогли ответить верно вообще
Про риски не забудь. Потому как бывает, что там можно отъехать, и не всегда за решётку.
Разница по покупке ДМС "оптовой" и "в розницу" очень большая. Когда смотрел, на семью выкладывать около 400к нужно было. Если через компанию, которая является только неким агрегатором(загупщиком), то на 30-40% дешевле. Про вычет не знал. С ним получается уже +- нормальная цена и для среднего разраба
Из-за народа. СССР сыпался по всем фронтам. И сыпался он в т.ч. по той простой причине, что народу был не нужен и даже враждебен. Не сами идеи даже, а то, как их извратили. Этому как раз тупые способствовали. И даже не политики, а номенклатура целиком, весь правящий класс.
Емнип, в случае связанности товаров, можно запросить возврат всей суммы чека. Это работает и в иных случаях, без обмана. Например, купил трактор, к нему инвентарь. Трактор сломан. Инвентарь так же подлежит возврату, т.к. представляет ценность только вместе с трактором.
А вот мне не понятно как документировать проверку. Например, идёт плохой запах от устройства(жжёная проводка). Продавец говорит, что запаха нет. Ты говоришь есть. И что?
И 2-ое, как присутствовать на экспертизе, если товар забирают за 1к км от тебя? Фактически этого права лишают же
Э, нет. Тут уже чушь несёшь! Ну или может закон поменялся, разрешили произвол, а я и не знаю? Когда я покупаю в инете я не читаю договор и не заключаю его но каждую покупку. Т.е. все покупки проходят по публичной оферте. И тут конкретный продавец - маркет. Он не является посредником в сделке. Он назначает цену, является тем кому я перевожу деньгия, является тем, кто устанавливает правила получения товара и его описание. Т.е. по всем признакам является продавцом. Точно таким же как продавец в обычном магазине. А все претензии решает магазин, а не завод, например. В случае публичной оферты - магазин может идти со своими договором подтираться. И уж никак это не соответствует духу закона! По крайней мере того закона, который был до 22 года. Есть и примеры решения таких ситуаций, например, с такси, который тоже "всего лишь агрегатор"(нет). Впрочем, не удивлюсь, что после 22 и тут на закон положили