Alternatives to Singleton when global access is wanted

Question

I have spent the last couple of hours reading about the singleton pattern and why not to use it, amongst others those really good sites:

• Singleton I love you, but you're bringing me down
• How to Think About the "new" Operator with Respect to Unit Testing
• Where have all the Singletons Gone?

I guess quite a lot of you know these already.

Looking at my code after reading that, I clearly am one of the maybe 95% of programmers that misunderstood and misused the singleton pattern.
For some cases, I can clearly remove the pattern, but there are cases where I am unsure what to do:

I know singletons for logging are accepted, one reason for that being that information only flows into them but not back into the application (just into the log file or console etc of course).

What about other classes which do not meet that criteria but are required by a lot of classes?

For example, I have a settings object which is required by a lot of classes. By a lot, I mean more than 200.

I have read into some other SO questions like "Singletons: good design or a crutch?", and all of them pointed out why using singletons is discouraged.
I understand the reasons for that, but I still have one major question:

How do I design a class which needs a single instance, accessible from everywhere, if not using the Singleton pattern?

The options I can think of would be:

1. Use a static class instead (though I don't see how this would be any better, looking at OOP and unit testing).
2. Have it created in an ApplicationFactory and perform dependency injection on every single class that needs it (keep in mind it's 200+ for some cases).
3. Use a singleton anyway, as the global access bonus outweighs the disadvantages for that case.
4. Something completely different.

Answer 1

Isn't this already discussed extensively and exhaustingly?

There is no misuse of the pattern. If your software works as expected (inlcuding maintainability and testablility) you are right with singletons.

The thing about people complain is that the singleton pattern has more impact than only restrict a class to have a single instance.

• you introduce a global variable
• you cannot build a subclass
• you cannot reset the instance

If all this is not a problem for you: Use singletons all over the place. The pattern discussion is academic and hairsplitting.

And - to answer your question - checkout the monostate vs singleton thread: Monostate vs. Singleton

Answer 2

It will depend on exactly what you mean by a settings object.

Do all 200 classes need all the settings; if not why do they have access to the unused settings? Where do the settings come from and is there a good reason why each class can't load its settings as and when required?

Most importantly though, don't make changes to working code just because the code uses a pattern which is frowned upon. I've only used the singleton pattern once but I'd use it again.

EDIT: I don't know your constraints but I wouldn't worry about multiple access from a file until it had been shown to be an issue. I would split up the configuration into different files for different classes/ groups of classes or, preferably, use a DB instead of files with different tables providing data for each class.

As an aside I've noticed that once you put the data in a db people seem to stop worrying about accessing it multiple times even though you're still going to the file system in the end.

PS: If other options aren't suitable I'd use a singleton... you want data to be globally available, you're not willing to use dependency injection, you only want the file to be read once; you've limited your options and a singleton isn't that bad.