2

If I know that a particular class is only going to be instantiated ONLY once in my program, would it be better to use static methods and variables instead for that particular class? If not, what would be the benefits of using instance methods and variables over static ones if there will only be one instance of that class?

Will Lin
  • 39
  • 5
  • 1
    You *could* make it an `enum`. But why **limit** yourself? What if you need two instances, or three? – Elliott Frisch May 23 '17 at 04:01
  • 1
    If you really know that it will be one instance then you should use (Singleton) pattern – Fady Saad May 23 '17 at 04:01
  • This question might be useful: https://stackoverflow.com/questions/519520/difference-between-static-class-and-singleton-pattern?noredirect=1&lq=1 – Leandro Galvan May 23 '17 at 04:04
  • Singleton is definitely an approach. However, I would suggest thinking about a `Factory` pattern that returns the single instance. Such an approach can make testing easier if it is necessary to change out the singleton for such purposes. – KevinO May 23 '17 at 04:09
  • 1
    Testability! Both singletons and static methods have testability issues. If it were up to me, I wouldn't use either. – Dawood ibn Kareem May 23 '17 at 04:26
  • @DawoodibnKareem David, what would you use? – Scary Wombat May 23 '17 at 04:33
  • @ScaryWombat I'd just instantiate it when I need it. These things can be horribly overengineered sometimes. – Dawood ibn Kareem May 23 '17 at 04:44

2 Answers2

4

That depends on what you need the class to do, and what you may need it for in the future. It also depends on how many people are going to see or use this code. If this code is only ever going to be seen and used by you, than picking one implementation and following it all the way through, then forcing yourself to switch to the other implementation as an exercise could be illuminating.

Assuming your code will be seen or used by another programmer:

If the object is something that you need to mimic in tests (like a database connection, for example) then it'll be best to have your methods be instance methods and find some other strategy for ensuring you only ever have the one.

If there is any chance at all that the things your class does could be done another way (ex. your class writes the output of your program to an excel file) then passing instances of your class into whatever methods need them is a good way to help make your code more flexible (ex. if later you decide you want to generate html output instead, all you have to do is write a sister implementation of your excel writer and pass that in instead).

If you are near 100% certain that your code will never need to be mimicked (aka "mocked") and that you will never need to take advantage polymorphism (eg. the Math class in Java) then the static approach will probably be fine, but this a rare case.

Mike Pors
  • 318
  • 3
  • 5
3

We come to the discussion on when we use a singleton or static methods. It has been discussed previously on this very site so I would point to that at the end of this answer.

One way to look at this is to ask if the class has state, would it need to be subclassed, how is it to be tested, would the singleton be used within a dependency injection framework i.e. will it be injected?

If your answer is "yes" to any of the aforementioned, you are better using a singleton - if not then you could use static methods.

However both these approaches are discussed in more detail in the links below in terms of why they should or should not be used.

See this for "why singletons is bad".

See this for "when not to use static methods".

Khanna111
  • 3,627
  • 1
  • 23
  • 25