Comments 6
Как ни странно было интересно прочитать, но есть что сказать и что дополнить.
Созданный компонент не является DI контейнером, т.к. нет "основной" фишки, а именно автоматизированного предоставление требуемых зависисмостей при создании объекта.
Полученный контейнер это скорее Service Locator с возможностью создавать компоненты по требованию.
Что бы доработать ваш код, надо научиться принимать на вход фабрики с параметрами и автоматически передавать эти параметры при создании экземпляра объекта.
А теперь по самому коду:
1) доступ к словарю где хранятся данные контейнера должен быть закрыт иначе, любой внешний код, сможет без труда делать с содержимым контейнера, что ему захочется.
2) Я понимаю зачем используются inline функции, но есть побочный эффект, их код будет размазан по всему приложению в местах вызова функций. Исправить просто, вся работа происходит в функции на вход которой в явном виде приходят параметры с информацией о типах т.е. fun <T:Any> create(type: KClass<T>, factory: Factory<T>). И эта функция не будет инлайн. А инлайн обертка будет просто получать информацию о типах в месте вызова и перехавать вызов в основную функцию.
DI контейнер это всего лишь мешок с фабриками, не более, автоматизация это уже другой аспект, либо она может быть либо нет (если честно для рядовых задач в Dagger нужно гораздо больше действий сделать, чем в моём DI решении), если нужны дополнительные параметры для фабрик или ещё что-то всегда можно это добавить, только если это действительно нужно в вашем проекте
1) это чтобы inline работал, можно сделать публичным неизменяемый вариант коллекции + норм доку написать и все дела
2) вообще фигня, в Kotlin полно inline функций, начиная с Android расширений и заканчивая коллекциями, не вижу в этом проблемы, чтобы на неё вообще обращать внимание, да и вообще Dagger генерит в 3 раза больше шаблонного кода, а Hilt в 6-10, так что сомнительно, но окэй
Не понимаю, зачем тебе тут мапа с объектами. Зачем так усложнять себе жизнь? Почему бы просто не использовать проперти твоего модуля
Хорошая статья, было интересно почитать. Я бы еще обозначил пару важных моментов:
1. В реализации функции `Di.instance()` было бы неплохо бросать более понятную ошибку, что класс такой-то не зарегистрирован в графе. Ну и в случае миграции ключей зависимостей с простых `KClass` на составные (по типу как в Koin), может появиться еще одна ошибка о том, что возвращаемый тип не совпадает;
2. Стоит отметить, что c `Map`-ой фабрик не получится сделать проверку графа зависимостей во время компиляции и есть риск упасть в рантайме с такой реализацией DI.
Пишем простенький DI для Android приложения