Это может быть не тот ответ, который вы ищете, поэтому держите вопрос открытым, если кто-то другой даст больше ответов на основе 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.
И поскольку этот макрос просто разворачивается в обычный старый код для передачи аргументов, пока ваши аргументы сериализуемы, у вас нет проблем, таких как unserializable Injector
.