Short article for a Kotlin trick that I found useful: https://proandroiddev.com/interface-singleton-in-kotlin-4c14d862cd67

As a general rule, singletons go against the principle of dependency injection,

I don’t understand that. Singletons are perfect candidates for DI. What does it mean that they “go against the principle of DI”?

I see your point, my phrasing is indeed wrong. I meant that accessing singleton instances directly went against dependency injection. But of course you’re right, singletons themselves aren’t an issue at all.

Mmh... I still don't follow. Why is it against DI to access singletons? What does that mean?

If I call a method on a singleton instance and obtain it directly, typically using

SingletonClass.getInstance()

, then I have a dependency on that singleton class, but I’m not injecting it

If you inject a Singleton, you also have a dependency on it.

Not if a singleton implements a interface

If your class is being injected with the singleton instance, it doesn’t know that it’s a singleton, and depend on that fact.

I think the misunderstanding here is between Singleton (pattern, capital ‘S’) and singleton as in creation mode. Singleton is harmful for DI like Martin specified, when you construct or obtain the instance inside your class. A singleton object , existing only in one instance, isn’t harmful at all when passed as a dependency of the class through a constructor. Notice that singleton =/=> Singleton, that is having only one instance doesn’t imply that class has to follow the Singleton pattern. (in fact that’s what Spring does to your `@Component`s: take care of creating one and only one instance for you)

I still don't see why "Singleton is harmful for DI"

@Martin Devillers advocates for inversion of control, where the caller/user provides all dependencies (push) instead of the callee figuring out where the dependencies are (pull). The fact that the dependency is a singleton or not is, when using inversion of control, not important to the callee.

so,

Singleton.getInstance()

- bad, breaks DI singleton as constructor param - good, testable

Yes, that's more like it. There's nothing intrinsically wrong about singletons in general, they are not just very useful, they are often unavoidable. What's wrong is certain implementations of singletons, such as

static

.

yes absolutely, but only when

Singleton.getInstance()

is called inside the class — same applies for a regular object instantiation: that penalizes IoC and testability

I know that article and fundamentally disagrees with parts of it :)

feel free

I think that the term ‘liars’ is not correct, a bit too harsh. But Singletons can be scattered around your codebase and you’d need knowledge of a class’ implementation to see which singletons/dependencies are needed. In general, using inversion of control and providing the dependencies explicitly in the constructor of a class or in a method of a class, makes clear what is needed and what is not needed. If inversion of control is well done, the signature of a class-constructor and the signatures of its methods are a complete description of what the class needs (for dependencies) to function well (no need to look at its implementation and hunt for dependencies providers)

IMHO, the obvious answer to "XXX breaks DI" is not "Dont Use XXX" but rather "Dont use DI" -- A non-scientific off-the-cuff assessment of comparing "Things that don't work well with DI" vs "Things that work well except with DI" leads me to the generalization that its DI thats the problem. In fact one reason for my personal conversion to Kotlin was that built into kotlin are features that address, or enable coding such such that DI isn't (or isn't as much) needed in the first place. So when I read a comment/blog/article about "XXX is BAD because it breaks DI" -- my take is thats one more reason Im glad to be using Kotlin for as many projects as I can -- there are so fewer compelling reasons to have to adopt either DI or the frameworks that require it as a dependency. Frameworks such as Spring which arose over the years as a way to manage the complexities of writing serious code in Java -- Remove the original problems and the resulting solution is no longer that compelling.