Делает внедрение зависимости, нарушают закон Demeter
Я решил проблему. Кажется, мне нужно было вызвать компонент где-нибудь в моем файле vue компонента панели инструментов. Поэтому я назвал его `и это позволяет компоненту CommentModal реагировать на отправленные события. Если компонент не вызывается нигде в одноуровневых компонентах, то он не реагирует ни на одно из событий.
Но я хотел бы услышать, есть ли лучшее решение для этого. Мне это кажется немного хакерским.
6 ответов
Внедрение зависимости CAN нарушает закон Demeter. Если Вы вынуждаете потребителей сделать инжекцию зависимостей. Этого можно избежать через статические методы фабрики и платформы DI.
у Вас могут быть оба путем разработки объектов таким способом, которым они требуют, чтобы зависимости были переданы в, и в то же время имея механизм для использования их без явного выполнения инжекции (функции фабрики и платформы DI).
Как это повреждает его? DI отлично помещается в идею наименьшего количества знания. DI дает Вам слабую связь - объекты являются меньшим количеством ответчика друг на друге.
Цитирование Википедия:
... объект A может запросить сервис (назовите метод) экземпляра объекта B, но возражают, что A не может “reach through” возражать B для доступа к еще одному объекту...
Обычно DI работает точно тот же путь, т.е. Вы используете услуги, предоставленные введенными компонентами. Если Ваша объектная попытка получить доступ к некоторым зависимостям B т.е. это знает много о B - это, приводит к высокой связи и повреждает идею DI
Однако, я требую, чтобы объекты выше моя цепочка вызовов имели знание объектов далее вниз цепочка вызовов
Некоторый пример?
Если я понимаю Вас правильно, это не вызывается при помощи внедрения зависимости, оно вызывается при помощи насмешки стратегий, которые сделали, чтобы Вы указали вызовы функции, которые Вы ожидаете, что метод сделает. Это совершенно приемлемо во многих ситуациях, но очевидно который означает, что необходимо знать что-то о методе, который Вы называете, если Вы указали то, что Вы думаете, что он, как предполагается, делает.
Пишущее хорошее программное обеспечение требует балансирующихся компромиссов. Поскольку реализация становится больше завершенным, это становится более непоследовательным. Необходимо решить то, что рискует теми несоответствиями, создают, и стоят ли они стоимости, созданной их присутствием.
это нарушает закон?
Строго говоря, я думаю, что это делает.
это имеет значение?
основная опасность нарушить закон состоит в том, что Вы делаете свой код более хрупким.
, Если Вы действительно сохраняете его только к тестам, кажется, что опасность не слишком плоха.
Смягчение
Мое понимание Закон Demeter - то, что это может сопровождаться при наличии "методов обертки", которые предотвращают непосредственно раскритиковывание в объекты.
Закон Demeter указывает, что метод M объекта O может звонить, методы на объектах создали/инстанцировали в M. Однако нет ничего, что указывает, как эти объекты были созданы. Я думаю, что это прекрасно подходит для использования посреднического объекта создать их, пока цель того объекта в жизни состоит только в том что - создание других объектов от Вашего имени. В этом смысле DI не нарушает закон Demeter.
Зависит: -)
Я думаю, что главный ответ неверен, даже с фреймворком во многих кодах используется внедрение зависимостей и внедряются объекты высокого уровня. Затем вы получаете спагетти-код с множеством зависимостей.
Внедрение зависимостей лучше всего использовать для всего, что может загрязнить вашу объектную модель, например, для ILogger. Если вы вводите бизнес-объект, убедитесь, что он находится на самом низком уровне, и попробуйте передать его традиционным методом, если сможете. Используйте инъекцию зависимостей, только если она становится беспорядочной.