Что лучше: передавать параметры в конструктор или инициализировать их внутри конструктора?

Оптимальные практики передачи параметров в конструктор

Вопрос выбора между передачей параметров в конструктор и их инициализацией внутри конструктора фундаментален для проектирования поддерживаемых и тестируемых PHP-приложений. Как опытный разработчик, я рекомендую явную передачу параметров через конструктор как основной подход, за исключением специальных случаев.

Основные подходы и их последствия

1. Явная передача параметров (Dependency Injection)

class UserService
{
    private UserRepository $repository;
    private LoggerInterface $logger;
    
    public function __construct(
        UserRepository $repository, 
        LoggerInterface $logger
    ) {
        $this->repository = $repository;
        $this->logger = $logger;
    }
}

Преимущества:

• Принцип явных зависимостей - класс честно декларирует всё, что ему нужно
• Тестируемость - легко подменить зависимости моками в юнит-тестах
• Гибкость - можно менять реализации зависимостей без изменения класса
• Принцип единственной ответственности - класс не знает, как создавать свои зависимости
• Поддержка инверсии управления - работает с контейнерами внедрения зависимостей

2. Инициализация внутри конструктора

class OrderProcessor
{
    private PaymentGateway $gateway;
    
    public function __construct()
    {
        $this->gateway = new StripeGateway(config('stripe.key'));
    }
}

Допустимые случаи использования:

• Value Objects - простые неизменяемые объекты-значения
• Конфигурационные параметры из глобального состояния (только если нет DI-контейнера)
• Вспомогательные утилиты без внешних зависимостей
• Приватные зависимости, которые никогда не потребуют замены

Критерии выбора на практике

Когда передавать параметры:

// ✅ Хорошо: зависимости передаются явно
class NotificationService
{
    public function __construct(
        private Mailer $mailer,
        private TemplateRenderer $renderer
    ) {}
}

// Конфигурация через DI-контейнер
$service = new NotificationService($mailer, $renderer);

Когда инициализировать внутри:

// ✅ Допустимо: создание простого value object
class Money
{
    public function __construct(
        private float $amount,
        private string $currency = 'USD'
    ) {
        $this->validateAmount($amount);
        $this->currency = strtoupper($currency);
    }
}

// ⚠️ Осторожно: доступ к глобальному состоянию
class ConfigReader
{
    public function __construct()
    {
        $this->config = $_ENV['APP_CONFIG'] ?? [];
    }
}

Архитектурные рекомендации

Для бизнес-логики и сервисов:

• Всегда используйте внедрение зависимостей
• Избегайте Service Locator (антипаттерн, скрывающий зависимости)
• Логируйте минимально необходимые зависимости, а не всё подряд

Для инфраструктурного кода:

• Фабрики и строители могут создавать объекты внутри
• Адаптеры могут инкапсулировать сложную инициализацию
• Специализированные объекты (DateTime, коллекции) создаются напрямую

Пример комплексного подхода

// Базовый класс с явными зависимостями
abstract class BaseService
{
    public function __construct(
        protected EventDispatcher $dispatcher,
        protected LoggerInterface $logger
    ) {}
}

// Конкретная реализация
class UserRegistrationService extends BaseService
{
    public function __construct(
        EventDispatcher $dispatcher,
        LoggerInterface $logger,
        private UserRepository $repository,
        private EmailVerifier $verifier
    ) {
        parent::__construct($dispatcher, $logger);
    }
    
    public function register(UserDto $dto): User
    {
        // Использование всех явно переданных зависимостей
        $user = $this->repository->create($dto);
        $this->verifier->sendVerification($user);
        $this->dispatcher->dispatch(new UserRegistered($user));
        
        return $user;
    }
}

Исключения и нюансы

1. Простые DTO/Value Objects - создание внутри конструктора допустимо
2. Финальные классы-утилиты с приватным конструктором
3. Синглтоны в устаревшем коде (хотя лучше использовать DI-контейнер)
4. Тестовые дублеры могут нарушать правила для целей тестирования

Заключение

Явная передача параметров через конструктор должна быть стандартом в 95% случаев современной PHP-разработки. Это обеспечивает предсказуемость, тестируемость и гибкость кода. Инициализация внутри конструктора допустима только для:

• Простых объектов-значений
• Вспомогательных внутренних компонентов
• Кода, работающего с глобальным состоянием (что само по себе требует пересмотра)

Сочетание явных зависимостей с современным DI-контейнером (Symfony Container, Laravel Service Container, PHP-DI) создаёт основу для поддерживаемой и масштабируемой архитектуры, что критически важно для долгосрочных проектов.