А, ты про тесты говоришь)) Я грешным делом подумал, что в системе нужно так запускать. Понятно.
Глянул поверхностно, мнда... Логика конечно та еще. Прежде чем переделывать инициализацию, нужно в ней разобраться немного.
Начал я с конфигурации и ничего не понимаю. Вот у тебя какая то конфига:
class Config extends Factory
{
public function get($id, $options = [])
{
$map = [
'local' => \ExampleCMS\Config\Local::class,
'database' => \ExampleCMS\Config\Database::class,
];
return $this->container->get($map[$id]);
}
}
Ну то, что ты тут замутил сервис-локатор, это полбеды. Почему тут захардкожены имена классов? Эти же классы прописаны в карте. А где же инверсия? Тут какая то рекурсия получается. Главная конфига, зарегистрированная в контейнере, запрашивает фабричную конфигу, что бы та выдала
имена классов, что бы по этим именам получить из контейнера(!) объекты этих классов по имени, по которому эти же классы зарегистрированы в контейнере.
Я чуть голову не сломал. И что получается теперь. Что бы заменить класс базы данных нужно заменить его имя в контейнере, а потом искать класс конфиги и менять там? В прогоне то бишь. Так где инверсия то?
Если твой контейнер писался под такую логику, чего удивляться тогда, что с моим реализовать ее сложнее. Там конечно можно упростить то, что ты сделал в этом месте, но это же изврат изначально...
'config' => function () {
$config = new \ExampleCMS\Config();
$configFactory = new \ExampleCMS\Factory\Config;
$configFactory->container = $this;
$config->configFactory = $configFactory;
return $config->get();
},
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.