# android


12/11/2017, 11:23 AM
This message was deleted.


12/11/2017, 11:24 AM
Just expose interface for client code, and keep private implementation
Or at least private constructor, but interface is better
You can have even anonymous implementation in your app, if you really worry about multiple instances
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
Of course, you can implement it this way, it's simplest way to use it, but also least testable and flexible
Also, in most of cases you actually don't need singleton
1. Yes, I mean client must pass context each time, but object already initialized.
2. What do you mean?
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
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
Also, singleton with context in constructor force client to be coupled with Android Framework and app context