Don't know if here is the correct thread to ask, but anyway.... for a new project (which will be 100% kotlin) we (team) are discussing regarding dependency injection framework and which one to use, if any... the more I'm looking into that, the more I don't see any reason to use it, because kotlin supports default parameter (constructor or method). Even looking into the description of Koin or Kodein I don't see any text regarding why, benefit of using DI framework. Can someone with more experience (I never tried any) tell me some benefits of using one please?

Does your team write tests? Because I'm wondering how 🙂

Testability is one but even without that consideration, it is a useful abstaction when you don’t have to worry about initialization. I’ve been using koin on android and it has been dead simple to use and it has improved reasoning about the project tremendously

With #mockk tests can be written with singletons, because you can mock the singleton object. If that's the only reason, there's a way to mock it without needing DI

I prefer doing DI by passing interfaces into constructors. Unfortunately many Android classes don’t follow the dependency inversion principle, which means you need to use concrete classes in lots of places, and factories to construct them and it’s a big mess, so using a DI framework helps.

I don't like doing DI when it's not necessary. Creating an interface that's only implemented by one class and than passing that interface is very redundant, IMO. For all effects, it is the concrete class, but you're pretending it's not, because you're passing the """"interface""""

I find that, even without testing or mocking, DI is still a good pattern, especially when using Multibindings. Being able to register and use multiple implementations of an interface/abstract class from different modules does wonders for keeping the codebase clean and extensible. To that end, Kodein supports multibindings while Koin does not. Unfortunately, it looks like Kodein is having trouble with their docs site right now so I cannot link it to you. However, Guice’s docs can give you an idea of what multibindings are useful for https://github.com/google/guice/wiki/Multibindings

Yes, in the cases that you're using multiple implementations, DI is amazing! But I don't think it's always the pattern to-go

@LeoColman I’m not sure if you have a full understanding of what dependency injection means. It’s completely possible to use DI without interfaces

I’ve yet to learn much about the DI frameworks, but it sometimes seems like a workaround for bad OO design. Instead of making a nice pluggable architecture, DI to the rescue. Instead of using composition (of small interfaces)… etc.

DI doesn’t necessarily require the use of a framework. Frameworks just make it easier and do the boilerplate work for you. It’s definitely good design to inject dependencies rather than creating them inside of a class

@ghedeon Singleton will do the trick if you want to write bad code 😂 . Dependency Injection is a good coding design pattern .If your trying to write clean uncoupled than use DI. If your trying write a jungle code ,than use none Di…

Singleton can be a good pattern and lead to a good organization if you do it right

anything can lead to spaghetti code

@rkeazor I'm all in for DI, Dagger user from the version one. But "good pattern" or DI == good code is just a weak argument. Many people blindly jump in but can't explain why they need Dagger. I can't help but have more respect for those who don't use a framework and understand why they don't need it, then for the bandwagon 😒imple_smile:.

@ghedeon you do know dependence injection is a design pattern not a framework 😊

I don't know if a codebase of singletons is bad. Mainly small code bases, in which you don't need the amount of hassle for DI. One of the main reasons for DI is being able to mock something in a test. If you can mock it in another way, perhaps DI isn't that beneficial

Devs always complain about complexity , but never take there time to learn new things ... People complain about Databinding but have never tried it. Complain about Rx java, "ooo it's too hard" because they never took the time to try it. A dev will tell you "unit test are not useful" but has never written an test in his life. The truth is, everything is complicated until you learn how to use it lol.

I don't think Singleton is a bad coding principle. Kotlin even supports it out of the box

Singletons, and Global State is never a good thing. The reason being is because , it can cause unwanted side effects when tampered with. And it can also couple your code together.. . Gl

you know that you create tons of singletons in Dagger, right? The annotation is called

@Singleton

, lol. Don't fool yourself, that you don't have them. Injection instead of hidden usage makes the difference, not the singleton itself. Yeah.. global state is awful... now, tell that to redux guys 🙂. The point is, apparently it's not black and white, as long as you know what are you doing.

@ghedeon Redux follows a different design theory and usecase. Redux creates a store if immutable states.... have you ever seen the source behind the @Singleton lol? Or how it actually works? I mean for each his own... if you would rather work in a code base that has a hugh singleton than feel free