What's Alternative to Singleton

The Google Testing blog has a series of entries about avoiding Singleton (in order to create testable code). Maybe this can help you:

Using dependency injection to avoid singletons
Singletons are Pathological Liars
Root Cause of Singletons
Where have all the Singletons Gone?

The last article explains in detail how to move the creation of new objects into a factory, so you can avoid using singletons. Worth reading for sure.

In short we move all of the new operators to a factory.
We group all of the objects of similar lifetime into a single factory.

Alternatives for the singleton pattern?

Generally, I avoid singletons because they make it harder to unit test your application. Singletons are hard to mock up for unit tests precisely because of their nature -- you always get the same one, not one you can configure easily for a unit test. Configuration data -- strongly-typed configuration data, anyway -- is one exception I make, though. Typically configuration data is relatively static anyway and the alternative involves writing a fair amount of code to avoid the static classes the framework provides to access the web.config anyway.

There are a couple of different ways to use it that will still allow you to unit test you application. One way (maybe both ways, if your singleton doesn't lazily read the app.cofnig) is to have a default app.config file in your unit test project providing the defaults required for your tests. You can use reflection to replace any specific values as needed in your unit tests. Typically, I'd configure a private method that allows the private singleton instance to be deleted in test set up if I do make changes for particular tests.

Another way is to not actually use the singleton directly, but create an interface for it that the singleton class implements. You can use hand injection of the interface, defaulting to the singleton instance if the supplied value is null. This allows you to create a mock instance that you can pass to the class under test for your tests, but in your real code use the singleton instance. Essentially, every class that needs it maintains a private reference to the singleton instance and uses it. I like this way a little better, but since the singleton will be created you may still need the default app.config file, unless all of the values are lazily loaded.

public class Foo
{
    private IAppConfiguration Configuration { get; set; }

    public Foo() : this(null) { }

    public Foo( IAppConfiguration config )
    {
        this.Configuration = config ?? AppConfiguration.Instance;
    }

    public void Bar()
    {
         var value = this.Config.SomeMaximum;
         ...
    }
}

Are there any viable alternatives to the GOF Singleton Pattern?

Alex Miller in "Patterns I Hate" quotes the following:

"When a singleton seems like the answer, I find it is often wiser to:

Create an interface and a default implementation of your singleton
Construct a single instance of your default implementation at the “top” of your system. This might be in a Spring config, or in code, or defined in a variety of ways depending on your system.
Pass the single instance into each component that needs it (dependency injection)

Alternatives to Singletons

Simple: create a single instance of your file manager (or whatever) class, and then pass it around inside your application as necessary. Much will depend on your application structure, but typically you have some sort of controller object that creates the other important objects in the application. That might be the object to instantiate the file manager, and then pass it to the other objects it creates that need a file manager.

If you're using a singleton because there MUST be no more than one instance of a certain class, that's usually okay. If you're using it because a singleton is a globally-accessible object that lets you avoid thinking about how the other objects talk to each other and what each object is responsible for, that's where you start to run into problems.

The file manager is a nice example. At first it seems like there should only ever be zero or one instances of the file manager object. But is that necessary? Can't you have two file systems on one machine at the same time?

Alternative To Singleton Util Class

You should avoid all static methods and instead design a class which does not mandate its lifecycle: it can be a typical immutable POJO with a public constructor.

Then, when you need it as a singleton, use it as a singleton. For testing, use it in some other way.

Usually, dependency injection is the preferred avenue to solve these problems: instead of hard-coding a pulling mechanism for your configuration object, you have the object delivered to any class which needs it. Then you can decide late what bean you will deliver.

Since you are probably not using Spring (otherwise dependency injection would be your default), consider using Guice, which is a very lightweight and non-intrusive approach to dependency injection.

Singleton Alternative - is it equivalent?

public sealed class Singleton
{
    private static readonly Lazy<Singleton> lazy = new Lazy<Singleton>(() => new Singleton());

    public static Singleton Instance { get { return lazy.Value; } }

    private Singleton()
    {
    }
}

Fast, clean, thread-safe.

What's Alternative to Singleton