Скрыть зависимости класса от конечного пользователя, создавшего его (PHP)

Question

Моя ситуация, по сути, такова: у меня есть класс с именем Foo, который имеет зависимости A и B, все из которых являются внутренними для библиотеки. Экземпляры Foo будут создаваться пользователем библиотеки, и они не должны требовать знания зависимостей.

Внутренне, конечно, я хотел бы, чтобы Foo оставался отделенным от конкретных реализаций A и B. Я рассмотрел простой статический фабричный класс, однако необходимо будет как-то настроить его для зависимостей (скажем, Factory :: $ _ staticAttr = x) и это кажется неправильным, так как это по сути означает, что у моего статического класса есть состояние.

Я также думал о каком-то XML или ином сконфигурированном контейнере для инъекций зависимостей, однако затем возникает вопрос о том, как сделать экземпляр сконфигурированного DIC доступным, не создавая беспорядка, такого как наличие в объекте реестра.

Я стремлюсь к какому-то тривиальному методу для конечного пользователя, чтобы сгенерировать экземпляр Foo со всем введенным, сохраняя при этом все детали зависимостей и т. Д., Скрытые в библиотеке.

Я перечитал, и решение пока не показалось мне очевидным, поэтому я буду признателен за любую информацию:).

Answer 1

Спасибо за ваш ответ.

Ммм, я прочитал вчера эту статью. Моя единственная проблема была:

`Factory::$_database = $ourDatabaseVarForDB1;`

Хотя это и удобно, но мне кажется, что такая реализация выглядит немного хакерской?

Однако он помечает другие поля, поэтому, если нет лучшего случая, он должен быть таким.

Answer 2

Я сам использую контейнер для инъекций зависимости (статическая фабрика) для этих вещей. Вы можете прочитать этот пост: http://www.potstuck.com/2009/01/08/php-dependency-injection/

Я стремлюсь к какому-то тривиальному методу для конечного пользователя, чтобы создать экземпляр Foo со всем впрыскивается, сохраняя при этом все детали зависимостей и пр. скрыты в библиотеке.

В этом случае я бы определенно пошел на фабрику.

UPDATE

Вот для чего статические классы. Они представляют собой определенное состояние, как в этом случае. Вам нужен только один адаптер БД (для каждого приложения | класса | пакета), так что вы можете использовать его снова и снова. Использование global было бы намного более хакерским;)