2017-01-20 1 views
0

Я работаю с очень большой базой кода с сотнями разных классов. Сначала у нас был главный Application.php, где мы как бы загрузили наш services. Значение сказать, что это, где мы подключили зависимости в Афоризм так же на что-то вроде этого:Как предотвратить появление «нового» экземпляра по всему месту в большой кодовой базе?

public function loadConfig(ConfigLocatorInterface $config) 
{ 
    $this->config = new Config($config); 
} 

т.д. Вы, вероятно, получить идею, Есть несколько таких случаев, которые могли бы даже взять 2 или более зависимостей или объекты, которые уже имеют зависимости.

Попутно это получает непригодным для использования, потому что вы постоянно должны передать эти serviceproviders вокруг других объектов, к контроллеру, к вашему connectionpool и т.д.

Это является причиной моих коллег разработчики начали инстанцировании объекты в классах сами, вместо того, чтобы передавать их по цепочке, создавая плотную связь. Даже newing объекты внутри конструкторов, что делает практически невозможным unit test эти фрагменты кода.

Передача этих зависимостей постоянно может быть не решением в этом случае, так как у многих конструкторов уже есть 3 аргумента. И если бы мы это сделали, нам пришлось бы создавать куски предварительно сконфигурированных объектов, что не всегда возможно.

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

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

+0

Это самая необычная причина в отношении контейнеров, которые я когда-либо слышал. –

+0

@ AlexBlex заботиться о разработке? Конечно, мы будем подавлять сообщения об ошибках в производстве, но люди все еще боятся утечки данных, если что-то ломается, потому что мы передаем объект конфигурации с нашими учетными данными и т. Д. В нем. Или вы имеете в виду, что контейнер становится раздутым? Мне бы хотелось, чтобы некоторые статьи или другая информация убеждали моих коллег. –

+0

Нет ничего сложного. Различные реализации контейнеров страдают от циклических зависимостей, медленной проводки на основе отражения и т. Д., Которые могут быть разблокирующими в крайних случаях. Отклонение контейнеров из-за соображений безопасности или риск иметь объект-бог довольно необычно и звучит скорее как неправильное использование. Он может заслужить свой собственный вопрос с примерами таких проблем в выбранном контейнере. –

ответ

-1

Вы ищете шаблон для одноэлементного дизайна. Пожалуйста, проверьте следующий пример здесь в stackoverflow: https://stackoverflow.com/a/203359/3130183

+0

Это своего рода близорукий ответ. Даже с шаблоном singleton вы можете легко столкнуться с проблемой. Особенно, если вы хотите передать динамическую конфигурацию вместе с вашими объектами и постоянно кэшировать экземпляр. –

Смежные вопросы