У меня есть несколько классов, например те, которые описывают структуру таблицы базы данных или те, которые описывают конфигурацию приложения, которые вообще не изменяют состояние во время выполнения программы. В настоящее время у меня есть эти классы как синглтоны, а классы, которые хотят получить информацию, запрашивают экземпляры класса (например, из общего метода getInstance ()), а затем переходят к получению желаемой информации. Хотя это работает, я надеялся обеспечить большую модульность, когда дело доходит до конфигураций, и именно здесь я застрял.
Моя главная цель - упростить отладку с помощью модульной конфигурации, сохранив при этом читаемость кода. Я не уверен, как я позволю обмениваться конфигурациями для отладки без включения еще одного синглтона (tm), из которого классы, использующие параметры конфигурации, могут извлекать правильные экземпляры конфигурации.
Это для веб-приложения PHP, но не помечено как таковое, потому что я предполагаю, что решение, скорее всего, будет независимым от языка.
Редактировать: Чтобы прояснить мой вопрос, даже несмотря на то, что инъекция зависимостей щекочет мое воображение в том, что касается ответов на мой вопрос, позвольте мне привести (возможно, упрощенный) пример.
Скажем, у меня есть оболочка для класса PHP Mysqli, который просто будет использовать любую информацию о подключении, указанную в синглтоне Config ...
class Mysql {
// ...
private $mysqli;
public function __construct() {
$conf = Config::getInstance(); // Get the configuration
$this->mysqli = new Mysqli(
$conf->getHost(),
$conf->getUsername(),
$conf->getPassword()
);
// ...
}
// ...
}
В этом примере класс Mysql будет принимать только те параметры, которые содержатся в Config, и невозможно использовать какую-либо конфигурацию, кроме той, которая содержится в Config. В этом примере может иметь смысл просто передать в конструктор хост / имя пользователя / пароль / что-то еще, но затем он падает на клиента, использующего класс Mysql для извлечения его из синглтона Config, и проблема снова проявляется во многих больше классов. Поскольку в конечном итоге он всегда извлекает зависимости из Config, невозможно легко попробовать другие настройки с этой настройкой.
Из того, что я читал в нескольких местах, включая замечательные комментарии здесь, похоже, что инъекция зависимостей - мой лучший выбор. Для будущих читателей я нашел одну интересную статью о внедрении зависимостей в отношении PHP здесь, а также упрощенное введение в концепцию (в Java) здесь.
Надеюсь, это немного проясняет ситуацию. Приведенный пример немного упрощен, поскольку я мог просто загрузить синглтон Config с другими данными, но в некоторых более сложных обстоятельствах этого решения недостаточно.

Это главный принцип внедрения зависимостей. Идея состоит в том, чтобы внедрить один экземпляр класса во время выполнения. Во время тестирования вы вводите что-то еще с таким же интерфейсом. Это может быть фиктивный класс, фиктивный объект или обычный экземпляр, созданный тестом с ожидаемым состоянием.
У меня проблемы с ответом на ваш вопрос. Можете ли вы проиллюстрировать, что вы подразумеваете под «модульной конфигурацией», желательно на примере?