Редактировал(а) Alexandr Fokin 2023/01/06 17:11

<
От версии < 10.1 >
отредактировано Alexandr Fokin
на 2020/07/14 20:39
К версии < 4.2 >
отредактировано Alexandr Fokin
на 2020/07/14 10:02
>
Изменить комментарий: Добавлен тег [js]

Комментарий

Подробности

Свойства страницы
Содержимое
... ... @@ -5,18 +5,17 @@
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**
20 20  Схожим образом можно интегрироваться с фреймворком типа React:
21 21  Создать BaseReactComponent, от которого будут наследоваться все компоненты.
22 22  Базовый BaseReactComponent будет создавать экземпляр BaseClass, который выполнит иницилизацию зависимостей, а после полученные зависимости можно скопировать из BaseClass в BaseReactComponent.
... ... @@ -24,12 +24,4 @@
24 24  
25 25  
26 26  
27 -Для создания ServieLocator использовалась библитеока di-xxl. Как показывает практика библиотека не умеет самостоятельно анализировать конструктор (возможно я плохо изучил, но вроде так) и определять необходимые для экземпляра зависимости. Как вариант можно явно прописать список параметров, передаваемых в конструктор, в блоке регистрации зависимости. Но на мой взгляд, более хорошим решением является разрешение зависимостей через ServieLocator в конструкторе базового класса. В таком случае список зависимостей определен в самом классе, а не в блоке регистрации зависимостей.
28 -(Возможно в данном варианте можно обойтись и без библиотеки di-xx. Сделав свое Key-Value хранилище привязок и поддержку singlethon)
29 29  
30 -Также хочу отметить важность создания строковых переменных с именами условных интерфейсов (привязок для внедрения). Чтобы в случае переименования интерфейса было достаточно заменить одну строковою переменную. А не искать по коду: где именно внедрялася данный интейс, чтобы изменить имя разрешения зависимости.
31 -
32 -Ссылки
33 -https://git.denhome.ru/Repository/Detail/d718758f-a0fd-4a64-a5c0-2ac48c5e7695
34 -
35 -