We are bitten by piece removing all singletons from our project in support of lightweight, task scoped targets which can easily be re-made when you need them.
Want to learn Salesforce from scratch? Here's is the right video for you on Salesforce provided by Intellipaat
Singletons are a bummer for testing and, if slowly initialized, will present "state indeterminism" with indirect side effects (which may abruptly surface when transferring calls to getInstance() from one field to another). Clarity has been mentioned as another obstacle, and since singletons indicate "global" (= random) access to accorded state, subtle bugs may appear when not correctly synchronized in parallel applications.
I think it an anti-pattern, it's a bad object-oriented way that typically amounts to managing global state.
To get following to your question:
Although the app context can be held a singleton itself, it is framework-managed and has a well-defined life-cycle, scope, and passage path. Hence I understand that if you do require to maintain an app-global state, it should go here, nowhere else. For anything different, rethink if you actually need a singleton object, or if it would also be likely to rework your singleton class to rather instantiate small, short-lived objects that accomplish the task at fingers.
Back