Proxy ставить посередника з тим самим інтерфейсом перед реальним об'єктом, щоб контролювати доступ до нього.
Яку проблему вирішує
Інколи перед зверненням до об'єкта треба додати кешування, перевірку прав, лінива ініціалізацію чи мережевий виклик - але вшивати це в сам об'єкт або розкидати по клієнтах не хочеться.
Як вирішує
Проксі реалізує той самий інтерфейс, що й реальний об'єкт, додає свою логіку і за потреби делегує виклик далі. Бізнес-логіка працює з одним інтерфейсом (RatesProvider), не знаючи, чи звертається вона до реального API, чи до кешу.
interface RatesProvider
{
public function latest(): array;
}
class ApiRatesProvider implements RatesProvider
{
public function latest(): array
{
return ['USD' => 41.2, 'EUR' => 44.7];
}
}
class CachedRatesProxy implements RatesProvider
{
public function __construct(private RatesProvider $provider) {}
public function latest(): array
{
return cache()->remember('rates', 300, function () {
return $this->provider->latest();
});
}
}
Де застосовувати
- Зовнішні API чи дорогі обчислення, які варто кешувати.
- Типові різновиди: кешуючий проксі (як у прикладі), захисний (перевірка прав), віддалений (звернення по мережі), лінивий (відкладена ініціалізація дорогого об'єкта).
Плюси та мінуси
- + Додає поведінку, не змінюючи ні реальний об'єкт, ні клієнта.
- + Може економити ресурси (кеш, ліниве створення) і приховувати складність.
- − Зайвий шар у стеку викликів, якщо додаткова поведінка не потрібна.
- − Близький до Decorator; різниця в намірі - Proxy керує доступом, Decorator нарощує функціональність.
