Exactly, you should worry about design, not about one empty class. Otherwise you should stop using a...

# android

[gildor]

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

[rdhruva]

yes, that is absolutely true

[rdhruva]

but it’s about the pattern in general

[rdhruva]

let’s say I have 25 screens in my app, and each screen has a corresponding object ScreenFooLoggingHelper {...}

[rdhruva]

this now means that if a user goes through all my screens, there’s 25 helper objects

[rdhruva]

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

[gildor]

If this is screen related why it should be an object 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

[gildor]

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