Зависимость Ад – как передать зависимости глубоко глубоко вложенным объектам?

Вот общий мнимый пример, составленный для этого сообщения. Рассмотрим 6 классов

TableFactory, TableData, TableCRUD, TableSchema, DBConnect, Logger. 

TableFactory – это внешний класс, допустим, он содержит объект TableData для таблицы DB.

В этом TableFactory нет вызовов TableSchema или DBConnect или logger . Я стремлюсь к примеру внутренних объектов, которые не нужны во внешней сфере.

TableData – это внутренний выбор и работает с данными, поэтому ему нужны TableCrud , DBConnect и Logger .

TableCrud содержит TableSchema и требует DBConnect и Logger .

DbConnect itseld, чтобы повеселиться, нужен Logger. Мой пример – теперь 3 области.

Мой вопрос довольно прост, если у вас есть объект 3 (или больше) областей, которые не вызываются объектами внешней области, как отправить эти объекты из внешнего в внутренний охват, не нарушая Принцип разделения сегрегации -> TableFactory shouldn Не нужно иметь дело с DBConnect или Logger, необходимыми для внутренних объектов.

Если кто-то уважает основные принципы ООП и стремится к простоте проверки -> у вас будут внешние объекты, нуждающиеся в инъекции 5 объектов, а затем есть методы геттера, которые пропускают объекты, необходимые дальше по цепочке. И внутренние объекты с областью, в свою очередь, требуют инъекции зависимостей их внутренних объектов с 3-кратным областью, а также для геттеров. Это означает, что объекты с внешними областями требуют много зависимостей, а геттеры – просто для их прохождения.

Есть ли альтернатива этой методологии прохождения объектов, что я пропустил по пути? Поделись, пожалуйста! Любые ссылки / комментарии оценены.

Это распространенное заблуждение, что зависимости нужно передавать через графический объект. Чтобы обобщить пример, Мишко Хевери дает в « Чистом кодексе»: не ищите вещей , Дом, которому нужна дверь, не нужно знать о замке в дверях:

 class HouseBuilder { public function buildHouse() { $lock = new Lock; $door = new Door($lock); $house = new House($door); return $house; } } 

Как вы можете видеть, Хаус совершенно не обращает внимания на то, что дверь в нем требует блокировки. Для HouseBuilder требуется создание всех необходимых зависимостей и объединение их друг в друга по мере необходимости. Шиворот навыворот.

Следовательно, в вашем сценарии вы должны определить, какие объекты должны работать над зависимостями (cf Law of Demeter ). Затем ваш строитель должен создать всех соавторов и убедиться, что зависимости введены в соответствующие объекты.

Также см. « Как думать о« новом »операторе в отношении модульного тестирования

Если вы спотыкаетесь на тот же вопрос, проверьте статью Эрви, которая попадает в глаз быков

http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

В случае, если статья исчезнет в будущем, вот выдержка

«Каждый объект просто знает об объектах, с которыми он непосредственно взаимодействует. Ссылка на объекты отсутствует, чтобы попасть в нужное место, где они нужны».

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