Should a single object used throughout the app be static?

Question

I'm writing a C# application that analyzes stocks based on historic prices. I have an object that holds the data (historic prices). All the data is kept in this object - I only need one instance of it, and the data is used by many other objects throughout the app.

Given the above, wouldn't it be easier (and also a better design) to make this object static? Because the alternative is what I'm currently doing - passing around between objects tens of references to the same single instance.

The reason I'm still hesitant is that I know static objects should be treated carefully and because I've read this answer. In my case, the object is not a simple utility object and it is not stateless. Data is being loaded into the object and changes it, but my thinking is that these changes still need to be shared across all other objects and I know I won't need to have two different instances of this data object.

What's your thinking as to the best approach in my case? Is there an alternative solution I didn't consider?

Answer 1

You can make it static or use the Singleton design pattern. I would use the Singleton.

No need to pass the reference around, the Singleton provides a global access point.

Example:

public class Singleton
{
    private static Singleton instance;

    private Singleton()
    {}

    public static Singleton GetInstance()
    {
        if(instance == null)
           instance = new Singleton();

        return instance;
    }
}

Private constructor and the GetInstance() function ensure there is only one instance of the object.

If you ever need to get the reference to the object to call a function inside the object just use this:

Singleton.GetInstance().FunctionName();

Also, this is lazy instantiation and not thread safe(multi-threaded programs), but you can learn more about that on your own, it should be fun!

Answer 2

If your object has a state, then instead of making it static or a singleton, I recommend using a dependency injection design pattern.

This way, you can replace that object or class with a different one depending on the circumstances e.g. one class for production code, another for testing.

The instance can be resolved in various dependency injection styles e.g.

• Constructor injection

• Property injection

• Inversion of Control Container (e.g. CommonServiceLocator)

• Configuration file

In all these options, you define an interface or base class with the public contract you want to use, then determine the actual class/instance implementing the interface outside the using code, so that you can change the decision without changing that code.

Answer 3

For what you want I'd say singleton. It all comes down to preference. Static makes it so your class can't be instantiated so you use the className.myMethod(). Thats fine if your data retrieval is not done in the constructor and you use a method to pull in the data. How ever if your constructor has connection credentials you need to move that to a new method you can call. Singleton can be limited to a single instance. You can test both and see which works best for you.

Answer 4

What about using the singleton-pattern? http://en.wikipedia.org/wiki/Singleton_pattern No references have to be passed. And it might help making it easier to change the design again.