This message was deleted.

# android

[Slackbot]

This message was deleted.

[gildor]

Just expose interface for client code, and keep private implementation

[gildor]

Or at least private constructor, but interface is better

[gildor]

You can have even anonymous implementation in your app, if you really worry about multiple instances

[gildor]

Interfaces improve testability and decoupling and it's just one interface, not a big deal. Because it's bad practice:
1. Anti-pattern with bad API (you pass useless context each time when call getInstance)
2. Allow to any code to access this particular implementation, so code become non-testable and coupled to particular implementation

[gildor]

Of course, you can implement it this way, it's simplest way to use it, but also least testable and flexible

[gildor]

Also, in most of cases you actually don't need singleton

[gildor]

1. Yes, I mean client must pass context each time, but object already initialized.

[gildor]

2. What do you mean?

[gildor]

In case of DI client code received implementation to constructor, so client know nothing about implementation, but in case of singleton client just get instance inside of code, so you cannot easily replace implementation for flexibility or testing

[gildor]

To test singleton in unit tests you should mock static field that already smells a lot

Yes, exactly, most common case where you want to provide another implementation is mocked/test implementation for unit tests.

I don't say that singleton is bad itself, sometimes it's useful, but singleton can easily make your code hard to test and don't push you to improve architecture

[gildor]

Also, singleton with context in constructor force client to be coupled with Android Framework and app context