Расскажи про свой опыт реализации паттернов с использованием абстракций

Мой опыт реализации паттернов с использованием абстрактных классов и интерфейсов

За более чем 10 лет работы с PHP я реализовал десятки паттернов проектирования в различных доменных областях — от электронной коммерции до сложных CRM-систем. Ключевой принцип, который я усвоил: абстракции (интерфейсы и абстрактные классы) — это фундамент для создания гибких, поддерживаемых и тестируемых систем.

Почему абстракции критически важны

Абстракции позволяют отделить контракт от реализации. Это означает, что компоненты системы взаимодействуют через чётко определённые интерфейсы, не зная деталей реализации друг друга. На практике это даёт:

• Снижение связности между компонентами
• Возможность лёгкой замены реализаций
• Упрощение тестирования через моки и стабы
• Чёткое разделение ответственности в команде

Ключевые паттерны с абстракциями

Стратегия (Strategy Pattern) с интерфейсами

Один из наиболее часто используемых паттернов в моей практике. Например, система расчёта доставки с разными провайдерами:

<?php

interface DeliveryCalculatorInterface
{
    public function calculate(array $items, string $destination): float;
    public function supports(string $providerCode): bool;
}

class DhlDeliveryCalculator implements DeliveryCalculatorInterface
{
    public function calculate(array $items, string $destination): float
    {
        // Логика расчёта для DHL
        $baseCost = 10.0;
        $weight = array_sum(array_column($items, 'weight'));
        return $baseCost + ($weight * 2.5);
    }
    
    public function supports(string $providerCode): bool
    {
        return $providerCode === 'dhl';
    }
}

class DeliveryContext
{
    private array $calculators;
    
    public function __construct(DeliveryCalculatorInterface ...$calculators)
    {
        foreach ($calculators as $calculator) {
            $this->calculators[] = $calculator;
        }
    }
    
    public function calculateCost(array $items, string $providerCode): float
    {
        foreach ($this->calculators as $calculator) {
            if ($calculator->supports($providerCode)) {
                return $calculator->calculate($items, 'default');
            }
        }
        throw new \InvalidArgumentException("Unsupported delivery provider");
    }
}

Фабричный метод с абстрактным классом

При создании сложных объектов с вариациями:

<?php

abstract class ReportGenerator
{
    abstract protected function createExporter(): ReportExporterInterface;
    
    public function generate(array $data): string
    {
        $exporter = $this->createExporter();
        $processedData = $this->processData($data);
        return $exporter->export($processedData);
    }
    
    protected function processData(array $data): array
    {
        // Общая логика обработки данных
        return array_filter($data);
    }
}

class PdfReportGenerator extends ReportGenerator
{
    protected function createExporter(): ReportExporterInterface
    {
        return new PdfExporter();
    }
}

Реальные кейсы из практики

1. Платёжная система с плагинами — создал абстрактный класс PaymentProcessor с шаблонным методом process(), где конкретные процессоры (Stripe, PayPal) реализовывали только специфические шаги авторизации и подтверждения.

2. Система кэширования с многоуровневым хранилищем — использовал интерфейс CacheInterface с реализациями для Redis, Memcached и файлового кэша. Паттерн Декоратор позволил создать цепочку кэшей с автоматическим fallback.

3. Построитель отчётов с Visitor — для сложной аналитики создал абстрактный класс ReportVisitor с методами visitSale(), visitUser() и т.д., что позволило добавлять новые типы отчётов без изменения структуры данных.

Ошибки и уроки

Раньше я иногда злоупотреблял наследованием, создавая глубокие иерархии абстрактных классов. Сейчас предпочитаю:

• Композицию вместо наследования там, где это уместно
• Интерфейсы для определения контрактов
• Трейты для повторного использования кода без наследования
• Принцип KISS — не вводить абстракции без реальной необходимости

Best Practices из текущих проектов

• Каждый интерфейс должен иметь только одну ответственность (Interface Segregation Principle)
• Абстрактные классы для общего поведения, интерфейсы для контрактов
• Использование type-hinting на интерфейсы в DI-контейнере
• Тестирование через интерфейсы с mock-объектами

Абстракции в PHP эволюционировали — сегодня у нас есть типизированные свойства, union types, attributes, что позволяет создавать ещё более выразительные и безопасные абстракции. Однако фундаментальные принципы остаются: правильно выбранный уровень абстракции определяет долгосрочную поддерживаемость системы.