Putting lipstick on a pig. That's so interesting that i had to create a new answer:
So it means that, for logging...
- You can't create sepatate singletons for each logging target, eg logError()->write, logWarning()->write, etc (???)
- You can't select log type when getting singleton log(TYPE)->write (???)
- You can't just create another instance of class, when needed (you can have same class using singleton for "global" logging and then yo can create an instance for something specific) (???)
So what is, in your opinion better than using singletons in this case?
- Maybe passing log class instance to every function in every class object
- Maybe just creating the log class on demand, and it'll mean that you'll have to open lock / close the file as many times as you have rows (very optimal:)
- Static class... same problem. Performance will suck...
- Global functions (nice mess)
- Global objects (nice mess again)
Singletons are good design practice because you can always modify global object somewhere, or someone else can just overwrite it. Not possible with singleton pattern.
Bad feedback? From uneducated developers? :) Ok, let's say that if you abuse any pattern you'd find it sucks, so we should conclude that every design pattern sucks because it could be abused. And mySQL have bad press over mongoDB, too :) You know the word "press" it's the key. Press is just looking for sensations and journalists really don't know what they talk about.
Math functions, anyone? Math.max()... nice idea to not create an object each time you want to do some simple math op, right? :)
Static class - you use it when you don't need to preserve state or resources between function calls (eg. do math functions, each on is unrelated to previous and doesn't require system resources). For eg. logging you use singletons, because you'd want to keep FileSystem Object Handle to not open/close it over and over again.