Return to Answer

The more a class knows about (statically) the less the world can change around it without breaking it. If you want to be pragmatic the next thing to ask is what is likely to change? Is it likely to change when I can't change this class? If we're talking about math.abs() that's not likely to change.

When a class calls a static method it's insisting that the static class must exist and still does whatever it needs. When a class calls a method on an object that it didn't build it doesn't even know what implementation it's calling. That means the change can be managed outside the class. Just pass the class whatever the correct implementation is now. That's dependency injection. You don't need a container to do it.

Be sure you really need this flexibility before you get too invested in a container. While there is a lot of power here there is also enough rope to hang yourself.

Minimize what a class knows about to protect it from likely change. For things that likely wont change, protect the class from over engineering.

DI without a container, that is Pure DI is more complex than using static methods. But container based DI is complex enough that it becomes something you have to mention when advertising the job working with this code. It's no longer a Kotlin programming job. It's a Kotlin + Hilt programming job. Be sure you're getting enough out of it to justify that.

The more a class knows about (statically) the less the world can change around it without breaking it. If you want to be pragmatic the next thing to ask is what is likely to change? Is it likely to change when I can't change this class? If we're talking about math.abs() that's not likely to change.

When a class calls a static method it's insisting that the static class must exist and still does whatever it needs. When a class calls a method on an object that it didn't build it doesn't even know what implementation it's calling. That means the change can be managed outside the class. Just pass the class whatever the correct implementation is now. That's dependency injection. You don't need a container to do it.

Be sure you really need this flexibility before you get too invested in a container. While there is a lot of power here there is also enough rope to hang yourself.

Minimize what a class knows about to protect it from likely change. For things that likely wont change, protect the class from over engineering.

DI without a container, that is Pure DI, is more complex than using static methods. But container based DI is complex enough that it becomes something you have to mention when advertising the job working with this code. It's no longer a Kotlin programming job. It's a Kotlin + Hilt programming job. Be sure you're getting enough out of it to justify that.

The more a class knows about (statically) the less the world can change around it without breaking it. If you want to be pragmatic the next thing to ask is what is likely to change? Is it likely to change when I can't change this class? If we're talking about math.abs() that's not likely to change.

When a class calls a static method it's insisting that the static class must exist and still does whatever it needs. When a class calls a method on an object that it didn't build it doesn't even know what implementation it's calling. That means the change can be managed outside the class. Just pass the class whatever the correct implementation is now. That's dependency injection. You don't need a container to do it.

Be sure you really need this flexibility before you get too invested in a container. While there is a lot of power here there is also enough rope to hang yourself.

Minimize what a class knows about to protect it from likely change. For things that likely wont change, protect the class from over engineering.

DI without a container, that is Pure DI is more complex than using static methods. But container based DI is complex enough that it becomes something you have to mention when advertising the job working with this code. Be sure you're getting enough out of it to justify that.

The more a class knows about (statically) the less the world can change around it without breaking it. If you want to be pragmatic the next thing to ask is what is likely to change? Is it likely to change when I can't change this class? If we're talking about math.abs() that's not likely to change.

When a class calls a static method it's insisting that the static class must exist and still does whatever it needs. When a class calls a method on an object that it didn't build it doesn't even know what implementation it's calling. That means the change can be managed outside the class. Just pass the class whatever the correct implementation is now. That's dependency injection. You don't need a container to do it.

Be sure you really need this flexibility before you get too invested in a container. While there is a lot of power here there is also enough rope to hang yourself.

Minimize what a class knows about to protect it from likely change. For things that likely wont change, protect the class from over engineering.

DI without a container, that is Pure DI is more complex than using static methods. But container based DI is complex enough that it becomes something you have to mention when advertising the job working with this code. It's no longer a Kotlin programming job. It's a Kotlin + Hilt programming job. Be sure you're getting enough out of it to justify that.

The more a class knows about (statically) the less the world can change around it without breaking it. If you want to be pragmatic the next thing to ask is what is likely to change? Is it likely to change when I can't change this class? If we're talking about math.abs() that's not likely to change.

When a class calls a static method it's insisting that it must exist and still does whatever it needs. When a class calls a method on an object that it didn't build it doesn't even know what implementation it's calling. That means the change can be managed outside the class. Just pass the class whatever the correct implementation is now. That's dependency injection. You don't need a container to do it.

Be sure you really need this flexibility before you get too invested in a container. While there is a lot of power here there is also enough rope to hang yourself.

Minimize what a class knows about to protect it from likely change. For things that likely wont change, protect the class from over engineering.

DI without a container, that is Pure DI is more complex than using static methods. But container based DI is complex enough that it becomes something you have to mention when advertising the job working with this code. Be sure you're getting enough out of it to justify that.

The more a class knows about (statically) the less the world can change around it without breaking it. If you want to be pragmatic the next thing to ask is what is likely to change? Is it likely to change when I can't change this class? If we're talking about math.abs() that's not likely to change.

When a class calls a static method it's insisting that the static class must exist and still does whatever it needs. When a class calls a method on an object that it didn't build it doesn't even know what implementation it's calling. That means the change can be managed outside the class. Just pass the class whatever the correct implementation is now. That's dependency injection. You don't need a container to do it.

Be sure you really need this flexibility before you get too invested in a container. While there is a lot of power here there is also enough rope to hang yourself.

Minimize what a class knows about to protect it from likely change. For things that likely wont change, protect the class from over engineering.

DI without a container, that is Pure DI is more complex than using static methods. But container based DI is complex enough that it becomes something you have to mention when advertising the job working with this code. Be sure you're getting enough out of it to justify that.