Комментарий

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

Подробности

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

Содержимое

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