Вот общий мнимый пример, составленный для этого сообщения. Рассмотрим 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/
В случае, если статья исчезнет в будущем, вот выдержка
«Каждый объект просто знает об объектах, с которыми он непосредственно взаимодействует. Ссылка на объекты отсутствует, чтобы попасть в нужное место, где они нужны».
Итак, что нужно сделать, вместо того, чтобы создавать глубокий вложенный графический объект с передачей зависимостей сверху вниз, идти горизонтально и управлять зависимостями в другом месте.