АО
Я про jvm мир
А я про то, что у вас там что-то как-то связывается, что-то к чему-то приводится, что-то куда-то подставляется, а это как раз про js - когда всё само, но где что - доподлинно неясно
Size: a a a
2020 July 07
AE
Вот DI через аннотации мне не нравится вообще. Зачастую понять, что откуда прилетело становится мало реально. Ну и инжектить начинают не сервисы, а все подряд
Почему сложно понять что куда прилетело? У тебя есть четко определенный тип, под него находится кандидат, если их несколько - ошибка, уточняй который нужен. Все детерминировано
AN
Почему сложно понять что куда прилетело? У тебя есть четко определенный тип, под него находится кандидат, если их несколько - ошибка, уточняй который нужен. Все детерминировано
Я в качестве примера привожу всегда ядро орхиды. Там черт ногу сломит
АО
А его можно очень по разному делать. God object - это тоже DI
GO или объект с единственной задачей - связать компоненты друг с другом?:) хотя да, я согласен, что это тоже врядли хорошая идея
AE
А я про то, что у вас там что-то как-то связывается, что-то к чему-то приводится, что-то куда-то подставляется, а это как раз про js - когда всё само, но где что - доподлинно неясно
Есть спеки и есть отладчик. Разобраться можно всегда
AE
Я в качестве примера привожу всегда ядро орхиды. Там черт ногу сломит
Я хз что это
АО
Почему сложно понять что куда прилетело? У тебя есть четко определенный тип, под него находится кандидат, если их несколько - ошибка, уточняй который нужен. Все детерминировано
Нет, у вас должен быть интерфейс (на крайний случай - абстрактный класс), а не четкий тип, если уж вы про SOLID заговорили:)
AE
Нет, у вас должен быть интерфейс (на крайний случай - абстрактный класс), а не четкий тип, если уж вы про SOLID заговорили:)
Интерфейс - не тип?
АО
Почему сложно понять что куда прилетело? У тебя есть четко определенный тип, под него находится кандидат, если их несколько - ошибка, уточняй который нужен. Все детерминировано
Ааааа, то есть вы всё-таки руками прописываете
АО
Интерфейс - не тип?
Интерфейс - это набор типов:)
АО
Сам по себе интерфейс может и можно формально назвать типом, но он всё-таки сам по-себе мало о чем скажет
AE
Ааааа, то есть вы всё-таки руками прописываете
Нет. Обычно у интерфейса одна реализация, если их несколько - делается уточнение квалифаерами, либо через профили, если это заменяемые реализации
АО
Почему сложно понять что куда прилетело? У тебя есть четко определенный тип, под него находится кандидат, если их несколько - ошибка, уточняй который нужен. Все детерминировано
В итоге получается что... Вы ставите кучу аннотаций. Если повезет и звезды сойдутся (утрирую, да) - у вас НИ У ОДНОЙ зависимости не будет параллельных реализаций. Иначе - вы пойдете прописывать ручками там, где реализаций больше одной (что и куда инжектить).
AE
В итоге получается что... Вы ставите кучу аннотаций. Если повезет и звезды сойдутся (утрирую, да) - у вас НИ У ОДНОЙ зависимости не будет параллельных реализаций. Иначе - вы пойдете прописывать ручками там, где реализаций больше одной (что и куда инжектить).
Обычно если реализаций несколько, то они разделяются профилями, либо они нужны мне все и я инжектирую их список по интерфейсу
АО
В итоге вы сэкономите один класс/объект/функцию и примерно 1/3 кода, но зато оно будет размазано по всему приложению и в лучшем случае как-то свяжется в компайлтайме
AE
Квалифаеры бывают нужны редко, например в разных частях системы разно специализированные рест клиенты
AN
Квалифаеры бывают нужны редко, например в разных частях системы разно специализированные рест клиенты
Вот это по-моему уже вариант абьюза. Если они могут быть разными, то должны передаваться явно
АО
Квалифаеры бывают нужны редко, например в разных частях системы разно специализированные рест клиенты
Даже если так, мне всё равно пока что не понятно, что вы получаете взамен размазанности инжектов и сложности поддержки (в силу распределенности этого DI)