Exactly, you should worry about design, not about ...
# android
Exactly, you should worry about design, not about one empty class. Otherwise you should stop using any Lists and especially Maps It is not “a huge overhead” it no practical overhead at all. On your app initialisation even before any UI you create hundreds and thousands classes with state (not just empty, like in you case). Overhead is so small that no reason to worry about it in such case. Spend your time to solve real problems and do real optimisation rather than worry about one global object
yes, that is absolutely true
but it’s about the pattern in general
let’s say I have 25 screens in my app, and each screen has a corresponding
object ScreenFooLoggingHelper {...}
this now means that if a user goes through all my screens, there’s 25 helper objects
which are singletons and stick around forever, even though it’s likely that user isn’t going to back to some of the screens again
If this is screen related why it should be an
instead if just member function of your screen or one of your classes. You probably also don't want to expose those screen specific methods
I just don't see good usecases for such
screen specific singleton
except builder functions As I remember in your original question you mentioned that you want to use it for logging, doesn't look like something screen specific