Proxy (Заместитель, Прокси) ► Шаблон проектирования Урок №22

Заместитель (англ. Proxy) - структурный шаблон проектирования, предоставляющий объект, который контролирует доступ к другому объекту, перехватывая все вызовы (выполняет функцию контейнера). Заместитель позволяет создать промежуточный слой между бизнес-логикой приложения и деталями.
Пример:
В существующий класс реализованный как деталь (плагин) для основной бизнес-логики
требуется добавить некую дополнительную функциональность:
1) Кеширование
2) Проверка доступа перед исполнением
3) Шифрование запроса перед отправкой (расшифровка ответа)
4) Логирование
5) Анализ кол-ва обращений и тп
#laravel #proxy_template #шаблоны_проектирования #design_patterns
*
★ Автор: Дмитрий Афанасьев.
★ Канал: clck.ru/JVYct
*
► Выразить благодарность, поддержать донатом развитие канала.
★ www.tinkoff.ru...
★ www.donational...
*
► Еще интересные курсы:
★ Видеокурс по Laravel: clck.ru/JVYa2
★ Видеокурс по Git: clck.ru/JVYYm
★ Объяснение SOLID: clck.ru/JVYXq
★ Шаблоны проектирования: clck.ru/JVYX7
★ Структурные шаблоны проектирования: clck.ru/TVB9Y
★★★ Все курсы → clck.ru/JVYVd

[@artem031294]

Большое спасибо за видео. Вопрос: класс Заместителя зависит всегда только от конкретного объекта (new ProductRepsoitoryImpl() у вас), или в качестве зависимости можно ему интерфейс передавать?

[@vitall789]

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

[@DmitryAfanasyev]

Работа через интерфейсы - это очерчивание архитектурных границ. Если прокси и целевой объект будут находиться по одну сторону границы, то можно использовать конкретный класс. Так же прокси "становится" для б-л целевым объектом, что предполагает что основной целевой объект никто использовать не будет - все перейдут на прокси. Это тоже плюс для использования целевого класса внутри прокси как "конкретный". Еще один алгоритм понять использовать конкретный класс или интерфейс - "Если целевой класс независим (или очень мало зависим), при этом много других классов зависят от него, то надо его превращать в плагин - то есть работать с ним через интерфейс". Если оно так, то 1) внутри прокси можно можно породить целевой объект через интерфейс (вероятно уже другой, наследник текущего) 2) либо в сервис провайдере задать правило как внедрить зависимость в прокси.

[@artem031294]

@@DmitryAfanasyev а вот в случае, когда прокси становится в итоге целевым объектом, расширяющим базовый, можно ли трейтами расширить базовый, не прибегая к прокси? Кроме тестирования, какие плюсы у прокси будут?

[@DmitryAfanasyev]

Если прокси начнёт расширять целевой класс, он перестает быть прокси и становится Декоратором.

[@ruslanvoroshchukowlookitlt245]

Спасибо за качественный материал, ждем продолжения!

[@rikitarurikitaru7716]

Спасибо, мне как раз для скорострелов -топ тема, за такое подписываюсь :)

[@retvain]

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

[@DrTopk]

Авансом поставил лайк! Вечером посмотрю

[@AntonReut]

Отличный материал и качество видео! Спасибо.

[@DmitryAfanasyev]

🙏

[@Slavec5]

Спасибо за видео, присоединяюсь к вопросу Артёма ниже

[@DmitryAfanasyev]

Ответил

[@misha-pitegorsk]

Наконец-то вернулись к структурным. А то литература, литературой, а с применением к Ларавель (и не на кошечках, собачках) никто как Вы не покажет. Спасибо, Дмитрий. Хотя и правда, даже после 2-го круга просмотров, без применения на реальном проекте многое вылетает из головы со временем. Чем-то по исполнению в Ларавель напомнил адаптер. С самого начала подумал, что всё видео таким быстрым будет, пришлось с замедлением смотреть)))

[@DmitryAfanasyev]

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

[@sovrinfo]

Большое спасибо за видео

[@saintsplay2337]

Было интересно, спасибо, лайк!

[@alexathe6896]

Спасибо за видео

[@AsRammstein]

Спасибо за видос)

[@dmitryleiko2869]

Лайк однозначно, спасибо :)

[@itsokay7052]

Продвигаем в массы шаблоны проэктирования )

[@byalexes]

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

[@АндрейГузич-ф3д]

По смыслу очень похоже на Декоратор. И там и там объект имеет тот же интерфейс что и базовый класс, и там и там расширяет или заменяет функциональность объекта базового класса. Разница заметна только в том. что декоратор динамически добавляет функциональность, а тут судя по всему нет. и видимо поэтому применена композиция. Так или еще есть разница?

[@ЯрославВлас-б6т]

Требую продолжение =)

[@otabeksobirov7686]

Дмитрий не Иисус, он обязательно вернётся) Поставил лайк, потрезвею, обязательно посмотрю)

[@DmitryAfanasyev]

😂😂😂😂

[@AnisimovAM]

Спасибо за интересное видео. Есть вопрос: в чем тогда разница между декоратором и прокси? В какой ситуации подходит один, а в какой другой. Выглядит так, что примерно задача одна «сделать какое-то побочное действие» при работе с целевым объектом.

[@DmitryAfanasyev]

Декоратор может расширять интерфейс. Прокси должен реализовать тот же интерфейс. Расширять нельзя.

[@AnisimovAM]

@@DmitryAfanasyev а точно ли декоратор может расширять интерфейс? Я сейчас перечитываю пример на рефакторинг.гуру с нотификациями и там интерфейс один. Как раз и сказано, что вы можете обернуть в несколько оберток и работать как с изначальным объектом, но получив изменения от всех оберток.

[@AnisimovAM]

@@DmitryAfanasyev И выглядит так, что декоратор нужно использовать когда нужно делать много вариантов небольших изменений. И можно было их легко комбинировать. А прокси - это разовое применение. Или прокси тоже можно много штук слоями обернуть? Или прокси это вообще полная замена исходного объекта? Типа мы больше нигде не используем исходный?

[@ruslanvoroshchukowlookitlt245]

@@DmitryAfanasyev получается основное отличие от декоратора в целевом назначении: декоратор - расширяет базовую логику целевого класса, а proxy внедряет промежуточную логику, не относящуюся к назначению целевого класса. Соответственно применение либо отмена использования proxy не должна затрагивать целевое назначение. Если да, то более универсальным выглядит создание в прокси экземпляра целевого класса также через интерфейс, тогда последний может быть подменен в приложении независимо, без внесения изменения в сам proxy, или?

[@DmitryAfanasyev]

Да, все верно

[@vitall789]

Универсальный вариант: 1. Создание реализационного класса не в прокси, а передаем параметром - new ..., что дает возможность работать внутри с подобными объектами, одному и тому же прокси. 2. Прокси при инициализ. класса сохраняет объект с которым будет работать соответственно. 3. Прокси использует только один маг. метод - __call($name, $args): if(!method_exists($this->OBJ, '_'.$name)){ if(method_exists($this->OBJ, $name)) return $this->OBJ->$name(...$args); throw new \Error($this->error = "Method $name doesn't exist", $code); } switch($name){ case 'test': throw new \Error($this->error = "Method $name not allowed", $code); } Суть маг. метода в том - в моем случае, это проверка есть ли имя функции начинающееся с "_" символа, то вызов предназначен для взаимодействия с прокси... если нет, то прокси просто передает вызов дальше, если нет вообще такого метода, можно выбросить исключение. Также доп. можно проверять спец. имена, к которым ограничить доступ - типа "test". Дальше маг. метод работает с основным объектом как хочет и возвращает результат. Как было сказано в видео, прокси должен быть макс. абстрагирован от реализации основного объекта. Т.е. он жонглирует только методами, которые реализованы только в основном классе!

[@DmitryAfanasyev]

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

[@onlybestmusic4185]

Всё плохо :) Начиная от "явное лучше чем неявное" и заканчивая непониманием смысла патерна прокси. Введение специального именования методов для определения необходимости проксирования. Я прошу прощения, можешь меня бить ногами, но я назову это говно кодом. Мало того что ты сам через пару месяцев не вспомнишь как это работает, хуже всего то что другой человек голову сломает прежде чем поймёт что происходит и почему. Суть шаблонов проектирования в том чтобы упростить задачу, предоставить максимально понятное, эффективное общепринятое решение. То что ты предлагаешь это не упрощает а запутывает причём максимально.

[@agnar878]

Реквесты в ларавель какой паттерн реализуют? Спасибо

[@АленаИштубаева]

1. как удалить модель из кэша, после апдейта или после добавление новой модели? 2. а как проверить на уникальность например в CreateUserAction (хотелось бы запрос сделать в БД, а не в кэш. или здесь не надо юзать UserRepository, а юзать User::query(), хотя... наверное нет)?

[@DmitryAfanasyev]

1 - можно через Observer обновить кэш для модели; 2 - в laravel есть CreateOrUpdate - если не найдет, то создаст новую, если найдет, то обновит то что нашел.

[@МаринаРозмарин]

все по делу

[@nickfist9187]

Спасибо за видео. А за черную страницу в браузере отдельно!

[@xpeh2xpeh]

спасибо

[@vitaliyp.3007]

Выходит для всех остальных методов мы просто делегируем вызов к целевому классу? То есть допустим 10 методов и в одном мы делаем кеширование, а в 9 просто вызов оригинального метода?

[@bobaboba3505]

Ура ура ура

[@ДенисБаженов-в2с]

Блин времени то 10 уже пора вставать.

[@onlybestmusic4185]

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

[@onlybestmusic4185]

1. Назначение Декоратор: добавление новой, либо видоизменение функциональности поверх метода целевого класса с сохранением смысловой нагрузки. Прокси: внедрение промежуточной функциональности между вызывающей стороной и целевым классом. Данная промежуточная логика не имеет никакого отношения к логике целевого класса. Например: ограничение доступа или улучшение производительности путем кеширования и тп 2. Использование Декоратор: вызывающая сторона может в равной степени использовать как декоратор так и целевой класс Прокси: вызывающая сторона на никак не используют напрямую целевой класс и даже не знает о его существовании. Вызывающая сторона знает только о существовании прокси, а вот proxi уже знает обо всём остальном. 3. Способы инстанцирования Декоратор: целевой класс может быть получен либо инъекцией либо инстанцированием Прокси: только композиция.

[@DmitryAfanasyev]

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