Спасибо! Больше всего мне понравилось именно в этом видео, что автор сначала на пальцах показал дорогу в ад, а потом - паттерн как решение. Сразу узнаешь свои кейсы, и становится понятно не только для чего нужен паттерн, но и в какой момент его лучше использовать.
Огромное спасибо за полезную и отлично поданную инфу. Часто не хватает примеров из реальной разработки, а тут отличный пример с жителями города. Однозначно лайк и подписка :D
Спасибо за довольно интересный и полезный видос, пока еще трудно полностью осознать принцип работы данного паттерна, но благодаря этому видео,я стал на шаг ближе.
очень полезно, спасибо! пробовал похожую ситуацию разрулить без паттернов, по наитию, и собрал все грабли. После граблей и этого видео сразу понятно зачем оно все нужно и как решить задачу. И, кстати, уяснил как использовать интерфейсы, не повторяя сегменты кода.
Тема интересная, буду ждать продолжения! На мой взгляд, было бы круто интегрировать побольше примеров и продемонстрировать их реализацию более явно (например, напрямую с NPC, которые меняет поведение на наших глазах).
О да. Это топ. Вот такого я давно ждал на русском ютабе. Тебе бы ещё превьюшки получше делать (дизайн в просаде). Теперь ты мой любимчик и уважаемый сэр (:
Вчера решал аналогичную проблему. Сначала налепил несколько классов с аналогичным функционалом. Осознал это. Отнаследовал от базового. Потребовалось добавить особый функционал нескольким типам, переделал в интерфейсы и закопался в переопределения. Кажется, я нашёл следующий этап...
Мне кажется что лучше объединить ITradable, ISpeakable итд под один интерфейс ICitezenAction и создать на основе него коллекцию. Тогда у нас не будут разрастаться методы взаимодействия и методы добавления и удаления и не будут оставаться ненужные NULL поля. А ещё лучше добавить Enum и при взаимодействии с Citizen вызывался бы такой метод PlayerAction(Player player, CitizenActionType actionType) и просто был бы перебор коллекции на совершения нужного действия.
Неудобно будет копаться в этом огромном свиче действий. И, кстати, null невозможен в моем кейсе, так как применяется паттерн nullObject, когда используется мое обьект и он ничего не делает
@@gaitavr1992 я не говорю про свич. Я говорю про цикл перебора по коллекции, по тому же листу или использовать Dictinary. Вызов метода будет из классов как PlayerAction(player, CitizenActionType.Speaking). А в самом методе будет либо цикл, либо обращение к Dictinary. Плюс такое же удобное добавление и удаление в один метод, а не в изменения разных ITradable, ISpeakable
@@gaitavr1992 ну у тебя движение если зависит от player и тебе никто не запрещает в IMoving добавить функционал зависящий не только от взаимодействия с Player. Просто у тебя получается что в citizen много ненужного что другие могут даже не использовать, но они это зачем то наследуют
Во первых, каждый Citizen абстракцирует логику работы с плеером. Кто в вашей системе решает, какой enum действия вызвать? А если произошел некий триггер(квест, кража и т.д.) как вы будете этот экшн менять? Во-вторых, я спросил за IMovable, так как это одно из поведений жителя, но не взаимодействующее с плеером напрямую, не вижу ничего ненужного в Citizen, это довольно гибкая, пусть и высокоуровневая система. Если хотите, присылайте какой-то реальных код, можем на нем обсудить
Видео супер! Только подскажите, пожалуйста, что нужно читать, чтобы понять, о чём в нём рассказывается?) А то вроде уроки и курсы по юнити прохожу, а как что-то глубже понять - на тебе!
У меня вопрос. Если все торговцы в городе имеют не только метод реализации торговли, но и поля такие как деньги, скидка, количество лотов на витрине, то не легче сделать абстрактный класс Tradable вместо интерфеса ITradable ?
Почему нельзя в этой концепции использовать просто более сложную систему наследованиях? Например: класс Citizen, от него наследуется IntractableCitizen, а от него Trader? Тогда все с кем мы можем взаимодействовать потенциально могу торговать.
А ты попробуй. Очень явно понимание паттернов и их необходимость происходит во время, собственно, проектирования. Например, как ты реализуешь немого торговца, шагающего кругами по центральной площади?)
@@gaitavr1992 Просто хочется увидеть как ты что то реализуеш длинное и кривое,которого полно на ютубе,а потом применяется "стратегия" и вместо 200 строчек спагетти получается 100 строчек легко читаемого кода,который легко поддерживать
Спасибо! Больше всего мне понравилось именно в этом видео, что автор сначала на пальцах показал дорогу в ад, а потом - паттерн как решение. Сразу узнаешь свои кейсы, и становится понятно не только для чего нужен паттерн, но и в какой момент его лучше использовать.
Очень приятно видеть паттерны в контексте геймдева и часто возникающих задач. Хороший материал
Большое спасибо за подробный и очень полезный урок!
Огромное спасибо за полезную и отлично поданную инфу. Часто не хватает примеров из реальной разработки, а тут отличный пример с жителями города. Однозначно лайк и подписка :D
Патерн дуже цікавий, надіюсь Ви будете знову ділитися своїм досвідом
Спасибо за довольно интересный и полезный видос, пока еще трудно полностью осознать принцип работы данного паттерна, но благодаря этому видео,я стал на шаг ближе.
Частый признак для применения - свич, в котором применяется разная логика
нихоа не понял, но начинаю смотреть весь канал, лайк
По сути здесь затронулся паттерн проектирования Мост, который и образуется благодаря паттернам Стратегия и Шаблонный метод. Спасибо за урок X_X
Большое спасибо за отличный урок!
супер, уже юзал такое, но не знал что это на самом деле был паттерн Стратегия, спасибо за поясния
очень полезно, спасибо! пробовал похожую ситуацию разрулить без паттернов, по наитию, и собрал все грабли. После граблей и этого видео сразу понятно зачем оно все нужно и как решить задачу. И, кстати, уяснил как использовать интерфейсы, не повторяя сегменты кода.
Дуже крутий приклад, дякую
Тема интересная, буду ждать продолжения!
На мой взгляд, было бы круто интегрировать побольше примеров и продемонстрировать их реализацию более явно (например, напрямую с NPC, которые меняет поведение на наших глазах).
Учту, спасибо!
+1
О да. Это топ. Вот такого я давно ждал на русском ютабе. Тебе бы ещё превьюшки получше делать (дизайн в просаде).
Теперь ты мой любимчик и уважаемый сэр (:
Дизайн конечно не мой конек) Но мне нравится иногда отвлечься от программирования вечерком и повозится в фотошопе)
Невыносимо полезное видео, не ожидал, спаcибо
комментарий в поддержку! спасибо за урок!
Номенклатура паттернов, хорошо. Возьмем.
Спасибо! Лучшее видео по этому патерну
Читал и (частично) использовал это в энтерпрайзе, но когда описано применительно к игре это как-то усваивается и складывается лучше.
Тот момент когда ты понимаешь что у тебя в коде не только фабрика, а фаприка+стратегия применена :)
Очень интересная тема! Хотелось бы знать какие еще паттерны хорошо/удобно применять в ходе разработки на Unity.
Следующее видео о декораторе будет)
Мне все интересно (
И было бы классно ещё уроки от 0 до создания первой игры змейки.
С нуля это не моя аудитория
супер! спасибо за урок!
ОммммЮ патерны!! канонично!!
Обьяснение похожее как в книге Head First Design Patterns
Рассказываешь хорошо
Кстати, в чем разница между стратегией и стейт машиной?
Очень круто, немного видел попытки объяснить этот паттерн, понятным мне показался пока только твой) Скажи пожалуйста, ты часом не из Украины?
Классный выпуск 👍
Вчера решал аналогичную проблему.
Сначала налепил несколько классов с аналогичным функционалом. Осознал это. Отнаследовал от базового. Потребовалось добавить особый функционал нескольким типам, переделал в интерфейсы и закопался в переопределения.
Кажется, я нашёл следующий этап...
Макс, спасибо!
Хороший и полезный видос, можешь снять продолжение?
Есть другое паттерны на канале
Было бы не плохо на реальном примере показать.
Мне кажется что лучше объединить ITradable, ISpeakable итд под один интерфейс ICitezenAction и создать на основе него коллекцию. Тогда у нас не будут разрастаться методы взаимодействия и методы добавления и удаления и не будут оставаться ненужные NULL поля. А ещё лучше добавить Enum и при взаимодействии с Citizen вызывался бы такой метод PlayerAction(Player player, CitizenActionType actionType) и просто был бы перебор коллекции на совершения нужного действия.
Неудобно будет копаться в этом огромном свиче действий. И, кстати, null невозможен в моем кейсе, так как применяется паттерн nullObject, когда используется мое обьект и он ничего не делает
@@gaitavr1992 я не говорю про свич. Я говорю про цикл перебора по коллекции, по тому же листу или использовать Dictinary. Вызов метода будет из классов как PlayerAction(player, CitizenActionType.Speaking). А в самом методе будет либо цикл, либо обращение к Dictinary. Плюс такое же удобное добавление и удаление в один метод, а не в изменения разных ITradable, ISpeakable
А с движением что? Его нельзя использовать как действие над citizen, ему подобных поведений будет еще куча
@@gaitavr1992 ну у тебя движение если зависит от player и тебе никто не запрещает в IMoving добавить функционал зависящий не только от взаимодействия с Player.
Просто у тебя получается что в citizen много ненужного что другие могут даже не использовать, но они это зачем то наследуют
Во первых, каждый Citizen абстракцирует логику работы с плеером. Кто в вашей системе решает, какой enum действия вызвать? А если произошел некий триггер(квест, кража и т.д.) как вы будете этот экшн менять?
Во-вторых, я спросил за IMovable, так как это одно из поведений жителя, но не взаимодействующее с плеером напрямую, не вижу ничего ненужного в Citizen, это довольно гибкая, пусть и высокоуровневая система.
Если хотите, присылайте какой-то реальных код, можем на нем обсудить
Видео супер! Только подскажите, пожалуйста, что нужно читать, чтобы понять, о чём в нём рассказывается?) А то вроде уроки и курсы по юнити прохожу, а как что-то глубже понять - на тебе!
Если вы еще сами не работаете пару лет(не важно фриланс или в команде) то сложновато будет понять проблему)
в гугле "design patterns книга"
У меня вопрос.
Если все торговцы в городе имеют не только метод реализации торговли, но и поля такие как деньги, скидка, количество лотов на витрине, то не легче сделать абстрактный класс Tradable вместо интерфеса ITradable ?
Торговля, как поведение вынесено под интерфейс, но никто не мешает добавить еще и абстрактный класс, если есть общее состояние.
@@gaitavr1992 понял, спасибо
Максим, учти в будущем, что concrete -- это бетон(см 4:32), а конкретный -- exact :)
concrete это и бетон и чтото конкретное
Почему нельзя в этой концепции использовать просто более сложную систему наследованиях?
Например: класс Citizen, от него наследуется IntractableCitizen, а от него Trader?
Тогда все с кем мы можем взаимодействовать потенциально могу торговать.
Получится перекрестная система, которую сложно поддерживать и легко сломать
А ты попробуй. Очень явно понимание паттернов и их необходимость происходит во время, собственно, проектирования. Например, как ты реализуешь немого торговца, шагающего кругами по центральной площади?)
Diyozen Отнаследую от Trader класс SilentTrader в котором пропишу как он ходит, а метод Speak будет пустым?
@@TheTorston ну вы же понимаете, что это ужасная структура?
Максим Крюков - разработка на unity а чем? Она же решает поставленную задачу
Кстати тебе нужно развиваться в соц сетях,дискорд сервер сделать,группу вк и т.д
Группа вк есть, но я особо в ней смысла не вижу. А так после 1к хотел следующий этап вводить. Но пока идет туговато)
Общее что то где то там промелькнуло,но без реальных примеров - не сильно понятно как это применить в проекте.
Методы без наполнения уже не реальный пример? Обычно на всевдокоде показывают, а там еще меньше реального
@@gaitavr1992 Просто хочется увидеть как ты что то реализуеш длинное и кривое,которого полно на ютубе,а потом применяется "стратегия" и вместо 200 строчек спагетти получается 100 строчек легко читаемого кода,который легко поддерживать
Принял, хорошо
слишком сложно, лучше сделаь практические уроки с реальным примером и его рефакторингом. На практике показать почему конкретный подход неудобен.
3:40
создаются объекты, но варнинг же будет что он монобеха наследуемся, это нормально?
Спасибо, очень полезный урок!