Возможно, это не тот ответ, который вы ищете, поэтому оставьте вопрос открытым на случай, если кто-то еще предоставит больше ответов на основе Guice.
В основном причина, по которой мы используем DI-фреймворки/библиотеки, связана с накладными расходами на передачу аргументов вручную и, возможно, также с развязкой реализации интерфейса (хотя последнее можно просто решить, передав функции в конструкторах и используя их для создания реализации, так что это не так). такой уж спор).
В Scala, по крайней мере, в кодовых базах, которые уходят от Java для более простых проектов, люди просто передают вещи в качестве аргументов:
class MyActor(name: String, surname: String) extends Actor { ... }
def createActor(name: String, surname: String) =
system.actorOf(Props(MyActor.class, name, surname))
У людей, которые не любят делать что-то вручную, есть некоторые другие варианты, но большинство из них основаны на отражении времени компиляции, например. Macwire, который использует типы для внедрения:
// tags used to distinguish things - something like named instance in Guice
// but on types instead of strings
sealed trait Name
sealed trait Name
class MyActor(name: String @@ Name,
surname: String @@ Surname) extends Actor { ... }
def createActor(name: String @@ Name, surname: String @@ Surname) =
// wire is a macro that puts arguments into constructor by looking at
// variables in the current scope and their types
system.actorOf(Props(wire[MyActor]))
Поскольку здесь ошибки связывания появляются во время компиляции, а не во время выполнения, многие люди считают, что это легче поддерживать, чем решения, предлагаемые экосистемой Java.
И поскольку этот макрос просто разворачивается в простой старый код передачи аргументов, пока ваши аргументы сериализуемы, у вас нет проблем, таких как несериализуемость Injector.
person
Mateusz Kubuszok
schedule
29.04.2019
