Привет. на 11:28 проговаривается, что класс DamageDecorator абстрактный (и по схеме UML так должно быть), но в коде же обычный класс ? Спасибо за отличные лекции по паттернам )
Бро, лучший)) Сейчас задумываюсь о том, чтобы работу найти, твои ролики для повторения материала и изучения нового - просто спасение :D. Респект, лайк и подписка. Даешь полезный контент!
Спасибо большое за контент. Материал на уровне+мемы кайф. Я не видел роликов с такой подачей(а с ивлеевой в начале я просто выпал, за подбор мемов +100500 респекта). Когда я разрабатывал меню для игры с вводом username на mvc было куча вопросов и я рад, что это видео дало понимание и я больше не буду страдать подобным(кста, сам пишу не на шарпах). Не останавливайся, такого реально на русском айти ютубе не хватает👍
Автор можешь раскрыть вопрос и проблему, зачем вообще нужен зенжект если приходится прокидывать руками сылки и запоминать где что прокидывать и при этом этих ссылок нужно прокинуть в 2 раза больше в место одной ссылки без зенжекта, либо вообще использовать GetComponent и забыть про прокидывение ссылок. в чем его преимущество над обычным GetComponent? У меня есть огромный проект где очень много зависимостей, я не использую конструкторы в unity вообще, без них в 100 раз удобнее и руками не прокидываю ссылку на объекты. Вопрос - мне точно станет легче если я внедрю в свой проект зенджек где мне придется думать куда что руками в какую ссылку какой объект прокинуть, а если случайно все ссылки сбросились мне нужно вспоминать и каждый раз прокидывать ссылки в ручную?
1. В зенджекте тебе нужно по минимуму прокинуть зависимостей. В инсталлере и в месте где тебе нужен тот или иной класс-сервис. Это не много, это мало и необходимый минимум. И написать код биндинга или тэг Inject - это как раз таки не вручную, вручную это прокидывать ссылки на монобех компоненты на сцене. Для зенджекта ручками ты просто настраиваешь инсталлер и scene-context, но это ты делаешь в одном месте а дальше все делает код 2. GetComponent ищет компоненты на том объекте - на котором находится скрипт вызывающий этот самый GetComponent. Если у тебя есть класс Enemy, и тебе внутри него нужно сообщить какому-нибудь EnemyController что враг умер - GetComponent не поможет, так как скорее всего EnemyController и Enemy - это разные GameObject-ы. 3. GetComponent(а могу предположить что ты ещё используешь FindObjectOfType) - это довольно дорогие по производительности операции. GetComponent ещё куда ни шло, а вот FindObjectOfType это тупо перебор по всем объектам на сцене. Их лучше избегать. Вообще интересно посмотреть твой проект, если там нет NDA и проект есть на гитхабе, напиши мне в тг, мне любопытно - как ты его так организовал, что у тебя там всё на GetComponent организовано. Потому что если у тебя большой проект и ты прокидываешь зависимости - тут либо DI, либо сервис-локатор, либо синглтоны, либо ECS - что в принципе те же синглтоны. А какая архитектура у тебя сейчас там - мне непонятно :D
@@sergeykazantsev1655 MonoBehaviour - Если нужно просто прокинуть одну строку кода - ссылку в качестве зависимости, компонент который есть в иерархии. Если нужна зависимость в классе не MonoBehaviour то через параметры функций или Singleton. Если попытаться прокинуть зависимости через Zenject к примеру в тот же класс который имеет экземпляры и является ScriptableObject или еще хуже класс, который является свойством класса, который унаследован от ScriptableObject, то придется создавать еще несколько дополнительных скриптов, потом скрипт installer и так далее. если что то пошло не так то будет сложно разобраться где и в чем проблема.
Ну понятно - получается у тебя синглтоны и ручные ссылки на монобех компоненты. Ну вот с ручными ссылками никогда проблем не возникало? Если в проекте несколько сцен, то где-то в компонент надо то ссылку на камеру, то на другой gameObject прокинуть. А если префаб поменять - ссылка может побиться и потеряться. А в зенжекте - новый класс - две новых строчки, ничего особенно большого Со ScriptableObject вообще проблем быть не должно ибо в Zenject-е вроде есть инструментарий подгрузки данных из них.
Если бы все объяснения начинались с "в чем вообще проблема и что будет без этого решения", мы наверное бы уже Марс терраформировали. Спасибо за хорошее объяснение.
Странный пример выбрал автор, сразу нарушив принцип O (The Open Closed Principle). Раз уж на то пошло MovementController должен принимать коллекцию экземпляров типа IMoveble.
Слушай, а для юнити вообще важно качество кода, чтобы делать игры? То что ты объясняешь, помогает писать меньше кода, и это круто. Но есть много другого, чтобы оптимизировать свой код и сделать его читабельнее. С одной стороны не хочется быть ЯгдереДевом, а с другой не хочется потратить время на дрочку 0.00000001 секунды скорости запуска
Качество кода даёт гибкость, а значит в долгосрочной перспективе при добавлении новой фичи ты будешь меньше тратить на нее время. Вообще есть мнение, что чем жирнее и крупнее проект, тем выше должно быть качество кода. На конвейере гиперказуалок, где делают прототипы за три недели, требований к коду меньше. Но вообще мое мнение заключается в том, что хороший разраб может писать качественный код так же быстро, как некачественный. Потому что качественный код это простой/читаемый/удобно расширяемый а не супер умный и сложный код
Не могу ответить на комент, почему-то 47 процентов разрабов на стим заработали больше $1000 по статистике самого стима, можно загуглить статью на хабре, бд стима. Но статистка только про тех, у кого есть платные игры
@@sergeykazantsev1655 Видно сообщение со ссылкой выше на хабр? Статистика стима, но там про разрабов, у которых есть платные игры. И это всё с помехой на первые проекты на юнити
Декоратор использует И наследование и агрегацию. При наследовании мы наследуемся от базового класса (знак :). Если мы имеем ссылку на базовый объект, это значит что мы поместили базовый объект внутрь, то есть агрегация
Здравствуйте, за недавнее время посмотрел почти все ваши видео по паттернам и мне очень понравилось как вы объясняете. Недавно делал свою игру и пришлось делать что похожее на смесь FSM и EventBus, в итоге наткнулся на паттерн Publish Subscribe Pattern, который очень был похож на то что у меня получилось, в итоге, и кторый почему то не упоминался во многих статьях, планируете ли вы сделать ролик по данному паттерну и правильно ли я понял его суть?
В любом случае, хотел сказать вам спасибо за ваши видео ролики, они максимально наглядные, и помогли мне многое осознать, желаю вам успехов в вашей карьере!☺
Уже лет 8 занимаюсь вебом, паттерны так сяк нужны были. Обычно разработка сводится "наговняй че ни будь по бырому", так что вроде и не сильно востребовано. Была давняя мечта игру написать, решил вот попробовать на годот простенький товер запилить. И тут понял 😅 зачем нужны паттерны. Твои видео пока что самое понятное на что я натыкался. Спасибо за контент.
Это правда самое простое объяснение зенжекта, которое я видел. Мне кажется в паттернах самое главное понять саму концепцию и у вас отлично получается ее подать!
Ты умеешь в addressables ? Если конкретный ассет загрузить через addressables, загрузится только он или весь бандл, в котором он находится? Уже 2 сениора сказали что весь бандл Но мои тесты на голом проекте говорят четко об обратном. Я уже все перепроверил. У меня именно билд, именно 1 бандл. Всё четко
Если честно, так и не понял для чего этот паттерн нужен. На мой дилетантский, ещё даже не стажерский, взгляд, все паттерны решают проблему распухания кода путем всяческих обобщений объектов, чтобы потом через общее (абстрактное) можно было обратится к частному, а также, чтобы написанный класс поместить в черный ящик и больше к нему не прикасаться. Здесь же, мы не обобщили ничего: как и раньше существует 2 копии кода, которые уменьшились на 2 строчки, при этом создали 3 отдельных класса и в сумме добавили около 20-30 строк кода. А ведь при добавлении объектов для создания, классы как распухали, так и будут распухать, и ни в какой черный ящик мы эти классы не поместили. Так ещё плюс к этому, в данном случае, вместо того, чтобы довольно лаконично в одном месте оставить логику кнопки из 5 строк кода, мы взяли и раскидали эту логику по всему проекту. Теперь, если при нажатии на кнопку, что-то пойдет не так, мы не полезем в код кнопки, а будем шарить по всему проекту и искать, в каком же микроклассе воспроизводится баг
Претензия отчасти мне понятна и я даже с ней отчасти согласен. Хочу сказать что всё-таки некое обобщение есть, фабричный метод так же абстрагирует логику создания. Я понимаю претензию по бОльшее количество строк кода, но при росте масштаба проекта куда хуже иметь свитч кейс в 400 строк чем иметь 10 классов в 40 строк. Тут работает принцип SRP, в случае если какая-то сущность неправильно создается, вместо огрромного свитч кейса мы лезем в маленький аккуратный тот самый микрокласс с реализованным внутри фабричным методом.
Хороший вопрос :) Для декораторов можно реализовать методы Unwrap или UnwrapAll. Тут конечно могут возникнуть небольшие трудности с тем чтобы отличить обёрнутый объект от необёрнутого, но всё же по аналогии обёртки можно сделать
Делал на этом паттерне большой проект, на прошлом месте работы. Там по сетевому протоколу приходили команды, а куча объектов в сцене должны были на них реагировать и менять свое состояни. Чтобы не плодить классы с событиями, обработчики регистрировались по имени события, а сами обработчики должны были принимать на входе один объект событие. Внутри события была коллекция параметров в словарике имя/значение. Поддерживался приоритет подписки и возможность рассылки событий глобально и внутри иерархии сцены. Не очень по ООП, но главное что работало и позволяло избегать зависимостей между объектами. Все что объекты в сцене знали, это один статик объект для работы с событиями.
В масштабе и области применения, как мне кажется. DI это паттерн который объясняет как строить архитектуру. Стратегия это паттерн основанный на di, предназначенный для реализации разных способов выполнения одной и той же задачи
Просто лучшее объяснение принципов SOLID. Все четко, ясно и по делу. А главное нет какого-то ощущения недопонимания после просмотра твоих видео, которые я обычно додумывал сам (и обычно додумывал неправильно). Спасибо огромное за проделанную работу! От себя добавил бы, что лучше бы метод Init сделать виртуальным, и переопределить его в наследнике.
Самые лучшие примеры и объяснения. А ты знаешь канал git-amend? Можешь по подобному сценарию что-то снимать, я думаю это будет логичное продолжение твоих видео, но с большим количеством примеров
Рад видеть Вас! Как всегда вовремя) Думаю, применить этот паттерн к модификации пушек в своём проекте (точность 20, а с рукояткой, глушителем становится 30, к примеру)
