Удобная навигация по видео :) 0:00 - Начало 0:48 - Proxy это Structural Design Pattern 1:23 - Концепция Proxy 2:23 - Proxy для логирования 2:59 - Proxy для кэширования 3:57 - Proxy для контроля доступа 4:17 - Proxy для дополнительной логики 4:44 - Виды Proxy 6:13 - Анатомия Proxy 8:47 - Live example 10:48 - Реализация примера 28:07 - Завершение
Спасибо за материал. Хотелось бы, так же увидеть, на канале рассмотрение всех базовых патернов проектирования(все 23 шт). Канал просто находка. Подписался. Жду нового материала.
Я редко пишу комментарии, но этот канал безусловно заслуживает внимание и проявление поддержки. Автору большое спасибо, такого качественного контента по C# мало на русском ютуб. Жду новых роликов! P. S. Lo-fi на фоне шикарен.
Благодарю за поддержку, это действительно очень важно для новых каналов. Рад, что Вам понравился формат и подход к донесению информации. Впереди много интересного. 🙂
Спасибо! Забавно, что компилятор больше не позволяет билдить структуру Order в таком виде, как в видео =) Был баг, который сейчас поправили. Сейчас в VS2022 и C#10 требуется дефолтный конструктор для подобной инициализации свойств. P.S. Чтобы убирать неиспользуемые операторы using в VS быстро: Ctrl+R, Ctrl+G
Ну раз речь пошла о паттерне прокси, то логично продолжить декоратором, адаптером или мостом. Переодически путаюсь кто из них кто. Может ваши видео разложат у меня по полочкам окончательно эту информацию.
Все здорово, спасибо за материал. Только мне кажется, что стоило разделить прокси на 2, один для кэширования, а другой для логгирования, чтобы соблюдался принцип SRP и показать наглядно, как поменяется поведение, в зависимости от порядка сборки объекта. Это конечно придирки, но если мы знаем, что статусы получаем медленно, то их точно не стоит получать каждый раз в foreach, хотя бы перед циклом) ну и можно было по ключу найти название, а не через linq
Большое спасибо за уточнения. Действительно, стоило это учесть. Основной фокус в видео это, разумеется, Proxy, поэтому детали (как вы правильно заметили про загрузку статусов в foreach) были несколько "размыты".
Виктор, благодарю за комментарий и хороший вопрос. Задача Proxy - проксировать запрос от клиента к ресурсу оставаясь прозрачным на стыке взаимодействия клиента и ресурса без изменения интерфейса. Декоратор масшатабнее, он может расширять функциональность ресурса и интерфейса. Отличным применением декоратора будет пример, когда класс ресурса закрыт для наследования, а вам необходимо расширить его функциональность (возможно даже, серьёзно расширив поведение).
Для конкретного примера из видео это непринципиально. А вообще, в коммерческой разработке, enum не даст возможности заведения новых статусов без перекомпиляции приложения. В примере я подразумевал, что список статусов может быть расширен, как если бы мы загружали его из базы данных. Решение с использованием Dictionary является более гибким.
А если бы понадобилось изменить статусы? Пришлось бы переписывать словарь? Добавить какой-нибудь метод UpdateStatuses() в классе Chief, который изменит информацию, а мы потом её получим в Proxy?
Привет, я упустил момент и не разобрался. Получается когда первый раз мы вызываем статусы , они "подвисаю" , потому что записываются в коллекцию ( IDictionary? _statuses), после этого мы всегда ее возвращаем , изменяя только сами статусы в ней. Так вот как Коллекция уведомляется об изменении статуса и выводит уже новый ?
Сами статусы (id и название статуса) читаются 1 раз внутри прокси и сохраняются (кэшируются), затем при следующем обращении к GetStatuses берётся их кэшированая версия. А изменение id статуса происходит в словаре заказов из-за использования функции рандом каждый раз, когда мы запрашиваем список заказов (chief.GetOrders) на клиенте (в цикле while в Main). Надеюсь понятно объяснил.
Спасибо за видео. Единственное, не совсем понял, как у нас меняются статусы у Proxy, если мы обращаемся за ними к Chief только один раз при инициализации, а дальше поле _status не меняется (т.к. после первой же инициализации оно будет не null). _status = _chief.GetStatus(); Образует ссылку, поэтому значения _status меняются при изменении _chief (который, в свою очередь, ссылается на new Chief())?
В примере, который обсуждается в ролике, подразумевается, что справочник статусов является неизменным, то есть статусы заказов ("ready", "not ready", "preparing") не добавляются и не удаляются. В более сложных сценариях, справочник может изменяться. Для его обновления необходимо использовать различные стратегии кэширования, которые подбираются в соответствии с требованиями задачи. Например, можно применить времени экспирации, чтобы справочник загружался через каждые 10 минут.
@@codaza-channel Рискну предположить, что вопрос был не об этом. Я думаю, что Dake Fasso, как и мне, интересно - почему статусы в консоли обновляются, если мы не обращаемся к _chief повторно? Потому что мы кэшируем ссылки на сами статусы, и в данном случае нам не нужно ждать 2 секунды, т.к. эти 2 секунды запускаются параллельно, в другом потоке и к нашему выводу в консоль уже не имеют никакого отношения. Верно?
@@aleksey8405 Я заметил что у всех моих заказов одинаковые статусы. Например 1 1 1 или в следующий раз 2 2 2, во время дебага проскальзываю 1 1 2 например
Потому что заказы с обновленными статусами мы получаем с помощью метода GetOrder(). А в методе GetStatus мы получаем только все возможные статусы для заказа. Просто вместо того, чтобы каждый раз создавать словарь с одними и теми же значениями, можно было один раз в классе создать константу и в методе передавать на нее ссылку, но здесь сделано иначе для примера кэширования.
А разве ChiefProxy должен в конструкторе иметь конкретного Chief? Лучше ведь IChief, чтобы мы могли один и тот же прокси использовать для любых реализаций Шефов.
Здесь нюанс состоит в том, что ресурс (в нашем случае Chief) не всегда реализует какой-то интерфейс (в нашем случае IChief). Чаще всего ресурс реализован в виде подключаемой библиотеки, которая реализована сторонними разработчиками. Поэтому в классе Proxy, мы не всегда имеем возможность определение ресурса через интерфейс. Если же есть возможность работы с ресурсом через интерфейс, то вариант, который вы предложили, конечно, является предпочтительным.
Не очень понял в чем смысл? То что мы обращаемся за статусом один раз - это понятно. Но ведь статус может измениться, и для этого надо обращаться к шефу, чтоб узнать актуальный. Объясните пожалуйста
И сам интерфейс нельзя считать за прокси, по сути он же тоже заместитель реального объекта, только без реализации конечно? А то смотрел какойто видос про этот паттерн, там реализовывали интерфейс и говорили что это прокси, а здесь совсем все иначе.
Рекомендую обратиться к первоисточнику, а именно, к книге Gang of Four Design Patterns. Отбросьте все видео (включая это) и прочитайте рекомендации от авторов паттерна.
Теория не плохая, реализация не достойна паблика. Учите своих зрителей как не надо программировать. Я понимаю, что это для примера, но ваш код нарушает принципы ООП и SOLID, а неопытные зрители повторяют эти ошибки. Пичалька.
Удобная навигация по видео :)
0:00 - Начало
0:48 - Proxy это Structural Design Pattern
1:23 - Концепция Proxy
2:23 - Proxy для логирования
2:59 - Proxy для кэширования
3:57 - Proxy для контроля доступа
4:17 - Proxy для дополнительной логики
4:44 - Виды Proxy
6:13 - Анатомия Proxy
8:47 - Live example
10:48 - Реализация примера
28:07 - Завершение
Очень релаксирующий ритм повествования, не грузит после рабочего дня. Спасибо! Паттерн Спецификация - в ютубе мало представлен.
Спасибо за материал.
Хотелось бы, так же увидеть, на канале рассмотрение всех базовых патернов проектирования(все 23 шт).
Канал просто находка. Подписался. Жду нового материала.
Благодарю за поддержку. Новый материал уже готовится.
Это бесподобно! Прям мой реальный кейс, только не с рестораном))
Очень круто!)
Я только что отдохнул после работы с пользой))
codaza, ты гигакрут!
💙
Потрясающее описание и визуализация деталей паттерна! Спасибо!
Я редко пишу комментарии, но этот канал безусловно заслуживает внимание и проявление поддержки. Автору большое спасибо, такого качественного контента по C# мало на русском ютуб. Жду новых роликов!
P. S. Lo-fi на фоне шикарен.
Благодарю за поддержку, это действительно очень важно для новых каналов. Рад, что Вам понравился формат и подход к донесению информации. Впереди много интересного. 🙂
Очень приятная подача материала. Спасибо.
Это прекрасно! Спасибо за видео. Материал и подача на высшем уровне!
Благодарю за высокую оценку 🙂 Здорово, что удалось показать Proxy с интересной стороны!
Спасибо за то, что делитесь своими знаниями!!!
Просто шикарно! С теорией, практикой, не нудным повествованием, а главное, видно что автор понимает о чем говорит!
Лучший канал что встречал , спасибо , вы лучшие!
Больше видео про паттерны, а то я сам не разберусь))))))
Ок, будем разбираться 😉
Учу C#, получается что курсы дают 25% знаний, еще 25% другие ресурсы, а этот канал 50% знаний.
Очень хотелось бы видеть больше видео.
Кодаза топ!
Ты крут! Все внятно и спасибо за работу!
крутое видео, спасибо! Я бы добавил, что smart proxy также называют декоратором. Для меня это было неожиданной новостью)
Контент, подача - супер! Больше подписчиков каналу! Спасибо за видео~
Классный дизайн на канале
спасибо за ролик) давай следующий паттерн Декоратор
Было занимательно и полезно. Спасибо, автор!
А чего так мало просмотров? Сделано качественнее чем в подавляющем большинстве роликов про паттерны.
Алгоритмы UA-cam беспощадны 😥 Спасибо Вам за комментарий 🙂
@@codaza-channel ну мне то алгоритмы выдали как-то ролик ))) Значит не все потеряно. А ведь я даже не искал ни C#, ни паттерны уже очень давно.
Тогда ждём 🙂
@@codaza-channel Держись! Всегда жалко, когда хорошие авторы забрасывают каналы, так как не смогли добиться запланированных результатов.
Спасибо!
Забавно, что компилятор больше не позволяет билдить структуру Order в таком виде, как в видео =) Был баг, который сейчас поправили. Сейчас в VS2022 и C#10 требуется дефолтный конструктор для подобной инициализации свойств.
P.S. Чтобы убирать неиспользуемые операторы using в VS быстро: Ctrl+R, Ctrl+G
Продолжай про паттерны плз очень круто получается!
великолепно👍
Даешь больше паттернов!!!!
Спасибо!
спасибо огромное
🔥🔥🔥
Ну раз речь пошла о паттерне прокси, то логично продолжить декоратором, адаптером или мостом. Переодически путаюсь кто из них кто. Может ваши видео разложат у меня по полочкам окончательно эту информацию.
Все здорово, спасибо за материал. Только мне кажется, что стоило разделить прокси на 2, один для кэширования, а другой для логгирования, чтобы соблюдался принцип SRP и показать наглядно, как поменяется поведение, в зависимости от порядка сборки объекта.
Это конечно придирки, но если мы знаем, что статусы получаем медленно, то их точно не стоит получать каждый раз в foreach, хотя бы перед циклом) ну и можно было по ключу найти название, а не через linq
Большое спасибо за уточнения. Действительно, стоило это учесть. Основной фокус в видео это, разумеется, Proxy, поэтому детали (как вы правильно заметили про загрузку статусов в foreach) были несколько "размыты".
Ты хорош
Спасибо. Жалко что нового net 5 и тем более Net 6 нет на более мене старых проектах. )))
Я использовал подобное кеширование, не зная, что это proxy pattern xD
С паттернами это нормально) Мы часто используем их в работе и позже узнаем название и формальное определение.
Здравствуйте. Спасибо за видео. У меня есть такой вопрос то что вы сделали вот тут: "IChef chef = new ProxChef(new Chef());
👍
Спасибо, очень понятно разложено. Но теперь интересно, какая принципиальная разница с декоратором?
Виктор, благодарю за комментарий и хороший вопрос. Задача Proxy - проксировать запрос от клиента к ресурсу оставаясь прозрачным на стыке взаимодействия клиента и ресурса без изменения интерфейса. Декоратор масшатабнее, он может расширять функциональность ресурса и интерфейса. Отличным применением декоратора будет пример, когда класс ресурса закрыт для наследования, а вам необходимо расширить его функциональность (возможно даже, серьёзно расширив поведение).
Спасибо за видео! Вместо dictionary со статусами не целесообразно ли использовать ,в данном случае, enum?
Для конкретного примера из видео это непринципиально. А вообще, в коммерческой разработке, enum не даст возможности заведения новых статусов без перекомпиляции приложения. В примере я подразумевал, что список статусов может быть расширен, как если бы мы загружали его из базы данных. Решение с использованием Dictionary является более гибким.
А если бы понадобилось изменить статусы? Пришлось бы переписывать словарь? Добавить какой-нибудь метод UpdateStatuses() в классе Chief, который изменит информацию, а мы потом её получим в Proxy?
Привет, я упустил момент и не разобрался. Получается когда первый раз мы вызываем статусы , они "подвисаю" , потому что записываются в коллекцию ( IDictionary? _statuses), после этого мы всегда ее возвращаем , изменяя только сами статусы в ней. Так вот как Коллекция уведомляется об изменении статуса и выводит уже новый ?
Сами статусы (id и название статуса) читаются 1 раз внутри прокси и сохраняются (кэшируются), затем при следующем обращении к GetStatuses берётся их кэшированая версия.
А изменение id статуса происходит в словаре заказов из-за использования функции рандом каждый раз, когда мы запрашиваем список заказов (chief.GetOrders) на клиенте (в цикле while в Main).
Надеюсь понятно объяснил.
Как на счёт Декоратора и его разница с Proxy?
Спасибо за видео.
Единственное, не совсем понял, как у нас меняются статусы у Proxy, если мы обращаемся за ними к Chief только один раз при инициализации, а дальше поле _status не меняется (т.к. после первой же инициализации оно будет не null).
_status = _chief.GetStatus();
Образует ссылку, поэтому значения _status меняются при изменении _chief (который, в свою очередь, ссылается на new Chief())?
В примере, который обсуждается в ролике, подразумевается, что справочник статусов является неизменным, то есть статусы заказов ("ready", "not ready", "preparing") не добавляются и не удаляются. В более сложных сценариях, справочник может изменяться. Для его обновления необходимо использовать различные стратегии кэширования, которые подбираются в соответствии с требованиями задачи. Например, можно применить времени экспирации, чтобы справочник загружался через каждые 10 минут.
@@codaza-channel Рискну предположить, что вопрос был не об этом. Я думаю, что Dake Fasso, как и мне, интересно - почему статусы в консоли обновляются, если мы не обращаемся к _chief повторно? Потому что мы кэшируем ссылки на сами статусы, и в данном случае нам не нужно ждать 2 секунды, т.к. эти 2 секунды запускаются параллельно, в другом потоке и к нашему выводу в консоль уже не имеют никакого отношения. Верно?
@@aleksey8405 Я заметил что у всех моих заказов одинаковые статусы. Например 1 1 1 или в следующий раз 2 2 2, во время дебага проскальзываю 1 1 2 например
Потому что заказы с обновленными статусами мы получаем с помощью метода GetOrder(). А в методе GetStatus мы получаем только все возможные статусы для заказа. Просто вместо того, чтобы каждый раз создавать словарь с одними и теми же значениями, можно было один раз в классе создать константу и в методе передавать на нее ссылку, но здесь сделано иначе для примера кэширования.
Отличная подача материала!
Только видоизменяет данные "декоратор", а прокси - нет.
Привет) Подача материала огонь
Скажи пожалуйста, что за трек на 13:50?
Реально хорошо подготовленный материал и подача. Думал все остальные посмотреть из 23 ех... ан нет... жаль
Как включить такие подсказки от VS? Те что серым высвечиваются в коде 12:37
Честно говоря, даже не задумывался об этих подсказках. Я использую Visual Studio 2022 и ReSharper. Вероятно что-то включено по умолчанию 🙂
А разве ChiefProxy должен в конструкторе иметь конкретного Chief? Лучше ведь IChief, чтобы мы могли один и тот же прокси использовать для любых реализаций Шефов.
Здесь нюанс состоит в том, что ресурс (в нашем случае Chief) не всегда реализует какой-то интерфейс (в нашем случае IChief). Чаще всего ресурс реализован в виде подключаемой библиотеки, которая реализована сторонними разработчиками. Поэтому в классе Proxy, мы не всегда имеем возможность определение ресурса через интерфейс. Если же есть возможность работы с ресурсом через интерфейс, то вариант, который вы предложили, конечно, является предпочтительным.
Не очень понял в чем смысл? То что мы обращаемся за статусом один раз - это понятно. Но ведь статус может измениться, и для этого надо обращаться к шефу, чтоб узнать актуальный. Объясните пожалуйста
Декоратор будет?
Видео уже давно, если нет ничего подобного расскажи разницу между прокси и адаптером
Надо было прост сказать Proxy - это враппер, пасаны.
И сам интерфейс нельзя считать за прокси, по сути он же тоже заместитель реального объекта, только без реализации конечно? А то смотрел какойто видос про этот паттерн, там реализовывали интерфейс и говорили что это прокси, а здесь совсем все иначе.
Рекомендую обратиться к первоисточнику, а именно, к книге Gang of Four Design Patterns. Отбросьте все видео (включая это) и прочитайте рекомендации от авторов паттерна.
Декоратор (Decorator) плиз
18:42 вырезан звук
"Не могу открыть ютуб, памагити"... Автор что-то знал....
После второго «испачкать руки в грязи» снял лайк и выключил
Теория не плохая, реализация не достойна паблика. Учите своих зрителей как не надо программировать. Я понимаю, что это для примера, но ваш код нарушает принципы ООП и SOLID, а неопытные зрители повторяют эти ошибки. Пичалька.
Поймал ошибку:
Inconsistent accessibility: return type 'IEnumerable' is less accessible than method 'IChief.GetOrders()'
Исправил:
public struct Order
Очень хорошие, структурированные и понятные видео, спасибо большое!