Question about injection

[rmaes4]

I'm a bit confused as to how this injection works. (Bear with me, this is a new concept for me). So say I create my context object in the main part of the application and then register some classes with it. If I want to access said variables from another class do I need to pass this context object via the constructor? Doesn't this defeat the whole purpose? I'm sure there is a better way. If someone could provide an example a bit more conducive to a game scenario I would really appreciate it.

[czyzby]

No, the goal is to keep all the initiation complexity in one place and simplify the process. If you want to create objects with DI at runtime, pass the providers (functional objects) to the appropriate constructors.

I know that some of the examples in the README pass the Context around, but this is just an example of its API usage. Normally you'd want to avoid using Context directly other than for the initialization phase.

Let me give you an example:

/** Does a thing. Requires [B] to work. */
class A(val b: B) {
  fun work() {
    b.work()
  }
}

/** A singleton service. */
class B {
  fun work() {
    println("B!")
  }
}

We've got an A class that requires a B instance to work. Let's suppose we want to create a C service that requires a new A instance on its every work method call. This is how it could look without ktx-inject:

class C(val b: B) {
  fun work() {
    val a = A(b)
    a.work()
  }
}

fun main(args: Array<String>) {
  val b = B()
  val c = C(b)
  c.work()
}

It might not seem that bad, and it does work as expected - but take a look at the C class again. Its API says (thanks to the constructor) that it depends on B, but actually it just uses A API and needs B to initiate it. B becomes a sort of false dependency, since it's not used directly - it's a dependency of A rather than C. Problems start when you try to refactor A. Let's say we want A to use another singleton service - D.

class D(val b: B) {
  fun work() {
    b.work()
    println("D!")
  }
}

Refactored A:

-/** Does a thing. Requires [B] to work. */
+/** Does a thing. Requires [B] and [D] to work. */
-class A(val b: B) {
+class A(val b: B, val d: D) {
  fun work() {
    b.work()
+   d.work()
  }
}

Now C fails to compile, even though its functionality hasn't really changed - it still just delegates work to an A instance. We have add yet another dependency to C to initiate A instances: D.

-class C(val b: B) {
+class C(val b: B, val d: D) {
  fun work() {
-   val a = A(b)
+   val a = A(b, d)
    a.work()
  }
}

fun main(args: Array<String>) {
  val b = B()
+ val d = D(b)
- val c = C(b)
+ val c = C(b, d)
  c.work()
}

So - not only do you need to change the initiation code, but also internal C logic, even though it really just comes down to a.work(). As you can imagine, it gets worse.

Of course, you might have solved that differently even without DI, but I'd say ktx-inject encourages you to design better APIs - and makes it easier. Now, let's go back to just A, B and C, and redesign the C API by saying that it needs a provider of A, so it can get an instance from time to time:

class C(val aProvider: () -> A) {
  fun work() {
    val a = aProvider()
    a.work()
  }
}

fun main(args: Array<String>) {
  val context = Context().register {
    bindSingleton(B())
    bind { A(inject()) }
    bindSingleton(C(provider()))
  }

  val c = context.inject<C>()
  c.work()
}

The initiation code got a bit longer, but now you don't need local variables - you just use Context's inject() and provider() to handle it for you. Now let's say you made the same changes: added D as a dependency of A. This is how it would affect your code:

class C(val aProvider: () -> A) {
  fun work() {
    val a = aProvider()
    a.work()
  }
}

fun main(args: Array<String>) {
  val context = Context().register {
    bindSingleton(B())
+   bindSingleton(D(inject()))
-   bind { A(inject()) }
+   bind { A(inject(), inject()) }
    bindSingleton(C(provider()))
  }

  val c = context.inject<C>()
  c.work()
}

You only have to say how to initiate D and modify how As are made. Note that there are no changes to C itself, as its contract with the other classes has not changed: it still uses A, and does not really care how it is constructed or what it uses internally - as it should be.

Does this clear things up a bit?

[rmaes4]

All of the letters are a bit hard to follow but I think I understand the gist of it.

[czyzby]

TL;DR: with ktx-inject you keep initiation code in one place and can focus on how the components interact with each other. You can refactor internal logic of other components and change their dependencies without breaking other classes, as long as all new components are initiated within the Context.