Паттерн Прокси (Proxy) в C#. Как использовать в Unity?

[@xanderxk]

Отличные видосы про паттерны! молодец)

[@ziiron322]

Классный видос, но хотелось бв ещё иметь некий "реальный" Пример. Не только в теории, на словах или в пеинте.В любом случае спасибо за видео.

[@andreiraketa6300]

Спасибо

[@ДенисБобаренко]

Спасибо за видео, лайк !!!))) смотрю на нижней панели у Вас ярлык Cocos Creator, что можете сказать о нем в пару словах. Лучше чем Unity для мобилок и web, если не брать размер билда?

[@gamedevlavka]

Я уже выпускал видео с ответом на этот вопрос) kzbin.info/www/bejne/p2aro2Cded2om7c

[@armat_funny_video]

Привет. Лучше использовать Обсервер. Код был бы проще. Ну да, вы сделали прокси чисто для демонстрации, но именно в этом примере так и просится Обсервер паттерн. А так классно объясняешь, молодец

[@RimuruDev]

Благодарю за материал❤ Отличная подача, все просто и локанично.

[@lev431]

Ты жив?Я помню как год назад твои ролики смотрел😅

[@RimuruDev]

@@lev431 ❤

[@chernos]

Привет, можешь посоветовать литературу для использования прокси в мультеплеере.

[@ВасечкаЛазарев]

Друг, это выглядит как декоратор Почему выбрано название "Прокси"?

[@gamedevlavka]

Прокси и декоратор фактически одно и тоже. Прокси был выбран исключением декоратора, т.к. в большинстве случаев в геймдеве декоратор используется для заворачивания бутерброда из декораторов для придания комплексного эффекта. К тому же в видео, я затронул тему валидации данных, что также является больше идеей для прокси, нежели декоратора. Но это всё на уровне идей, факт остается прежним, это одно и тоже

[@CTePeoTun]

А почему на 7:50 свойство решили поднять выше поля?) Везде обычно наоборот для удобства чтения)

[@gamedevlavka]

Ой, это прошу не обращать внимания. Из-за кокоса и особенностей TypeScript, могу забывать, что перед чем идёт, так что я переставил, потом понял что что-то не то, но уже не подал виду)

[@KevinBarker-y5q]

А как вы думаете, паттерн Прокси может улучшить производительность в Unity? я сам выбирал курсы для изучения IT, рассматривал разные компании, но Skypro оказался лучшим вариантом))

[@ANTIM]

это коммент от бота-пиарщика скайпро

[@lDyamonagl]

Надеюсь, если будучи джуном такое делать, работодатель не погонит ссаными тряпками на собеседовании, потому что это формально нарушение принципа инкапсуляции (не в плане ограничения доступа, а я про то определение, которое про то, что пихаем все данные и методы, оперирующие этими данными, в один класс)

[@shenanicode]

Locality of behaviour и инкапсуляция не одно и то же. Всё что показал автор - валидное решение. У такого решения есть свои плюсы, и есть неочевидные минусы. И никто никого гнать за знание паттернов не будет, если эти паттерны будут в руках эксперта. Паттерны не нужно применять в работе в таком виде, в котором вы их изучали. Главное понять их идею

[@lDyamonagl]

@@shenanicode Честно говоря, от locality of behaviour глаз дергается уже. На одном рабочем проекте начальник на нем настаивал, но по факту чуть ли не процедурщину писали обычную, чтобы "ну все в одном месте" (доходило до абсурда - он стирал константы и писал магические числа вместо них, чтобы числа были там же, где и логика). Я прекрасно понимаю, что это ни в каком виде не является инкапсуляцией по определению, потому что тут необязательно идет оперирование одними данными - могут фигурировать и из других сущностей, если здесь и сейчас того требует алгоритм.

[@gamedevlavka]

Если работодатель прогонит за такое ссаными тряпками, то рекомендую не спорить и найти нормального работодателя. Дело в том, что в большинстве случаев на проектах стремятся к архитектуре чистых данных. Приведу контр пример: есть механика строительства, можно строить разные дома за разные ресурсы. А ещё возможность строительства некоторых домов основана на выполнении каких-то квестов. Как произвести валидацию строительства внутри сущности "строение"? Передавать ему все необходимое для валидации? Много ответственности для такой маленькой сущности. А если зависимость от квестов только у одного здания из 50? Можно было бы сказать, что тогда надо валидировать в контроллере - одно место, снаружи сущности. Так это и есть отделение данных от логики. Ну и скажу, что на проектах все строится так, как видит техлид, а техлид не всегда обладает достаточным или валидным опытом, чтобы сделать все надёжно и не менее удобно для работы

[@lDyamonagl]

@@gamedevlavka Понял, спасибо за ответ. Я это в принципе и хотел в качестве ответа получить, а то просто на собесах речь идет о том, что святость принципов ООП непогрешима, и я более чем согласен, что у каждого подхода есть свои плюсы и минусы, и важно уметь оценивать перевес одного над других в рамках конкретных задач перед тем, как начать их решать. У меня лишь возникли затруднения как раз здесь с пониманием, какие конкретно плюсы в таком подходе затмевают минусы нарушения инкапсуляции, а то в одном проекте подобное делали, и там это ощущалось как просто плохой подход по типу пихать везде синглтоны. Еще раз спасибо за разъяснение, запомню.

[@zaylen8389]

Все эти паттерны для меня сложно воспринимаются, потому что я не вижу того, что мы получаем от того, что только что сделали. Реальных примеров как будто не хватает

[@dezoksiribonukleotid5011]

Всё круто, но Па́ттерн Прям уши режет