C# Factory Method Фабричный Метод | Design Patterns

[@codaza-channel]

Удобная навигация по видео :) 0:00 - Начало 0:48 - Factory Method это порождающий паттерн 1:25 - Концепция Factory Method 6:52 - Недостатки Factory Method 8:07 - Анатомия Factory Method 9:59 - Live example 10:52 - Пример: Создаём проект в Visual Studio 2022 (.NET6) 11:18 - Пример: Создаём абонементы 16:47 - Пример: Создаём фабрики 22:24 - Пример: Используем фабрики в клиентском коде 32:33 - Завершение

[@tarlanismailov5228]

На мой взгляд было бы неплохо, если бы вначале урока была определена проблематика: то есть код без применения какого-либо паттерна, а уже потом можно было бы увидеть пользу от использования паттерна. Но все равно уроки очень полезные. Спасибо!

[@codaza-channel]

Да, это очень хорошая идея. Я подумаю над этим. Спасибо!

[@voffkaboo7183]

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

[@codaza-channel]

Всегда приятно читать такие комментарии, они очень мотивируют. Я рад, что видео оказываются полезными и нравятся. Спасибо за комментарии, они очень помогают каналу 🙂👍

[@aleksalex1479]

Каждое новое видео на этом канале не только источник знаний, их ещё и приятно смотреть и слушать. Спасибо!

[@codaza-channel]

Благодарю за высокую оценку. Надеюсь и дальше радовать познавательным контентом. Впереди много интересного!

[@BrownAleks]

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

[@marksreider7645]

Спасибо за ваш труд, ваш канал источник знаний C#

[@codaza-channel]

Я очень рад, что канал оказался для вас хорошим источником знаний по C#. Вам большое спасибо за комментарии под роликами и поддержку, это очень сильно помогает каналу. Впереди много интересного 🙂👍

[@ТуралИскендерли]

Очень четко! Если кто то у меня попросит отличный пример имплементации этого паттерна я просто скину это ссылку на это видео.

[@КритерийПарето]

Просто невероятно круто. Много моушен графики, дизайна самого ролика. Музыка, оформление, цвета, выверенный голос. Здесь всё идеально. Я молчу про содержание - это и так понятно любому, кто сюда зашел. Даже не будем останавливаться. Так паттерн никто не разбирал. Тема ультра не для всех - это не учить, что такое string и набирать миллионы просмотров. Здесь делается колоссальная работа для людей кто в теме, а таких мало. Большое Вам человеческое спасибо за Ваши труды.

[@ArconWell]

Я всё ещё жду разбор остальных паттернов проектирования 😁 Вам удаётся максимально простым языком говорить о сложных вещах. Такое мало кому под силу

[@postman2084]

Присоединяюсь, очень жаль что нового ничего нет (

[@phat80]

Как всегда отлично!

[@_MrMaser_]

Спасибо большое codaza, долгое время не мог понять как этот паттерн работает, спасибо большое!

[@codaza-channel]

Пожалуйста! 🙂 Спасибо, что смотрите и оставляете комментарии. Очень рад, что понимание работы паттерна пришло после просмотра этого ролика 💙

[@vladbush8718]

Мужик,спасибо тебе большое за то что ты делаешь от всего нашего сообщества! Я со знакомыми программистами разбираем разные темы по программироварию и частенько смотрим разные источники(сайты с документациями на разных языках,по видео,по сайтам,на русском лучший metanit ,и твоя падача лучше чем у всех на русском ютубе. Я уверен,что сложно так качествено делать,спасибо тебе😁)

[@codaza-channel]

💙

[@777homosapien]

Надо поменять "И выведем информацию клиенту" на "И схватим nullreference ". А описание отличное! Спасибо!

[@viktorkobylyanskyy102]

Продолжайте пжлст не остонавливайтесь, для новичков очень хорошо что есть хоть какие то примеры, потому что часто неясно вообще зачем все ети штуки нужны. Учишь что то, типо лямбда выражений, паттернов, асинхронного программирования и тд, а на фига ето нужно в итоге не понятно вообще.

[@RageBerry_]

Спасибо за труд, видос зашёл на "ура", буду ждать новых роликов и выделять время и силы на те, что уже есть

[@ВасяДомин-ъ8п]

Спасибо чувак, не думал что можно учиться не насилуя свои мозги. Очень приятно подаешь

[@yanutsh]

Шикарное описание паттерна. От Концепции до примера Реализации!!! Наконец-то стало все понятно, хоть я пишу не на С а на PHP. Большое спасибо. Подписался. Буду искать объяснений других шаблонов.

[@NoL1nker]

По праву один из лучших каналов по программированию в целом и C# в частности. Большинство ориентированы на новичков, что на самом деле не всегда хорошо. Огромное спасибо, за одно видео почерпнул массу полезной и нужной информации!

[@qnet1080]

То что нужно , идеально . Спасибо . Вы лучшие!

[@РоманИванов-п1д]

Спасибо большое, это лучшее объяснение, которое я видел. 👍👍👍

[@interjacksoninter6310]

Спасибо за выпуск, всё понятно и доступно!!! Ждём продолжения про абстрактную фабрику, к примеру)))

[@6trica1a3]

Реально круто делаешь Паттерны с тобой реально понятны💪

[@Николай-ш8ж4у]

Спасибо за видос. По мимо фабрики, еще и за switch. Ото по привычке case..break использую )

[@nobodynemo9556]

Понимание этого патерна пришло именно из этого ролика, спасибо :)

[@ANTONY-vk3pu]

Продолжай пожалуйста, очень понравилось, отличный канал!!!

[@vladisslavss]

Отличное объяснение! спасибо за видео! Лукас и коммент в поддержку автора канала!

[@petrodyak]

Спасибо за класное обьяснение этого патерна. Очень просто и в то же время наглядно на примере (то что надо для програмvиста- спортсмена :) )

[@codaza-channel]

Спорт только приветствуется 👍 Рад, что видео оказалось полезным!

[@youchinafriend]

Шикос, спасибо большое 👍🏻💥

[@РоманЕжов-щ4й]

Не знаю, уравновешенный ли человек это придумывал, но без навыка "МАНИЯ", такое придумывать не охото) 4:36. Спасибо, ты супер отлично объясняешь.

[@ibragimProtopopov]

В данном примере мы создаем фабрику, а в ней конкретный класс, почему мы не можем создать сразу конкретный класс? или фабрики еще будут расширяться и в самой фабрике будет еще свич в зависимости от параметра?

[@ккк-ь4о]

очень понятное и интересное видео, спасибо!

[@TheKovalAndrey]

Спасибо, не такой уж и сложный паттерн. Понял ;)

[@ЖекаКабанов-э6ь]

Комент для продвижения. Автор красавчик.

[@Дмитрийсекрет-н7о]

Спасибо. Очень сегодня пригодилось.

[@codaza-channel]

Пожалуйста :)

[@aarongrimes9276]

Спасибо за видео, как всегда отлично

[@justraccoon3047]

Ля, ну очень крутое и понятное видео. Сложная тема, но у тебя очень понятное объяснение. Очень бы хотелось увидеть видео по остальным паттернам.

[@mathew9794]

Просто отличное пояснение. Большое человеческое.

[@МимоПроходил-о8г]

Хорошее видео. Спасибо.

[@habel2446]

Один из лучших каналов

[@WestPicturesStudio]

Я нашел закодированное послание на 25:20! ты на самом деле GPT! (если тебя держат в заложниках, ты знаешь что делать;)

[@БерёзоваяКора-ц4ч]

Спасибо, всё понятно

[@dazl974]

Также, я думаю, было бы интересно узнать как и зачем использовать асинхронные методы (async await)

[@toks1396]

Больше года прошло с вопроса, не знаю актуален ли ответ, но все равно напишу. Асинхронные методы нужны для того, чтобы не загружать поток работой ожидания ответа от IO, т.е. когда фактически поток не работает, но и не отпускает выделенный ему планировщиком квант времени. Синхронное ожидание IO операций плохо, поскольку в пустую загружает систему. Лично мне всегда было проще понимать на примерах и аналогиях, поэтому предложу такой пример. Ты живешь в квартире с тремя друзьями (снимаете квартиру на 4х). Вас в квартире четверо - представь, что каждый из вас - это "поток". Квартира - "процесс" (это не совсем так, но чисто для простоты). Т.е. в одной квартире есть 4 потока. Каждый из вас может делать какую-то работу (Task), а может ничего не делать, отдыхать. Вы проголодались и решили заказать пиццу. Т.е. появилась задача (получить пиццу чтобы можно было ее съесть). Задача состоит из нескольких частей: заказать пиццу (реальная работа для одного из вас), подождать курьера (работает курьер, вы в это время не задействованы), встретить курьера и принести пиццу на стол (реальная работа для кого-то из вас). Как будет выглядеть синхронный вариант: один из вас позвонил в пиццерию, сделал заказ, и сел ожидать курьера. Пока он ждет курьера, он вроде ничего не делает, но при этом отказыватся делать что-то другое (накрывать на стол, помогать вешать полку и т.д.). Т.е. просто сидит, уставился в стенку и ждет звонка. У вас в квартире в этот момент, с некой долей упрощения, стало всего 3 свободных потока, т.е. вы одновременно можете делать 3 задачи. И если у вас большой список задач (даже мелких), вам на 3х их разгребать стало сложнее, а этот мерзавец сидит и пялится в стену! Асинхронный вариант: один из вас позвонил в пиццерию, сделал заказ, но не сел ожидать курьера, а продолжает делать какие-то дела по дому. В тот момент, когда поступит звонок от курьера, он (либо любой из вас, зависит от контекста синхронизации) - выйдет встречать курьера и принесет пиццу. Получается, что на момент ожидания курьера, вы не лишились одной рабочей силы и так и продолжали делать одновременно 4 задачи. Тот, кто заказывал пиццу, смог сделать много мелких задач пока не поступил звонок от курьера. Модель очень упрощенная, но должна более-менее отражать суть асинхронности. Все это нужно чтобы система не деградировала, ожидая ответа от внешних устройств (или сервисов) - всякие запросы к базам данных, api, ожидание сообщения в шине данных и тому подобное.

[@dazl974]

Было бы неплохо, если бы ты объяснил конфигурацию через IConfiguration.

[@ДмитрийУрюпин-ч6у]

Узнал по голосу) брал курс на юдеми) огромный респект! Наконец стало понятно, что эта фабрика довольно прозаичная штука)

[@codaza-channel]

Здорово, что видео оказалось полезным. Вероятно Вы обознались, так как я не выкладывал курсов на Udemy. А что за курс? Интересно послушать голос, который Вам показался схожим с моим 🙂

[@ДмитрийУрюпин-ч6у]

@@codaza-channel на udemy курс Программирование на c# от новичка до специалиста. Илья Фофанов. Очень похожие голоса

[@codaza-channel]

Спасибо. Нет, не я :) У Ильи есть свой канал на KZbin.

[@ДмитрийУрюпин-ч6у]

@@codaza-channel так, или иначе, Ваша подача материала просто прекрасна)

[@morozovua]

Может мой коммент покажется душным, но задачу с абониментами надо было бы решать паттерном декторатор и все эти вещи типо бассейна и т.д. делать отдельными сущностями которыми можно было бы расширять сущность Gym

[@loam]

А мне сразу на ум для приведенного примера шаблон декоратор пришел...

[@ЭрнестБугурт]

20:50 - ну а где звук?

[@vasikkot4083]

Незаслуженно малое количество подписчиков

[@_MrKekovich]

Какой же офигенный контент. Мне очень нравится подача и огромная ценность информации. Спасибо!

[@_MrKekovich]

Забыл ещё то, что это не только к C# принимается, но и ко всем языкам, которые поддерживают современное ООП

[@НикитаЗубенко-о1о]

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

[@codaza-channel]

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

[@tarlanismailov5228]

9:29: тут, видимо, опечатка, так как, насколько я понял, вовращаемый тип в factoryMethod в классе AbstracFactory должен быть IProduct?

[@codaza-channel]

Да, разумеется. Благодарю Вас за внимательность.

[@AlexanderXarawg]

У меня было впечатление, что фабрика несколько сложнее. А тут получается, что логика, которая обычно описывается в сервисе или коре, выносится и разбивается по различным реализациям фабрики.

[@mihaylo47]

смотреть можно только на 1,25 скорости. На двадцатой минуте пропадает звук на несколько минут. Окей, я понял как организовать фабрику, но так и не понял, зачем, с тем же успехом я мог создать в методе GetFactory сами классы GM, GPPM, PTM без фабрик, напрямую. Зачем столько работы, с какой целью?

[@KislyEmb]

В видосах 90% воды. Более того в данном примере фаблика выпускает только один тип обьектов.. если бы фабрика выпускала колеса, то на каждый тип протектора и диаметра и тд пришлось бы строить еще одну фабрику..

[@serb1146]

Что мешает в switch выражение поместить создание сразу необходимого membership? В два раза меньше кода, в два раза меньше классов. С таким же успехом можно еще нагородить генераторы фабрик для создания продуктов, а потом генераторы генераторов... Формально построение паттерна вы объяснили, но ваш пример использования может ввести в заблуждение новичка, что в будущем вызовет трудности применения.

[@ravenempty3562]

В видео же специально несколько раз повторялось "Тут может быть сложная логика, которая будет отличаться". Если в обучающем ролике сразу городить эти различия, то новичку как раз будет сложно в этом разобраться и в голове будет каша. Тут главное донести саму суть работы паттерна

[@mykhailoskachkov5946]

Видео классное, но сам пример имхо неудачный. В данной ситуации все то же самое можно было бы сделать без фабрик вообще с единым оператором switch. Поэтому как по мне, то суть паттерна как раз не раскрыта. Лучшим примером был бы акцент на каком-то алгоритме, сделанном в общем виде, где автоматом создаются объекты и акценте на том что код этого алгоритма не меняется никогда и вот для того чтобы он не менялся нам на определенном этапе нужны эти фабрики . ну и да, конструкторы у классов для наглядности лучше было бы сделать разными, чтобы собственно и показать что где надо, вызывается кастомный код (внутри фабрик), а где надо, вызывается код в общем виде (внутри алгоритма). Мне кажется эти акценты в видео если и есть, то сделаны неочевидными.

[@Ar6yZuK]

Жаль не могу два лайка поставить

[@IIIA_KO]

Спасибо за урок. Я изучаю программирование уже второй год и вот пришел к изучению паттернов. Неясным для меня осталось только одно: зачем создавать абстрактную фабрику, когда можно создать конкретные для каждого типа? Все равно ведь работа будет выполнена та же самая

[@codaza-channel]

В базовом классе (в нашем случае MembershipFactory) мы можем определить общую логику (если она необходима) для конкретных фабрик. Кроме того, базовый класс необходим для унификации работы с создаваемыми фабриками, так как вам может потребоваться отложенное (lazy) создание объекта.

[@IIIA_KO]

@@codaza-channel Понял, спасибо большое

[@ig6187]

Спасибо за канал. Фоновая музыка имхо немного громкая

[@codaza-channel]

Спасибо за комментарий и обратную связь. Если не трудно, можете скинуть парочку ссылок на ролики с других каналов, где фоновая музыка вам кажется комфортной? Постараюсь поработать над этим 🙂

[@ig6187]

@@codaza-channel Ответил отдельно.

[@codaza-channel]

Благодарю за хорошие чаевые ☕️ Поработаю над уровнем громкости 🙂

[@ivnwngspn]

14:18 Почему мы не можем просто создать для имени свойство со стандартным геттером и приватным сеттером, а для цены стандартный геттер и инит сеттер? Зачем нам вместо этого какие-то уродские поля с подчеркиваниями? В случае со стандартными свойствами этот функционал можно было бы ещё и засунуть в интерфейс IMembership, определить там стандартную реализацию и перегрузить где надо, а не копировать один код во всех абонементах. Почему делается не так? Не понимаю этот момент.

[@codaza-channel]

Первое, что хочу отметить, “уродские поля с подчеркиваниями” - это общепринятая нотация в C# для private данных 🙂 Касательно ваших предложений: пример очень небольшой, поэтому тут возможны практически любые вариации без потери смысла, в том числе, предложенные вами.

[@gleb_rr]

Спасибо большое!!! Остался один небольшой вопрос: где должна находиться папка factories, которая создает объекты Domain, если приложение MVVM? (Domain, Infrastructure, Bootstrapper, ViewModel)?

[@СергейСергеев-л7ш6и]

В примере с фитнес клубом, зачем нам нужны прослойки классы-фабрики, если логику создания экземпляров IMemberahip можно поместить внутрь классов наследников? Чем больше изучаю фабричные методы, тем больше не понимаю их реальную пользу. Дополнительные поражения для усложнения кода.

[@nytakoe6156]

Полностью согласен, начал изучать и не понимаю, зачем прослойка в виде классов-фабрик... Можно просто без них обойтись, паттерн от этого никак не изменится. А в плане пользы, есть хороший пример с логгером: kzbin.info/www/bejne/rofaiKibdrKel8ksi=-3DvgND3QG0x2X5G

[@sergeymigel4680]

все понял. так банально, что аж разочарован немного)

[@danyka6974]

А какое преимущество у этого паттерна по сравнению с например определением какого нибудь статического класса с методом IMembership GetMembership(Type) где Type - enum. Сам метод возвращает нужный нам объект, внутри тела метода все тот же switch case который в зависимости от значения Type вызывает один из приватных методов внутри класса который и конструирует объект. Т.е. тут вообще нет никаких фабрик, для расширения функционала все что надо это добавить новый метод и все.

[@codaza-channel]

Спасибо за отличный вопрос. Вы описали как раз тот случай, из-за практики применения которого, пришли к необходимости создания паттерна Factory Method. Если сделать статический класс таким, как вы его описали, то мы получим так называемый "God Object". Приведу определение из Wikipedia (если не слышали про это): Боже́ственный объе́кт (англ. God object) - антипаттерн объектно-ориентированного программирования, описывающий объект, который хранит в себе «слишком много» или делает «слишком много». Таким образом, мы сразу же создадим себе множество проблем, главная из которых - нарушение принципа открытости/закрытости. Если нам потребуется изменить принцип создания какого-нибудь объекта, мы всегда будем делать это в этом большом статическом классе. Кроме того, просто представьте что будет с этим классом если у вас будут десятки сложно-конструируемых объектов, весь код превратится в нескончаемую лапшу трудную для анализа и понятную только её создателю. Выделяя логику создания в отдельные фабрики, мы инкапсулируем её в них, тем самым делая код читаемым и пригодным к проведению unit-тестирования. И конечно же сам фабричный метод - возможность централизованного выделения базовой логики для создания объектов.

[@neu2229]

@@codaza-channel а почему код который написали вы не нарушет принцип открытости-закрытости? Вы же пишете Switch-Case который так или иначе будете раширять при добавлении нового типа абонимента. Это уже ключевое нарушение этого принципа. Разница лишь в том, что в фабриках это более структурированый код. Но это никак не убирает нарушение open-closed принципа. Или что тут я не так понимаю?

[@codaza-channel]

@@neu2229 Вы правы в том, что в части switch-case принцип открытости/закрытости нарушается. В данном случае это считается нормальным, так как это часть клиентского кода, где нет логики создания абонементов, так как она располагается в соответствующих фабриках. Однако, даже в этом случае, при необходимости, мы можем этого избежать используя рефлексию.

[@MrKingofTiger]

Интересная комбинация. Горит с того, что не пользуешься подсказками, что вместо Console.WL пишешь полные названия и вообще игнорируешь любые подсказки, но с другой стороны приятная музыка, голос и отличная подача материала. За второе однозначно лайк. Было полезно

[@codaza-channel]

Благодарю за обратную связь. В комментариях под другим видео уже задавали этот вопрос, я продублирую мой ответ: Причина по которой я стараюсь не пользоваться быстрыми действиями состоит в том, чтобы зритель видел развитие мысли в процессе написания кода без резких “скачков”, которые эти действия создают. На канале люди с разным уровнем подготовки и начинающих разработчиков такие “фокусы” также могут смущать.

[@codemystery]

Видео информативное и крутое, спасибо! Почему не пользуетесь предложенными студией подсказками, по большей части, то что она предлагает, Вы и пишите?

[@codaza-channel]

Благодарю за обратную связь. В комментариях под другим видео уже задавали этот вопрос, я продублирую мой ответ: Причина по которой я стараюсь не пользоваться быстрыми действиями состоит в том, чтобы зритель видел развитие мысли в процессе написания кода без резких “скачков”, которые эти действия создают. На канале люди с разным уровнем подготовки и начинающих разработчиков такие “фокусы” также могут смущать.

[@ИгорьМакушин-г3ш]

Считаю, что все эти паттерны - баловство. В реальной жизни не до "фабрик". Надо сделать быстро, дешево, и так как хочет заказчик, а не программист.

[@TedRed]

И это грустно. У нас закуток системы таким говнокодом написан, что пока разберешь как оно работает - пройдет половина дня. Если это хоть сколько-нибудь поддерживаемый проект в дальнейшем - писать не по паттерну себе дороже выйдет.

[@Bushido_Cat]

Патерн выглядит очень громоздким и нагруженным, только не понятно ради чего это все стоит затевать, если тот же SwitchCase может порождать любой вариант - абонемент экземпляр класса по нажатию кнопки, без этой всей этой химеры 😪

[@sportshomeworkout3834]

DotNet_6 рулит

[@clutchmeisteryo9831]

Хорошо, объясните что мне мешает создать метод, который инкапсулирует в себе тот же switch case и в зависимости от ввода создаёт мне нужный класс? Чем этот вариант хуже реализации этого паттерна?

[@codaza-channel]

Пример сильно упрощен, чтобы дать понимание структуры и взаимодействия классов. В реальных задачах, создание абонемента может быть весьма сложным процессом и подобное упрощение приведет к перегруженности клиентского кода, которому нужно знать все детали реализации создания всех абонементов. Таким упрощением вы нарушаете принцип единственной ответственности (Single Responsibility Principle), описываемый в SOLID.

[@tupoy_ytub_uberi_psevdonim]

С 19 по 22 минуту резко пропадает весь звук

[@mattaku9430]

Не должны ли субклассы фабрики решать какой метод создавать? Метод придётся менять, если мы добавляем ещё один класс и фабрику

[@EvgeniyYatsenko]

в российских реалиях собака нужна чтобы человек не тырил оборудование на чермет))

[@ГрамовичОлег]

20:51 звук пропал 22:30 вернулся

[@FixedA]

Осталась ли необходимость в данном паттерне когда есть внедрение зависимостей?

[@qwww..8628]

Добрый день. Можете пояснить почему вы использовали интерфейс, а не абстрактный класс для создания абстракции "продукта"?

[@codaza-channel]

Добрый день. Интерфейс используется ввиду отсутствия необходимости общей логики работы "продуктов". Если бы в "продукте" нужно было сделать расчёт базовой стоимости, то мы могли бы прибегнуть к использованию абстрактного класса.

[@СергейТарамалы-ш8г]

Автору на будущее, в visual studio можно копировать файлы классов, а не каждый раз создавать новые, писать им название, и копипастить код. Без хейта, наоборот респект за открытые знания.

[@dzianisshcharbakou145]

Спасибо за видео, но все же есть вопрос к методу GetFactory(string membershipType) на клиенте, разве он не нарушает принцип открытости закрытости? или здесь имеется ввиду, что этот метод должен быть из стороннего источника, а мы его просто используем?

[@codaza-channel]

Да, нарушает. Но в этом конкретном месте это некритично, так как это точка вход в программу, где мы даём пользователю выбор абонемента, который нужно создать. Здесь важно понимать, что нельзя написать код, который на 100% будет соответствовать принципам SOLID. Всегда будут существовать "узловые точки", где принципы должны быть нарушены по тем или иным причинам. Интерфейсная логика является одной из таких "узловых точек".

[@saldy723]

Правильно ли понимаю, что абстрактный метод, это реализация той же стратегии, но с необходимостью делигацией создания объектов?

[@codaza-channel]

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

[@TheCry412]

Спасибо тебе за хорошее объяснение. Слушай, можешь помочь, как обработать вариант, если пользователь введет неверную букву(не g,p,t) ну или вообще ничего не введет. Сколько я пытаюсь у меня не получается.

[@codaza-channel]

Попробуйте подписаться на событие изменения текста в поле ввода и использовать регулярное выражение для фильтрации вводимых символов.

[@rinatsadyev4649]

Не понял зачем нужна посредник фабрика. Можно же создавать абонементы так же через switch без фабрики.

[@uprekayshiy_goose]

Думаю в фабричном методе нужно добовлять ещё кучу разной логики

[@king_fox_3106]

Чувак, очень круто объясняешь, но я всетаки так и не понял, зачем создавать кучу одинаковых классов выполняющих одно и то же действия, только с разными реализациями... Сейчас пытаюсь адаптировать код для своей игры на Юнити (Создание вещей с разными типами сущности, Предмет, животное, растение) и что то не клеится у меня с тем, что ты показал в примере. Я реализую абстрактный класс Фабрики и интерфейса в Фабрике сущьности, это уже выходит за рамку паттерна?

[@codaza-channel]

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

[@redice8928]

Честно, не понял в чем суть фабрики, почему бы сразу не создавать абонемент? Вместо этого мы сначала создаем фабрику определенного типа, а потом через нее создаем абонемент соответствующего типа

[@ermekbakyt5507]

Eto u vas Abstract Factory pattern ili Fatcory Method pattern?

[@codaza-channel]

Factory Method

[@Tleu13]

@@codaza-channel странно я до конца не стал смотреть но даже на картинке в начале у вас у каждого абонемента по фабрике и над ними ещё одна фабрика. Возможно все же вы сделали пример абстрактной фабрики?)

[@ВладКозлов-щ8ц]

Вообще не очень понял целесообразность нескольких фабрик для каждого абонемента. Дублирование кода.

[@codaza-channel]

Пример сильно упрощен, чтобы дать понимание структуры и взаимодействия классов. В реальных задачах, создание абонемента может быть весьма сложным процессом и существенно отличаться для разных абонементов.

[@edwardfreedom]

что за плагин с подсказками

[@vitaliySobakinson]

ГДЕ НОВЫЕ ВИДЕО??

[@vitaliySobakinson]

Дед, получишь по жопе! Делай видео!

[@vladbush8718]

17:30 Почему GetMemberShip, а не GetIMemberShip кто-нибудь знает?

[@codaza-channel]

В C# принято именовать метод по объекту, который этот метод возвращает. GymMembership, PersonalTrainingMembership всё это Membership (абонемент). Да, они реализуют интерфейс IMembership, но добавление буквы I в название метода будет избыточным.

[@morozovua]

Плохой пример реализации. С таким же успехом можно было просто создать абонементы без избыточности

[@DF-ov1zm]

Паттерны, хуяттерны, бизнесс шмизнесс... чел, все, что тебе нужно было ответить на вопрос "нахера козе баян" в отношении фабрик - это: вам придётся их использовать, когда 1) в конструкторе дофига очень медленного говна, да ещё и костыльно синхронно асинхронного и вам больно смотреть на себя в зеркало от того говно кода, который вы накидали в конструкторы, прям спать не можете как и 2) когда вам нужно, что бы клиенту было фиолетово до того какие там реализации интерфейсов он запрашивает

[@ahega0]

к сожалению, код в этом ролике не правильный, автор реализовал не фабричный метод, а абстрактную фабрику. те кто будет мне доказывать обратное - смотрите псевдокоды и читайте термин данного паттерна

[@constantin3280]

Нет, здесь реализован именно фабричный метод, но конкретно здесь лучше было бы реализовать абстрактную фабрику. В коде MembershipFactory объявляет фабричный метод GetMembership. Метод возвращает объект типа IMembership. Класс GymMembershipFactory переопределяет фабричный метод для возврата экземпляра GymMembership. IMembership интерфейс, который объявляет поведение продуктов, а GymMembership конкретный продукт, который реализует этот интерфейс.

[@grizzly805]

вообще ничего не понятно🙃

[@kitemanrus]

Примитивный пример. Если выкинуть всё эти фабрики и в методе getFactory в свиче создавать непосредственно экземпляры классов абонементов получим тот же результат.

[@codaza-channel]

Пример взят для первого знакомства с паттерном Factory Method. Мне показалось, что рассмотрение более сложных процессов может отвести от понимания сути шаблона. Если Вам встречались более удачные примеры, буду рад если оставите ссылки. Мне будет интересно посмотреть на примеры, раскрывающие суть паттерна лучше. Так же это будет полезно для гостей канала, которые заглянули в комментарии 🙂

[@kitemanrus]

@@codaza-channel Я пытаюсь понять сакральный смысл этого паттерна ) Пока кажется, что ключевая идея это возвращение интерфейса, а не конкретного объекта конкретного класса. Сами же фабрики это просто некая обертка, смысл которой не совсем понятен.

[@codaza-channel]

“Возвращение интерфейса” (более корректно - “объект реализующий интерфейс”) - не является ключевой идеей, но это важный элемент позволяющий реализовывать её. Паттерн Factory Method позволяет отделить код создания (конструирования) отдельных объектов от остального кода, который эти объекты использует. При таком подходе, масштабирование (или расширение) кода, возможно проводить, не затрагивая кодовой базы, которая использует бизнес-объекты, создаваемые фабриками.

[@Bont1860]

Очень красивая анимация и дизайн. Спасибо за ролик. Но очень бы хотелось небольшое дополнение, чтобы показать преимущества самого паттерна. Ведь самое главное, это то как мы его будем расширять и добавлять новые сущности. Ведь именно в этом удобства паттерна. Например я хочу добавить другое семейство сущностей - сотрудники. Для этого я создаю новый интерфейс для сотрудников в Domain, создаю класс сотрудник наследованный от интерфейса, а так же создаю новую абстрактную фабрику? Опять создаю все классы наследуемые от него. Не понятно в чем удобства всего этого.

[@priest_2152]

Представь, что вместо этого примера ты используешь сущности сотрудников как сущности для добавления в бд оператором твоей автоматизированной системы по управлению предприятием. Со временем штат предприятия растет, добавляется всё больше и больше сущностей. У каждой сущности свои обязанности, свойства и методы. А потом, через какое-то время, вы обнаружите что ваш код жестко привязан к самому факту существования этих сущностей. Эту проблему и решают паттерны, в том числе такие как фабричный метод. Мы можем описать в базовом классе для сущностей некий метод, который будет отвечать за конвертирование своей информации в понятный для пользователя вид (это всё условно, на самом деле так делать не стоит) - после этого вью будет всё равно с каким объектом ей работать, и наш код будет довольно резиновым. Можно промоделировать и ситуацию когда наш условный оператор хочет получить список сотрудников определенной должности из БД. В этом случае без фабричного метода нам все равно придется как-то реализовывать преобразование данных из бд в определенный список сущностей - это наплодит огромную кучу условных операторов, а при изменении одной из сущностей программа либо не скомпилируется из-за ошибки, либо будет вести себя не так, как мы этого ожидаем (что, я так полагаю, еще хуже). P.S: Данная ситуация очень притянутая, фактически здесь можно обойтись и другими паттернами и трюками. Но в этом и суть паттерном, что не получится подобрать универсальный под каждую ситуацию, они должны применятся очень точечно. Думаю в данной проблеме я бы использовал фабричный метод только для выгрузки сотрудников из бд.

[@kyk0_924]

ничего не понятнно но очень интересно)

[@fishbone_x]

@codaza Не до конца понял зачем нам эта прослойка в виде всего что в папке Factories, разве нельзя было обойтись вызовом напрямую ? типо так: void Main() { ... IMembership membership = GetMemberShip(membershipType); ... } private static IMembership GetMemberShip(string membershipType) => membershipType.ToLower() switch { "g" => new GymMembership(100) { Description = "Description Gym" }, "p" => new GymPlusPoolMembership(250) { Description = "Description G+P" }, "t" => new PersonalTrainingMembership(400) { Description = "Description PT" } ... }

[@codaza-channel]

Пример сильно упрощен, чтобы дать понимание структуры и взаимодействия классов. В реальных задачах, создание абонемента может быть весьма сложным процессом и подобное упрощение приведет к перегруженности клиентского кода, которому нужно знать все детали реализации создания всех абонементов. Таким упрощением вы нарушаете принцип единственной ответственности (Single Responsibility Principle), описываемый в SOLID.

[@fishbone_x]

@@codaza-channel спасибо)

[@nkochubashev]

Почему вы не перенесете приватные поля класса в свойства, в коде ниже? Зачем создавать поля и методы, если можно создать только свойства? namespace FitnessClub.Domain { internal class GymMembership : IMembership { private readonly string _name; private readonly decimal _price; public GymMembership(decimal price) { _name = "Gym membership"; _price = price; } public string Name => _name; public string Description { get; set; } public decimal GetPrice() => _price; } Оптимизированный вариант: namespace FitnessClub.Domain { internal class GymMembership : IMembership { private readonly decimal _price; public string Name { get; } public string Description { get; set; } public decimal GetPrice() => _price; public GymMembership(decimal price) { Name = "Gym membership"; _price = price; } } }