В предыдущих публикациях (раз, два) я рассматривал возможности использования внедрения зависимостей в чистом JavaScript (без TypeScript, аннотаций и транспиляции). В данной публикации я продолжаю погружаться в вопросы использования DI в JS и более пристально рассматриваю роль идентификатора зависимости в создании объектов контейнером.

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

Предусловия

Как уже было сказано в предыдущих публикациях, заморачиваться с инверсией контроля (и внедрением зависимостей) есть смысл только в больших проектах, состоящих из большого количества es6-модулей и большого количества npm-пакетов.

В силу исторических причин браузерные приложения собираются при помощи бандлеров, которые трансформируют исходный код (зачастую TypeScript) и которым не в напряг обработать аннотации и разрезолвить зависимости (как это сделано в Angular). Рассматриваемый мной метод внедрения зависимостей работает и в браузерных приложениях, но он явно уступает по скорости загрузки исходных модулей классическому варианту с бандлами. Если для PWA/SPA такой подход ещё можно, с некоторой натяжкой, считать допустимым (с учётом кэширования исходников на стороне браузера), то для обычных веб-страничек это явный перебор. Поэтому сказанное в посте относите, преимущественно, к серверным приложениям (nodejs).

Исходный код nodejs-приложения, как правило, состоит из npm-пакетов, которые состоят из es6-модулей, которые состоят из export'ов. "Кирпичом" ES6+ приложения является отдельный экспорт. Таким образом, идентификатор зависимости должен уметь адресовать отдельный экспорт.

Экспортом может быть класс, функция, объект, примитив. Зависимости от других экспортов могут быть (а могут и не быть) у класса или функции. Если класс или функция имеют зависимости, то они должны передаваться в виде отдельного объекта - "спецификации" (см. "2. Спецификация зависимостей"), где каждое свойство спецификации представляет собой отдельную зависимость:

export function Factory({dep1, dep2, dep3}) {}

dep1, dep2 и dep3 - как раз и являются идентификаторами зависимостей.

Варианты описания зависимостей

Конфигурационный файл

Самым гибким, но не самым удобным способом является создание конфигурационного файла, в котором для каждой зависимости определялся бы метод её создания (XML-файл, например, является традиционным способом в Spring Framework):

<beans>
    <bean id="dep1" package="..." export="...">
        <!-- collaborators and configuration for this bean go here -->
    </bean>
</beans>

Преимуществом этого способа является то, что мы можем определять в очень широком диапазоне правила создания зависимостей контейнером. Вплоть до отказа от спецификации, как единственного параметра конструктора/фабричной функции:

// with specification
export function Factory({dep1, dep2, dep3}) {}

// without specification
export function Factory(dep1, dep2, dep3) {}

Неудобством - то, что этот файл нужно вести отдельно от самого JS-кода.

Аннотации

Я считаю аннотации вторым по гибкости способом описания зависимостей, но аннотации требуют предобработки (компиляции, транспиляции). Для интерпретируемых языков я считаю предобработку излишним шагом, а нативных декораторов в JS пока ещё нет.

Ключ в Спецификации Зависимостей

В JS ключом в объекте (именем свойства объекта) может быть строка:

const spec = {
    logger,
    config: config,
    'Практически any text': dep,
};
Object.keys(spec); // [ 'logger', 'config', 'Практически any text' ]

В варианте 'depId': dep мы можем описывать нужные нам зависимости практически как угодно, хоть на естественном языке (спасибо @TheShock за наводку).

Что нужно для создания зависимости?

Путь к исходникам

Допустим, что у нас совсем простая зависимость:

function Factory({logger}) {}

Если мы создаём нужный нам объект вручную при помощи фабрики, то это выглядит так:

import {logger} from '@vendor/package/src/Logger.js'
const obj = Factory({logger});

Т.е., нам как минимум нужно знать путь к es6-модулю, содержащему исходный код зависимости.

Имя экспорта

Если нужная нам зависимость - это именованный экспорт, то код для импорта выглядит так, как выше. А если зависимость экспортируется по умолчанию, то импорт выглядит так:

import logger from '@vendor/package/src/Logger.js'

Т.е., нам нужно знать имя экспорта внутри es6-модуля (именованный или по умолчанию).

Фабрика

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

export default const Configuration = {...};

В других случаях экспортируется фабричная функция или класс, которые используются для создания зависимости:

// ./config.js
export default {name: 'Demo'}
// ./logger.js
export default function (msg) {}
// ./dep.js
export default function ({config}) { return ...;} // фабричная функция
// ./service.js
export default function ({logger, dep}) {}

// ./main.js
import config from './config.js';
import logger from './logger.js';
import Dep from './dep.js';
import Service from './service.js';

const dep = Dep({config}); // создаём новый объект при помощи фабричной функции
const serv = Service({logger, dep});

Если весь наш проект "инвертирован по зависимостям", то для создания любого объекта, имеющего зависимости, должна использоваться фабричная функция (или конструктор), в которую мы передаём зависимости в виде объекта спецификации (spec). Ну вот такие у нас предусловия. Но иногда в зависимости нужно просто использовать класс, как класс, а не как фабрику для нового объекта:

// ./clazz.js
export default class Clazz {
    constructor() {}
}

// ./main.js
import Clazz from './clazz.js';
import Service from './service.js';

const serv = Service({Clazz}); // класс, а не экземпляр класса!

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

Lifestyle

Некоторые объекты в приложениях нужны в одном экземпляре (singleton), например - конфигурация приложения. Некоторые объекты создаются каждый раз заново (например, контекст какого-либо запроса).

// ./config.js
export default {}
// ./context.js
export default class Context {}
// ./service1.js & ./service2.js
export default function ({config, context}) {}

import config from './config.js';
import Context from './context.js';
import Service1 from './service1.js';
import Service2 from './service2.js';

const serv1 = Service1({config, context: new Context()});
const serv2 = Service2({config, context: new Context()});

Здесь config является "одиночкой", а context создаётся заново для каждого сервиса.

Декораторы

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

Вот сервис, который выполняет некоторую работу:

// ./service.js
export default function (req) { return req + 2;}

Вот диспетчер, который принимает в качестве зависимостей несколько сервисов (в данном случае - один) и перенаправляет запрос на соответствующий сервис:

// ./dispatcher.js
export default function ({service}) {
    return function (req) {
        return service(req);
    };
}

А вот декоратор для сервиса, который логирует входные параметры запроса:

// ./logger.js
export default function (fn) {
    return (...args) => {
        console.log(args);
        return fn(...args);
    };
}

Создание, обёртывание и внедрение зависимости:

import logger from './logger.js';
import service from './service.js';
import Dispatcher from './dispatcher.js';

const wrapped = logger(service);
const disp = Dispatcher({service: wrapped});

Структура идентификатора

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

• путь к es6-модулю с исходным кодом зависимости

• имя соответствующего экспорта внутри es6-модуля

• режим создания зависимости (фабричная функция или as-is)

• lifestyle (одиночка или новый экземпляр)

• используемые декораторы

Я думаю, что можно придумать ещё какие-либо атрибуты, относящиеся к созданию и внедрению зависимости, но я перечислил те, которые использовал в своих проектах я сам.

Примеры идентификаторов

Я напоминаю, что идентификатор зависимости в исходном коде является инструкцией по созданию и внедрению зависимостей в режиме выполнения (в отличие от статического связывания через import).

Nodejs style

Самый прямой способ для идентификации es6-модуля в проекте - это указать путь к нему относительно корня проекта:

node_modules/@vendor/package/src/path/to/mod.js

затем через какой-либо разделитель (например, ":") добавить имя экспорта, режим создания и lifestyle:

node_modules/@vendor/package/src/path/to/mod.js:default:factory:instance

после чего добавить список декораторов:

.../mod.js:default:factory:instance:[logger,timer,validator]

С такими идентификаторами внедрение зависимостей могло бы выглядеть так:

export default function (
    {
        './src/Configuration.js:default:asis:singleton': config,
        'node_modules/@vendor/package/src/Service.js:default:factory:instance:[logger]': service,
    }
) {}

Этот вариант вполне себе рабочий, хотя и слишком многословный.

Кодирование имён пакетов

Аналогичный способ используется в PHP (PSR-4). Каждому npm-пакету ставим в соответствие некоторый уникальный код (namespace) и составляем карту этих соответствий:

const map = {
    '@vendor/package': 'node_modules/@vendor/package/src',
    'app': './src',
};

Также к namespace'у можно привязать расширение, используемое для исходников данного пакета (*.js, *.mjs, *.es6, ...). Использование подобной карты в контейнере объектов (composition root) позволяет сократить идентификаторы до такого вида:

app/Configuration:default:asis:singleton
@vendor/package/Service:default:factory:instance:[logger]

export default

Если предположить, что один es6-модуль отвечает за одну единственную задачу (SOLID), то можно оставлять в модуле один единственный экспорт - default. В таком случае большинство идентификаторов станет короче, а для именованного экспорта придётся ввести дополнительный разделитель (например, "."):

app/Configuration:asis:singleton
@vendor/package/Service:factory:instance:[logger]
app/Utils.formatDate:asis:singleton

Способ создания и lifestyle

Поскольку способ создания (factory или as-is) и lifestyle (singleton или transient|instance) являются бинарными атрибутами, то их также можно использовать по-умолчанию, а второй вариант кодировать каким-либо символом (например, "$" и "@").

Допустим, что большинство экспортов в нашем проекте используются as-is и как одиночки (singleton). В таком случае идентификаторы могли бы выглядеть так:

app/Configuration  // default:asis:singleton
@vendor/package/Service$@:[logger]  // default:factory:instance:...
app/Utils.formatDate  // :asis:singleton

Использование значений по умолчанию делают идентификаторы зависимостей не такими уж страшными:

function Factory(
    {
        'app/Configuration': config,
        '@vendor/package/Service$@:[logger]': service,
        'app/Utils.formatDate': formatDate,
    }
) {}

Имена JS-переменных

Вот теперь пойдёт совсем ненормальное программирование, но я просто развиваю мысль в этом направлении :)

В качестве имени переменной в JS может выступать любой буквенный или цифровой символ, подчёркивание или $. Если заменить разделитель пути "/" подчёркиванием и задать, что по умолчанию используется default-экспорт, режим создания - "as-is" и lifestyle как singleton, а также выкинуть все недопустимые символы из пути к файлу с исходником, то идентификатор может стать валидным именем JS-переменной:

function Factory(
    {
        App_Configuration: config,
        Vendor_Package_Service: service,
    }
) {}

А если теперь использовать допустимый знак "$" и модификаторы после него (режим создания: A - as-is, F - factory, lifestyle: S - singleton, I - instance), то идентификаторы сокращаются до:

function Factory(
    {
        App_Helper_Price$AI: price, // as-is, instance
        Vendor_Package_Web_Service$FS: service, // factory, singleton
    }
) {}

Можно даже вот так:

function Factory(
    {
        App_Helper_Price$FS,
        Vendor_Package_Web_Service$FI,
    }
) {}

Наши идентификаторы зависимостей теперь могут служить и переменными для фабричной функции.

Разумеется, что таким образом можно закодировать только определённые комбинации свойств идентификатора зависимости, а для описания всех возможных свойств придётся использовать полную версию в виде строки с произвольными символами:

function Factory(
    {
        'Vendor_Package_Web_Service$FS[logger]': service,
        'App_Utils.formatDate': formatDate,
    }
) {}

Заключение

Какой бы способ внедрения зависимостей не использовался, чтобы внедрить зависимость в конструктор или фабричную функцию, разработчику (или программе-контейнеру) нужно ответить на следующие вопросы:

• где находится файл с исходным кодом (es6-модуль)

• какой экспорт es6-модуля использовать

• использовать ли экспорт "как есть" или использовать экспорт как фабричную функцию (конструктор) для создания зависимости

• внедрять новую зависимость (instance) или использовать уже имеющуюся (singleton)

• нужно ли декорировать зависимость перед внедрением

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

Зачем я всё это написал? Я просто ищу наиболее удобный для себя способ создавать веб-приложения и считаю, что техника внедрения зависимостей очень сильно помогает как в переиспользовании своего собственного кода, так и в разработке больших приложений различными командами. Критика изложенного со стороны читателей Хабра позволяет провести ревизию подхода, посмотреть на него другими глазами, а зачастую найти и "более лучшие" решения :)

Спасибо, что дочитали.