Proxy - контроль доступу і кеш

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 нарощує функціональність.