Нормально ли внедрять объект конфигурации как зависимость в класс?

Question

[Александр]

Вопрос никак не связан непосредственно с PHP, просто приведу примеры на нем.
Предположим, что у нас есть некий объект конфигурации (синглтон), который содержит в себе все настройки нашего приложения:

$config = Config::getInstance();
$timezone = $config->get('timezone'); // получить настройку часового пояса

Также, есть класс-сервис, который имеет некие зависимости, которые берутся из конфигурации:

class MyService
{
    /**
     * @var string
     */
    private $timezone;

    /**
     * @var string
     */
    private $language;
}

Данный сервис будет создаваться с помощью DI-контейнера и будет существовать в единственном экземпляре (будет синглтоном). Есть два варианта инициализации свойств сервиса:
1. Мы передаем в конструктор класса весь объект конфигурации и получаем нужные свойства внутри конструктора:

public function __construct(Config $config)
{
    $this->timezone = $config->get('timezone');
    $this->language = $config->get('language');
}

2. Мы передаем в конструктор класса уже готовые значения параметров, предварительно получив их из конфигурации на уровне настроек DI-контейнера:

public function __construct($timezone, $language)
{
    $this->timezone = $timezone;
    $this->language = $language;
}

// И, где-нибудь в boot.php:
$di->setSingleton('my-service', function () {
    $config = Config::getInstance();
    $timezone = $config->get('timezone');
    $language = $config->get('language');

    return new MyService($timezone, $language);
});

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

Answer 1

[Михаил]

Тут все просто, если классу MyService нужны все! данные из класса Config, тогда передавайте в параметры Config.
Если же ему нужна будет только часть данных из Config, тогда передавайте параметрами отдельно, а если их много, создавайте другой конфиг, который сделан специально для данного класса, типа "MyServiceInitalParams".
Если вы будете передавать классу то, что он не использует, это значительно затруднит написание unit тестов и в целом чтение кода. Увеличит его связность.

Comments

[Александр]

Подскажите, а что именно при передаче полного конфига затруднит написание unit-тестов и чтение кода? В unit-тестах я очень легко могу мокнуть Config, оставив там только нужные параметры.

[Михаил]

Александр:
А если в конфиге не только текст, а какие нибудь сложные для создания данные хранятся?
При чтении, у стороннего разработчика может вызвать недоумение, зачем классу которому нужны 2 поля передали объект из 20 полей, в одном из которых вообще файловый поток хранится (например).

[Михаил]

Александр: По сути, при передаче такого неоднозначного объекта, у класса будет не специфицированный контракт. Тестировать придётся комбинации всех значений в Config, а не только эти 2, хоть вы и знаете сами, что тут 2 поля используется, другие разработчики без чтения документации этого могут не знать.

[Александр]

Михаил: Вот, это уже более реальные аргументы.