2

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?

Community
  • 1
  • 1
Itay
  • 57
  • 6

4 Answers4

5

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!

apxcode
  • 7,696
  • 7
  • 30
  • 41
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.

Danny Varod
  • 17,324
  • 5
  • 69
  • 111
  • I think the point to emphasize here is that the inability to do dependency injection *is* the reason not to use a singleton pattern or static class. IoC containers and service locators generally have a good way to bind types to singletons anyway. – Ben Aaronson May 10 '14 at 21:44
  • @BenAaronson I am assuming that for many people that would ask this question, the importance of dependency injection isn't clear to them, otherwise they wouldn't even consider a singleton or static class. That is why I am not being so blunt. – Danny Varod May 10 '14 at 21:48
1

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.

user3587554
  • 353
  • 1
  • 7
0

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.

user3387542
  • 611
  • 1
  • 8
  • 28
  • Singleton does not mean static, so it may still require passing references around – jordan May 10 '14 at 20:33
  • Its not static, but somehow very close to it. You can only have one instance of this class. (if you'd done it properly) And you can Easily get it by calling MyNewSingeltonClass.getInstance().testMethod()/testmember as getInstance is a static method. From everywhere. – user3387542 May 10 '14 at 20:39
  • @jordan Not true, read my answer. The Singleton provides a global access point. – apxcode May 10 '14 at 20:39
  • Yes, a way around passing the instance is made possible using the solution you provided. Doing this makes it impossible to test all code that depends on this. Yes there are hacks to get around this during testing, but, again, they are hacks. If you pass the instance around, then you can mock it and allow test coverage. Otherwise this global access point makes testing difficult. Also if in the future you change it to not be a singleton, then no dependencies should require a change. – jordan May 10 '14 at 21:06
  • Also your quote "You can make it static or use the Singleton design pattern." agrees with my first statement that they are distinct things. – jordan May 10 '14 at 21:09