Когда нужно принимать интерфэйс?

Когда следует принимать интерфейс в PHP?

Принцип "принимать интерфейс, а не реализацию" — один из фундаментальных принципов объектно-ориентированного проектирования, который напрямую связан с Dependency Inversion Principle (DIP) из SOLID. В PHP это означает, что методы и конструкторы должны объявлять типы параметров как интерфейсы, а не конкретные классы.

Ключевые ситуации для использования интерфейсов

1. Внедрение зависимостей (Dependency Injection)

Когда класс зависит от внешнего сервиса (например, отправка email, работа с базой данных), следует принимать интерфейс этого сервиса. Это позволяет легко подменять реализации.

interface MailerInterface {
    public function send(Message $message): bool;
}

class SmtpMailer implements MailerInterface {
    public function send(Message $message): bool {
        // Реализация отправки через SMTP
    }
}

class NewsletterService {
    private MailerInterface $mailer;
    
    public function __construct(MailerInterface $mailer) {
        $this->mailer = $mailer; // Принимаем интерфейс, а не SmtpMailer
    }
}

2. Тестирование (Mocking и Stubbing)

Интерфейсы позволяют создавать тестовые заглушки вместо реальных зависимостей. Это особенно важно для модульного тестирования.

class TestMailer implements MailerInterface {
    private array $sentMessages = [];
    
    public function send(Message $message): bool {
        $this->sentMessages[] = $message;
        return true;
    }
    
    public function getSentCount(): int {
        return count($this->sentMessages);
    }
}

// В тесте
$testMailer = new TestMailer();
$service = new NewsletterService($testMailer);
// Тестируем без реальной отправки email

3. Соблюдение принципа открытости/закрытости (Open/Closed Principle)

Класс должен быть открыт для расширения, но закрыт для модификации. Принимая интерфейс, вы позволяете добавлять новые реализации без изменения существующего кода.

interface PaymentProcessor {
    public function process(float $amount): bool;
}

class CreditCardProcessor implements PaymentProcessor { /* ... */ }
class PayPalProcessor implements PaymentProcessor { /* ... */ }
class CryptoProcessor implements PaymentProcessor { /* ... */ }

class OrderService {
    public function checkout(PaymentProcessor $processor, float $amount) {
        // Код не меняется при добавлении новых способов оплаты
        $processor->process($amount);
    }
}

4. Работа с различными реализациями одного контракта

Когда система должна поддерживать несколько вариантов поведения, определяемых во время выполнения.

interface CacheInterface {
    public function get(string $key): mixed;
    public function set(string $key, mixed $value, int $ttl): bool;
}

class RedisCache implements CacheInterface { /* ... */ }
class FileCache implements CacheInterface { /* ... */ }
class ArrayCache implements CacheInterface { /* ... */ }

class DataService {
    public function __construct(private CacheInterface $cache) {}
    
    public function getData(string $key) {
        // Работает с любой реализацией кэша
        return $this->cache->get($key);
    }
}

5. Создание плагинных архитектур

Когда система должна позволять динамическое подключение дополнительных модулей или компонентов.

interface PluginInterface {
    public function execute(array $data): array;
}

class PluginManager {
    private array $plugins = [];
    
    public function addPlugin(PluginInterface $plugin) {
        $this->plugins[] = $plugin;
    }
    
    public function process(array $data): array {
        foreach ($this->plugins as $plugin) {
            $data = $plugin->execute($data);
        }
        return $data;
    }
}

Когда НЕ нужно принимать интерфейс

1. Для value-объектов или DTO — когда объект представляет собой простую структуру данных без поведения.
2. Для final-классов из сторонних библиотек — если у класса нет интерфейса и вы не контролируете его код.
3. В простых внутренних утилитах — где переиспользование или тестирование не требуются.

Практические рекомендации

• Создавайте интерфейс, когда у вас есть хотя бы две реализации или потенциальная возможность их появления
• Используйте интерфейсы для абстракций высокого уровня, а не для деталей реализации
• Интерфейс должен определять роль, а не просто дублировать методы класса
• В современных PHP-фреймворках (Laravel, Symfony) интерфейсы часто используются для связывания в контейнере зависимостей

Пример из реальной практики

// Плохо: принимаем конкретную реализацию
class ReportGenerator {
    public function __construct(private MySQLDatabase $db) {}
}

// Хорошо: принимаем интерфейс
interface DatabaseConnection {
    public function query(string $sql): array;
    public function execute(string $sql): int;
}

class ReportGenerator {
    public function __construct(private DatabaseConnection $db) {}
    // Теперь можно использовать MySQL, PostgreSQL, SQLite и даже тестовую базу
}

Принятие интерфейсов делает код более гибким, тестируемым и соответствующим принципам SOLID. Это инвестиция в поддерживаемость системы, которая окупается при масштабировании и изменении требований.