Паттерн Factory Method, Фабричный метод, С#, Unity

[@it_is_muchomor]

Спасибо. Редко встречаются люди, которые сперва объясняют - ЗАЧЕМ, а уже потом - КАК. Отдельное спасибо за "где применяется")

[@kirillnotof4861]

Долго не мог понять сути данного паттерна и у вас получилось! Благодарю вас! Голова забурлила от идей, в плане где его можно применить.

[@АлтынбекАнарбеков-й4ф]

"Ямете кудасай" вообще неожиданно было ) И узнал то, что хотел и поржал отдуши, спасибо!

[@MrG12g]

Отличное видео! Редко оставляю комментарии, но на этом этапе развития канала решил поддержать автора таких хороших видео

[@Djegur]

Спасибо большое, очень хорошие и наглядные примеры. Блягодарен вам очень сильно. Качество звука видео и монтажа лучше чем у платных курсов, добрый юмор тоже весьма уместен)

[@play-pot]

Супер, доступно даже для такого пенька как я. Спасибо!

[@VyacheslavTamplier]

Сергей, у тебя лучшие уроки по SOLID и паттернам в контексте геймдева и в частности Unity. Продолжай, пожалуйста! Хороших и грамотных роликов по этой тематике в ру (да, и не только) сегменте очень мало, все смотрят видосы в духе "сделал игру за час" с пустым контентом, а подобных видеороликов, где кратко, четко, понятно и по теме, очень не хватает. Спасибо!

[@darr11]

Спасибо большое, очень понятно

[@НатальяСтаселько-и1б]

Спасибо! Как всегда быстро, чётко, понятно, с юмором и без лишней инфы. Для таких торопыг, как я, - самое то) классный канал! Спасибо автору!!!

[@MarselNz]

Очень крутое объяснение, спасибо за ваш труд

[@jackmusic631]

огромное спасибо за труд!! объяснение с различными примерами, встречающимися проблемами и визуализацией лайк подписка

[@nrouslan]

Ответили на все вопросы! Спасибо большое!!

[@rightmelancholy1170]

Очень здорово, приятно было посмотреть.

[@andreybulatov7097]

Очень полезный тутор спасибо!)

[@Тест_ТВ]

Спасибо! Продолжай! Очень доходчиво и интересно (Пишу на Java)

[@ДаниилПономарев-щ1ш]

Супер просто и понятно🎉

[@АртемЗайцев-к9щ]

Очень хорошее видео, много понял, большое спасибо

[@PinkPanteRus]

Спасибо! Понятно рассказал.

[@ivan-jc1bp]

Огромной спасибо!

[@vladimirkraft4315]

Спасибо большое!

[@Mepp3ku]

Так детально показывает и рассказывает автор, буквально пережевывая все моменты, а я все равно нифига не понял))

[@sergeykazantsev1655]

А что именно непонятно? :D

[@derikfant831]

Жиза, каждый шаг по отдельности понятен, но картина в общем в голове не укладывается. Но думаю это дело практики) надо пересматривать и повторять до тех пор, пока не сложится

[@andreyromanov680]

Лучший

[@ravenempty3562]

Подскажите, что такое "public abstract Mage FactoryMethod();" на 8:30 ? Почему в объявлении метода фигурирует класс Mage? что-то я запутался совсем.

[@ravenempty3562]

ааа, всё, допёр, он должен ВЕРНУТЬ объект класса Mage. Фух, чуть голова не закипела, ну его, это ваше программирование!

[@sergeykazantsev1655]

Ну вот, я даже не успел ничего сказать:D

[@fuuuns]

В правильно поставленном вопросе кроется 70% ответа! Эффект уточки.

[@Oscar-ll6mt]

У меня вопрос, вот согласно DRY мы не должны дублировать код, но в классах IceCreator и FireCreator логика создания одинаковая, не правильнее было бы ее абстрагировать?

[@sergeykazantsev1655]

Если вы про первые 3 строчки на 8:37, да, ResourcesLoad + Instantiate можно абстрагировать, а вот Init не удастся и с AddComponent тоже повозиться придётся.

[@Oscar-ll6mt]

Спасибо за ответ, ваши уроки они мне очень помогли, хотел бы в вашем исполнении послушать про ESC, если вам его использовать?

[@sergeykazantsev1655]

Я пока не чувствую себя достаточно компетентным, буквально неделю назад начал писать проект на DOTS ECS и чувствую себя очень зелёным в этой области) Теоретические знания у меня есть, но нужно больше практики

[@takeTheRedPill189]

Слушай ты просто мог сделать класс Сreator и там требовать мага и всё поскольку ледяной маг и огненый маг являются магами как ты и сказал 8:12 они оба подойдут, ты много продублировал код 6:34

[@sergeykazantsev1655]

А создавать их кто будет, если creator их требует?

[@Serge86210]

Пример из жизни? Я думал, он про программирование расскажет, а не про фэнтези и мечи.

[@sergeykazantsev1655]

Так ты посмотри видео дальше, и про программирование тебе все будет

[@Serge86210]

@@sergeykazantsev1655 да нет, по сути все круто. Просто напомнило про Донни из Большого Лебовски, который произносит ключевые фразы раньше, чем требуется по сценарию)

[@sergeykazantsev1655]

Можешь считать это моим видением. Сперва я рассказываю определение, потом пример из жизни, потом структура, потом код) А фэнтези, мечи и всю эту тему я очень люблю, сам хемой занимаюсь, вот что первое на ум приходит то в и материал залетает)

[@Serge86210]

@@sergeykazantsev1655 ясно, про абстрактную фабрику видео тоже понравилось)

[@zheka9877]

Если честно, так и не понял для чего этот паттерн нужен. На мой дилетантский, ещё даже не стажерский, взгляд, все паттерны решают проблему распухания кода путем всяческих обобщений объектов, чтобы потом через общее (абстрактное) можно было обратится к частному, а также, чтобы написанный класс поместить в черный ящик и больше к нему не прикасаться. Здесь же, мы не обобщили ничего: как и раньше существует 2 копии кода, которые уменьшились на 2 строчки, при этом создали 3 отдельных класса и в сумме добавили около 20-30 строк кода. А ведь при добавлении объектов для создания, классы как распухали, так и будут распухать, и ни в какой черный ящик мы эти классы не поместили. Так ещё плюс к этому, в данном случае, вместо того, чтобы довольно лаконично в одном месте оставить логику кнопки из 5 строк кода, мы взяли и раскидали эту логику по всему проекту. Теперь, если при нажатии на кнопку, что-то пойдет не так, мы не полезем в код кнопки, а будем шарить по всему проекту и искать, в каком же микроклассе воспроизводится баг

[@sergeykazantsev1655]

Претензия отчасти мне понятна и я даже с ней отчасти согласен. Хочу сказать что всё-таки некое обобщение есть, фабричный метод так же абстрагирует логику создания. Я понимаю претензию по бОльшее количество строк кода, но при росте масштаба проекта куда хуже иметь свитч кейс в 400 строк чем иметь 10 классов в 40 строк. Тут работает принцип SRP, в случае если какая-то сущность неправильно создается, вместо огрромного свитч кейса мы лезем в маленький аккуратный тот самый микрокласс с реализованным внутри фабричным методом.

[@danoxztm3250]

А нахрена тут нужен class Creator? Мы с таким же успехом могли просто написать 2 функции createIceMage и createFireMage и в обработчиках нажатия кнопок вызывать их соответственно. ?????

[@sergeykazantsev1655]

В боевых проектах код будет распухать и его будет больше чем 5 строчек. Если вынести логику создания в отдельный класс, принцип Single Responsibility будет лучше соблюдаться и так в целом будет удобнее

[@fuuuns]

Я так понял это банальный ивент рассылки. И это получается ведь фабрика и билдер это по сути декораторы? Или нет? Есть родительский класс ивент. Единый общий Текст, картинка, хтмл, документ, что угодно. От него наследуются фабрикой рассыльщики. Получают данные и каждый начинает слать в свой канал, почта, телеграмм, смс, файрбейз, дебаг логи в клику в кибану. У кажого свои особености там целые династии этих оберток, компоновка данных, подготовка соединения и конект к бд, получение обработка ответов, сверху еще сбор ошибок или поломаных отправок на перезапуск, дальше в слой который поставит недоставленную таску в очередь на новый перезапуск. И так по осп можно абстракцию ивента до бесконечности можно оборачивать в количестве * (количество средств рассылки данных)

[@fuuuns]

Вот она, сила ООП в своей красе...

[@fuuuns]

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

[@sergeykazantsev1655]

Рассылка это про взаимодействие между классами. Здесь же(и в абстрактной фабрике) речь про то где порождать и как порождать объекты

[@fuuuns]

Порождать объекты с заданиями для очереди. Генератор задач для очереди? С которыми работаем потом каждым отдельно в другом месте как с пирожками.