Комментарий

• Свойства страницы (3 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Название

...	...	@@ -1,1 +1,1 @@
1		-JS Внедрение зависимостей | JS Dependency injection
	1	+Внедрение зависимостей | Dependency injection

Теги

...	...	@@ -1,1 +1,1 @@
1		-DI|js
	1	+DI

Содержимое

...	...	@@ -1,31 +1,0 @@
1		-
2		-**Внедрение зависимостей в JavaScript.**
3		-
4		-Для внедрения зависимостей в JS можно использовать следующую схему.
5		-
6		-1) Создаем класс ServieLocator. В нем будут содержаться все зависимости и метод для получения зависимости.
7		-2) Создаем BaseClass, который:
8		- Содержит статичный экземпляр ServieLocator.
9		- В конструкторе принимает список зависимостей.
10		- При выполнении конструктора запрашивает все необходимые зависимоти и бросате ошибку, если зависимость не найдена.
11		-
12		-
13		-**Вопрос абстракции.**
14		-Нет возможности определить интерфейс.
15		-Как вариант определять класс без логики. Методы могут быть пустими и бросать ошибку: метод не реализован. Потомок либо переопределит метод либо получит ошибку при вызове.
16		-В пустом классе определить статичное поле - имя абстракции, которое будет использоваться для регистрации и разрешения зависимости.
17		-
18		-
19		-**Интеграция с React**
20		-Схожим образом можно интегрироваться с фреймворком типа React:
21		-Создать BaseReactComponent, от которого будут наследоваться все компоненты.
22		-Базовый BaseReactComponent будет создавать экземпляр BaseClass, который выполнит иницилизацию зависимостей, а после полученные зависимости можно скопировать из BaseClass в BaseReactComponent.
23		-При этом BaseReactComponent пробрасывает возможности конструктора BaseClass, позволяя передать массив необходимых зависимостей.
24		-
25		-
26		-
27		-Для создания ServieLocator использовалась библитеока di-xxl. Как показывает практика библиотека не умеет самостоятельно анализировать конструктор (возможно я плохо изучил, но вроде так) и определять необходимые для экземпляра зависимости. Как вариант можно явно прописать список параметров, передаваемых в конструктор, в блоке регистрации зависимости. Но на мой взгляд, более хорошим решением является разрешение зависимостей через ServieLocator в конструкторе базового класса. В таком случае список зависимостей определен в самом классе, а не в блоке регистрации зависимостей.
28		-(Возможно в данном варианте можно обойтись и без библиотеки di-xx. Сделав свое Key-Value хранилище привязок и поддержку singlethon)
29		-
30		-Также хочу отметить важность создания строковых переменных с именами условных интерфейсов (привязок для внедрения). Чтобы в случае переименования интерфейса было достаточно заменить одну строковою переменную. А не искать по коду: где именно внедрялася данный интейс, чтобы изменить имя разрешения зависимости.
31		-