C# Proxy Заместитель | Design Patterns
Vložit
- čas přidán 9. 07. 2024
- Паттерны проектирования важно и нужно знать. В этом ролике мы поговорим про design pattern Proxy (Заместитель) - структурный шаблон проектирования. Поговорим о сути, посмотрим на примеры и сделаем реализацию в Visual Studio 2022 и .NET 6. Заходите, будет интересно и станет понятно 🙂
Исходный код проекта на GitHub: github.com/codaza/Cooker
C# 10 New features (новые фичи): • C# 10 New features | Н...
Telegram канал: t.me/codaza
На кофе ☕️: pay.cloudtips.ru/p/179d0532
Patreon: / codaza
Boosty: boosty.to/codaza
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 - Завершение
#proxy #designpatterns #ITubeTeam #gof #csharp #net6 #паттерныпроектирования #codaza
Удобная навигация по видео :)
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 - Завершение
Потрясающее описание и визуализация деталей паттерна! Спасибо!
Очень релаксирующий ритм повествования, не грузит после рабочего дня. Спасибо! Паттерн Спецификация - в ютубе мало представлен.
Учу C#, получается что курсы дают 25% знаний, еще 25% другие ресурсы, а этот канал 50% знаний.
Очень хотелось бы видеть больше видео.
Больше видео про паттерны, а то я сам не разберусь))))))
Ок, будем разбираться 😉
Спасибо за материал.
Хотелось бы, так же увидеть, на канале рассмотрение всех базовых патернов проектирования(все 23 шт).
Канал просто находка. Подписался. Жду нового материала.
Благодарю за поддержку. Новый материал уже готовится.
Это бесподобно! Прям мой реальный кейс, только не с рестораном))
Очень круто!)
Очень приятная подача материала. Спасибо.
Просто шикарно! С теорией, практикой, не нудным повествованием, а главное, видно что автор понимает о чем говорит!
Спасибо за то, что делитесь своими знаниями!!!
Это прекрасно! Спасибо за видео. Материал и подача на высшем уровне!
Благодарю за высокую оценку 🙂 Здорово, что удалось показать Proxy с интересной стороны!
Я редко пишу комментарии, но этот канал безусловно заслуживает внимание и проявление поддержки. Автору большое спасибо, такого качественного контента по C# мало на русском ютуб. Жду новых роликов!
P. S. Lo-fi на фоне шикарен.
Благодарю за поддержку, это действительно очень важно для новых каналов. Рад, что Вам понравился формат и подход к донесению информации. Впереди много интересного. 🙂
Я только что отдохнул после работы с пользой))
codaza, ты гигакрут!
💙
спасибо за ролик) давай следующий паттерн Декоратор
А чего так мало просмотров? Сделано качественнее чем в подавляющем большинстве роликов про паттерны.
Алгоритмы CZcams беспощадны 😥 Спасибо Вам за комментарий 🙂
@@codaza-channel ну мне то алгоритмы выдали как-то ролик ))) Значит не все потеряно. А ведь я даже не искал ни C#, ни паттерны уже очень давно.
Тогда ждём 🙂
@@codaza-channel Держись! Всегда жалко, когда хорошие авторы забрасывают каналы, так как не смогли добиться запланированных результатов.
Классный дизайн на канале
Спасибо!
Забавно, что компилятор больше не позволяет билдить структуру Order в таком виде, как в видео =) Был баг, который сейчас поправили. Сейчас в VS2022 и C#10 требуется дефолтный конструктор для подобной инициализации свойств.
P.S. Чтобы убирать неиспользуемые операторы using в VS быстро: Ctrl+R, Ctrl+G
крутое видео, спасибо! Я бы добавил, что smart proxy также называют декоратором. Для меня это было неожиданной новостью)
Лучший канал что встречал , спасибо , вы лучшие!
Кодаза топ!
спасибо огромное
Даешь больше паттернов!!!!
Ты крут! Все внятно и спасибо за работу!
Очень хорошие, структурированные и понятные видео, спасибо большое!
Было занимательно и полезно. Спасибо, автор!
🔥🔥🔥
Контент, подача - супер! Больше подписчиков каналу! Спасибо за видео~
Продолжай про паттерны плз очень круто получается!
Ты хорош
Ну раз речь пошла о паттерне прокси, то логично продолжить декоратором, адаптером или мостом. Переодически путаюсь кто из них кто. Может ваши видео разложат у меня по полочкам окончательно эту информацию.
Все здорово, спасибо за материал. Только мне кажется, что стоило разделить прокси на 2, один для кэширования, а другой для логгирования, чтобы соблюдался принцип SRP и показать наглядно, как поменяется поведение, в зависимости от порядка сборки объекта.
Это конечно придирки, но если мы знаем, что статусы получаем медленно, то их точно не стоит получать каждый раз в foreach, хотя бы перед циклом) ну и можно было по ключу найти название, а не через linq
Большое спасибо за уточнения. Действительно, стоило это учесть. Основной фокус в видео это, разумеется, Proxy, поэтому детали (как вы правильно заметили про загрузку статусов в foreach) были несколько "размыты".
великолепно👍
👍
Спасибо!
Спасибо. Жалко что нового net 5 и тем более Net 6 нет на более мене старых проектах. )))
Я использовал подобное кеширование, не зная, что это proxy pattern xD
С паттернами это нормально) Мы часто используем их в работе и позже узнаем название и формальное определение.
Реально хорошо подготовленный материал и подача. Думал все остальные посмотреть из 23 ех... ан нет... жаль
Отличная подача материала!
Только видоизменяет данные "декоратор", а прокси - нет.
А если бы понадобилось изменить статусы? Пришлось бы переписывать словарь? Добавить какой-нибудь метод UpdateStatuses() в классе Chief, который изменит информацию, а мы потом её получим в Proxy?
Здравствуйте. Спасибо за видео. У меня есть такой вопрос то что вы сделали вот тут: "IChef chef = new ProxChef(new Chef());
Привет) Подача материала огонь
Скажи пожалуйста, что за трек на 13:50?
Спасибо, очень понятно разложено. Но теперь интересно, какая принципиальная разница с декоратором?
Виктор, благодарю за комментарий и хороший вопрос. Задача Proxy - проксировать запрос от клиента к ресурсу оставаясь прозрачным на стыке взаимодействия клиента и ресурса без изменения интерфейса. Декоратор масшатабнее, он может расширять функциональность ресурса и интерфейса. Отличным применением декоратора будет пример, когда класс ресурса закрыт для наследования, а вам необходимо расширить его функциональность (возможно даже, серьёзно расширив поведение).
Спасибо за видео! Вместо dictionary со статусами не целесообразно ли использовать ,в данном случае, enum?
Для конкретного примера из видео это непринципиально. А вообще, в коммерческой разработке, enum не даст возможности заведения новых статусов без перекомпиляции приложения. В примере я подразумевал, что список статусов может быть расширен, как если бы мы загружали его из базы данных. Решение с использованием Dictionary является более гибким.
А разве ChiefProxy должен в конструкторе иметь конкретного Chief? Лучше ведь IChief, чтобы мы могли один и тот же прокси использовать для любых реализаций Шефов.
Здесь нюанс состоит в том, что ресурс (в нашем случае Chief) не всегда реализует какой-то интерфейс (в нашем случае IChief). Чаще всего ресурс реализован в виде подключаемой библиотеки, которая реализована сторонними разработчиками. Поэтому в классе Proxy, мы не всегда имеем возможность определение ресурса через интерфейс. Если же есть возможность работы с ресурсом через интерфейс, то вариант, который вы предложили, конечно, является предпочтительным.
Надо было прост сказать Proxy - это враппер, пасаны.
Как на счёт Декоратора и его разница с Proxy?
Привет, я упустил момент и не разобрался. Получается когда первый раз мы вызываем статусы , они "подвисаю" , потому что записываются в коллекцию ( IDictionary? _statuses), после этого мы всегда ее возвращаем , изменяя только сами статусы в ней. Так вот как Коллекция уведомляется об изменении статуса и выводит уже новый ?
Сами статусы (id и название статуса) читаются 1 раз внутри прокси и сохраняются (кэшируются), затем при следующем обращении к GetStatuses берётся их кэшированая версия.
А изменение id статуса происходит в словаре заказов из-за использования функции рандом каждый раз, когда мы запрашиваем список заказов (chief.GetOrders) на клиенте (в цикле while в Main).
Надеюсь понятно объяснил.
Видео уже давно, если нет ничего подобного расскажи разницу между прокси и адаптером
Как включить такие подсказки от VS? Те что серым высвечиваются в коде 12:37
Честно говоря, даже не задумывался об этих подсказках. Я использую Visual Studio 2022 и ReSharper. Вероятно что-то включено по умолчанию 🙂
Спасибо за видео.
Единственное, не совсем понял, как у нас меняются статусы у 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 мы получаем только все возможные статусы для заказа. Просто вместо того, чтобы каждый раз создавать словарь с одними и теми же значениями, можно было один раз в классе создать константу и в методе передавать на нее ссылку, но здесь сделано иначе для примера кэширования.
Декоратор будет?
Декоратор (Decorator) плиз
18:42 вырезан звук
Не очень понял в чем смысл? То что мы обращаемся за статусом один раз - это понятно. Но ведь статус может измениться, и для этого надо обращаться к шефу, чтоб узнать актуальный. Объясните пожалуйста
И сам интерфейс нельзя считать за прокси, по сути он же тоже заместитель реального объекта, только без реализации конечно? А то смотрел какойто видос про этот паттерн, там реализовывали интерфейс и говорили что это прокси, а здесь совсем все иначе.
Рекомендую обратиться к первоисточнику, а именно, к книге Gang of Four Design Patterns. Отбросьте все видео (включая это) и прочитайте рекомендации от авторов паттерна.
После второго «испачкать руки в грязи» снял лайк и выключил
Теория не плохая, реализация не достойна паблика. Учите своих зрителей как не надо программировать. Я понимаю, что это для примера, но ваш код нарушает принципы ООП и SOLID, а неопытные зрители повторяют эти ошибки. Пичалька.
Поймал ошибку:
Inconsistent accessibility: return type 'IEnumerable' is less accessible than method 'IChief.GetOrders()'
Исправил:
public struct Order