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

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

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

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

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

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

💙

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Factory Method

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

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

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

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

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

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

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

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

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

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

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

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

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

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