Ответ 1

Разве не было бы проще или логичнее использовать его таким образом, более похожим на DI, который мы видим чаще, но все же передавая его в конструкторе?

Иллюстрация шаблона в вашем примере на самом деле называется шаблоном локатора службы. Эта модель рассматривается многими как анти-шаблон.

Шаблон локатора обслуживания

преимущества

• "Локатор сервисов" может действовать как простой компоновщик времени выполнения. Это позволяет добавлять код во время выполнения без повторной компиляции приложения, а в некоторых случаях без необходимости его перезапуска.
• Приложения могут оптимизировать себя во время выполнения путем выборочного добавления и удаления элементов из локатора служб. Например, приложение может обнаружить, что у него есть лучшая библиотека для чтения доступных изображений JPG, чем стандартная, и соответствующим образом изменить реестр.
• Большие разделы библиотеки или приложения могут быть полностью разделены. Единственная связь между ними становится реестром.

Недостатки

• Вещи, помещенные в реестр, - это, по сути, черные ящики в отношении остальной части системы. Это затрудняет обнаружение и восстановление из-за их ошибок и может сделать систему в целом менее надежной.
• Реестр должен быть уникальным, что может стать узким местом для одновременных приложений.
• Реестр может быть серьезной уязвимостью безопасности, поскольку он позволяет посторонним вводить код в приложение.
• Реестр скрывает зависимости класса, вызывая ошибки во время выполнения, а не ошибки времени компиляции, когда отсутствуют зависимости.
• Реестр делает код более сложным для поддержания (против использования инъекции зависимостей), потому что становится неясным, когда вы вводите нарушение.
• Реестр делает код более сложным для тестирования, поскольку все тесты должны взаимодействовать с одним и тем же классом локатора глобальных сервисов для установки поддельных зависимостей тестируемого класса. Однако это легко преодолеть, введя классы приложений с помощью одного интерфейса локатора служб.

Внедрение зависимости

(Предпочтительный) шаблон, используемый в настоящее время angular (как и другие рамки).

преимущества

• Инъекционная инъекция позволяет клиенту гибко настраиваться. Исправлено только поведение клиента. Клиент может действовать на все, что поддерживает встроенный интерфейс, который ожидает клиент.
• Включение зависимостей может использоваться для экстернализации деталей конфигурации системы в файлах конфигурации, что позволяет переконфигурировать систему без перекомпиляции. Отдельные конфигурации могут быть записаны для разных ситуаций, требующих разных реализаций компонентов. Это включает, но не ограничивается, тестирование.
• Поскольку инъекция зависимостей не требует каких-либо изменений в поведении кода, ее можно применять к устаревшему коду в качестве рефакторинга. В результате клиенты, которые являются более независимыми, и которые легче изолировать тест изолированно, используя заглушки или макет объектов, которые имитируют другие объекты, которые не тестируются. Эта легкость тестирования часто является первым преимуществом, которое наблюдается при использовании инъекции зависимостей.
• Включение зависимостей позволяет клиенту удалить все знания о конкретной реализации, которые необходимо использовать. Это помогает изолировать клиента от влияния изменений дизайна и дефектов. Это способствует повторному использованию, тестируемости и ремонтопригодности.
• Сокращение кода шаблона в объектах приложения, поскольку вся работа по инициализации или настройке зависимостей обрабатывается компонентом поставщика.
• Инжекционная инъекция допускает параллельное или независимое развитие. Два разработчика могут самостоятельно разрабатывать классы, которые используют друг друга, а только знать интерфейс, через который будут взаимодействовать классы. Плагины часто разрабатываются сторонними магазинами, которые даже не разговаривают с разработчиками, которые создали продукт, который использует плагины.
• Инъекция зависимостей уменьшает связь между классом и его зависимостью.

Недостатки

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

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

Есть также другие подобные вопросы о различиях между этими 2, как этот: Какая разница между шаблонами зависимостей и шаблонами Locator? ,

Ответ 2

Инъекция конструктора - это самый простой и надежный способ внедрения инъекции зависимостей.

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

Каждый другой способ затрудняет понимание того, когда доступны зависимости и доступны ли они. Необходимы дополнительные обратные вызовы жизненного цикла, которые вызываются после ввода зависимостей.

Создание объекта с наследованием довольно сложно, так что классы создаются из внутреннего (суперкласса) out (subclass), так что каждый уровень имеет правильно инициализированное состояние, в котором выполняется несколько предварительных условий, например, что никакой подкласс не получает доступ к члену до того, как конструктор суперкласса isn Не закончено. Typcript (ES6), например, принудительно вызывает super() в конструкторе, если в суперклассе есть не общий конструктор.

Если в подклассе есть конструктор, ему нужно сначала вызвать super() перед использованием "this".

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

Ответ 3

// Non-Angular Example

@Component({})
class FooComponent {
  public appState: AppState;

  constructor(DI: DependencyInjector) {
    this.appState = DI.get('AppState'); 
  }

  ngOnInit() {}
}

Вы можете использовать инжектор в своем конструкторе и вручную ввести то, что вам нужно:

@Component({})
class FooComponent {
  public appState: AppState;

  constructor(private injector: Injector) {
    this.appState = injector.get(AppState); 
  }

  ngOnInit() {}
}

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

Ответ 4

Инъекционная инъекция в AngularJS в высшей степени полезна и ключ к созданию легко проверяемых компонентов. В этой статье объясняется, как работает система впрыска угловой зависимости.

Провайдер ($ обеспечивают) Служба $ services несет ответственность за то, чтобы сообщить Angular, как создавать новые инъекционные вещи; эти вещи называются услугами. Услуги определяются вещами, называемыми провайдерами, и это то, что вы создаете, когда используете $ provision. Определение поставщика осуществляется с помощью метода провайдера в службе $ offer, и вы можете получить услугу $ предоставления, попросив ее ввести в функцию конфигурации приложения. мы можем ввести переменную с именем greeting в любую инъекционную функцию (например, контроллеры, подробнее об этом позже), а Angular вызовет функцию $ get провайдера, чтобы вернуть новый экземпляр службы.