Паттерн Factory Method, Фабричный метод, С#, Unity
Vložit
- čas přidán 15. 07. 2024
- Довольно простой порождающий паттерн, Фабричный метод
Если будут вопросы
мой тг @wargy
моя почта kazancev.s215@gmail.com
Автору на кофе и шаурму
4276 5500 5792 8742 - карта Сбербанка
Тайминги
00:00 Введение
00:28 Порождающие паттерны
00:42 Популярные порождающие паттерны
01:10 Определение
02:37 Пример из жизни
03:36 UML-схема
04:36 Почему Factory Method хорош?
05:39 Конкретный пример: введение
06:15 Конкретный пример: код волшебников
06:45 Конкретный пример: код UI окна
07:59 Конкретный пример: рефакторим код
08:53 Конкретный пример: сравниваем старый и новый код
10:09 Когда использовать Factory Method
10:30 Бонус: немного про Abstract Factory
11:47 Финал - Hry
Спасибо. Редко встречаются люди, которые сперва объясняют - ЗАЧЕМ, а уже потом - КАК. Отдельное спасибо за "где применяется")
Отличное видео! Редко оставляю комментарии, но на этом этапе развития канала решил поддержать автора таких хороших видео
Спасибо! Как всегда быстро, чётко, понятно, с юмором и без лишней инфы. Для таких торопыг, как я, - самое то) классный канал! Спасибо автору!!!
огромное спасибо за труд!! объяснение с различными примерами, встречающимися проблемами и визуализацией
лайк подписка
Долго не мог понять сути данного паттерна и у вас получилось! Благодарю вас! Голова забурлила от идей, в плане где его можно применить.
Очень полезный тутор спасибо!)
Спасибо большое, очень хорошие и наглядные примеры. Блягодарен вам очень сильно. Качество звука видео и монтажа лучше чем у платных курсов, добрый юмор тоже весьма уместен)
Очень крутое объяснение, спасибо за ваш труд
Сергей, у тебя лучшие уроки по SOLID и паттернам в контексте геймдева и в частности Unity. Продолжай, пожалуйста! Хороших и грамотных роликов по этой тематике в ру (да, и не только) сегменте очень мало, все смотрят видосы в духе "сделал игру за час" с пустым контентом, а подобных видеороликов, где кратко, четко, понятно и по теме, очень не хватает. Спасибо!
Очень здорово, приятно было посмотреть.
Ответили на все вопросы! Спасибо большое!!
Очень хорошее видео, много понял, большое спасибо
"Ямете кудасай" вообще неожиданно было ) И узнал то, что хотел и поржал отдуши, спасибо!
Спасибо! Понятно рассказал.
Огромной спасибо!
Супер просто и понятно🎉
Спасибо большое!
Лучший
Так детально показывает и рассказывает автор, буквально пережевывая все моменты, а я все равно нифига не понял))
А что именно непонятно? :D
Жиза, каждый шаг по отдельности понятен, но картина в общем в голове не укладывается. Но думаю это дело практики) надо пересматривать и повторять до тех пор, пока не сложится
Подскажите, что такое "public abstract Mage FactoryMethod();" на 8:30 ? Почему в объявлении метода фигурирует класс Mage? что-то я запутался совсем.
ааа, всё, допёр, он должен ВЕРНУТЬ объект класса Mage. Фух, чуть голова не закипела, ну его, это ваше программирование!
Ну вот, я даже не успел ничего сказать:D
Слушай ты просто мог сделать класс Сreator и там требовать мага и всё поскольку ледяной маг и огненый маг являются магами как ты и сказал 8:12 они оба подойдут, ты много продублировал код 6:34
А создавать их кто будет, если creator их требует?
Пример из жизни? Я думал, он про программирование расскажет, а не про фэнтези и мечи.
Так ты посмотри видео дальше, и про программирование тебе все будет
@@sergeykazantsev1655 да нет, по сути все круто. Просто напомнило про Донни из Большого Лебовски, который произносит ключевые фразы раньше, чем требуется по сценарию)
Можешь считать это моим видением. Сперва я рассказываю определение, потом пример из жизни, потом структура, потом код) А фэнтези, мечи и всю эту тему я очень люблю, сам хемой занимаюсь, вот что первое на ум приходит то в и материал залетает)
@@sergeykazantsev1655 ясно, про абстрактную фабрику видео тоже понравилось)
У меня вопрос, вот согласно DRY мы не должны дублировать код, но в классах IceCreator и FireCreator логика создания одинаковая, не правильнее было бы ее абстрагировать?
Если вы про первые 3 строчки на 8:37, да, ResourcesLoad + Instantiate можно абстрагировать, а вот Init не удастся и с AddComponent тоже повозиться придётся.
Спасибо за ответ, ваши уроки они мне очень помогли, хотел бы в вашем исполнении послушать про ESC, если вам его использовать?
Я пока не чувствую себя достаточно компетентным, буквально неделю назад начал писать проект на DOTS ECS и чувствую себя очень зелёным в этой области) Теоретические знания у меня есть, но нужно больше практики
Если честно, так и не понял для чего этот паттерн нужен.
На мой дилетантский, ещё даже не стажерский, взгляд, все паттерны решают проблему распухания кода путем всяческих обобщений объектов, чтобы потом через общее (абстрактное) можно было обратится к частному, а также, чтобы написанный класс поместить в черный ящик и больше к нему не прикасаться.
Здесь же, мы не обобщили ничего: как и раньше существует 2 копии кода, которые уменьшились на 2 строчки, при этом создали 3 отдельных класса и в сумме добавили около 20-30 строк кода. А ведь при добавлении объектов для создания, классы как распухали, так и будут распухать, и ни в какой черный ящик мы эти классы не поместили.
Так ещё плюс к этому, в данном случае, вместо того, чтобы довольно лаконично в одном месте оставить логику кнопки из 5 строк кода, мы взяли и раскидали эту логику по всему проекту. Теперь, если при нажатии на кнопку, что-то пойдет не так, мы не полезем в код кнопки, а будем шарить по всему проекту и искать, в каком же микроклассе воспроизводится баг
Претензия отчасти мне понятна и я даже с ней отчасти согласен.
Хочу сказать что всё-таки некое обобщение есть, фабричный метод так же абстрагирует логику создания.
Я понимаю претензию по бОльшее количество строк кода, но при росте масштаба проекта куда хуже иметь свитч кейс в 400 строк чем иметь 10 классов в 40 строк. Тут работает принцип SRP, в случае если какая-то сущность неправильно создается, вместо огрромного свитч кейса мы лезем в маленький аккуратный тот самый микрокласс с реализованным внутри фабричным методом.