Re: [Week 4] Sample Game Programming Interview Question

Time for week 4 I hope these questions have been a good challenge for people!

Question 1:

What is a singleton? What are the advantages and disadvantages of using one?

Optional:

Write either a base class or template class to ease the implementation of a singleton.

Question 2:

Why do you want to work here?

Go for it!

Ahhh Question 2!!!
I can never answer that at an interview!! Almost 95% of the time I am not sure about the company I will dodge that question like my life depended on it. The problem with this question is that employers immediately think ****************** (common sense has just told me to stop).

So yeah my answer is, I dodge this question like my life depends on it most of the time (which is a real shame) and flunk. I would like it if the interviewer actually asked what do you hope to accomplish. Because my dreams are bigger than what they do ( let me dream people ... let me dream ).

Question 1. A singleton is object oriented methodology of implementing one class and everything we do should be in that class, included other classes... i'm not sure im making it up.

Re: [Week 4] Sample Game Programming Interview Question

Posted 21 February 2011 - 01:17 PM

1. A singleton design pattern has some advantages and disadvantages. The advantage is that it will save the user memory since there will never be more then one of the object at any given time. The disadvantage is that we lose the option of creating multiple instances of the class that can be different throughout the application.

Unless you declare the constructors (and destructors and all the rest) of your class private or protected, you won't have a real singleton, I'll still be able to create multiple instances of that class. But if I do make them non-public that defeats the purpose of the template.

Because your intention that the class should be used as a singleton is not immediately visible (because the implementation of the singleton lies outside the class, in your template) it may cause confusion for someone trying to understand how your code should be used. If instead you just declare an Instance() function for every singleton class there is no more confusion.

As an answer to question #1:
As a general guideline classes should not be singletons unless they either (a) have no internal state or (b) their internal state is entirely irrelevant to anything outside the class. Examples of classes that can be singletons are Logger, SoundRenderer, GraphicsRenderer...

This post has been edited by diego_pmc: 22 February 2011 - 06:06 AM
Reason for edit:: Added spoiler tags

Re: [Week 4] Sample Game Programming Interview Question

Posted 22 February 2011 - 05:54 AM

Actually that is a great implementation. As long as your constructor is declared private then you will still not be able to create an instance of the class except through the static Instance() function, which is public. The best way to use this is to have the Singleton be a friend of your class

Re: [Week 4] Sample Game Programming Interview Question

Posted 22 February 2011 - 06:02 AM

Yes, but I'm almost implementing the entire singleton in the class itself. Only difference is instead of an Instance() function I have a friend declaration and one more header to worry about. Maybe this varies from person to person, but I'd rather declare the function in every singleton class rather than have a friend. Friends should be avoided and are unnecessary in most cases. (Btw, you could make a question about how and when to use friends next time. )

Re: [Week 4] Sample Game Programming Interview Question

Posted 22 February 2011 - 08:53 AM

What I'm saying is (to continue from my last post), are there any advantages to having a singleton template, instead of making each class a template? In the example you gave the Factory template could very well be a singleton itself so there's no need for the second typedef.

Re: [Week 4] Sample Game Programming Interview Question

Posted 22 February 2011 - 11:27 AM

Singleton design pattern is a design pattern which architecturally enforces the idea that one and only one instance of a singleton class can be instantiated at any given time. A clear disadvantage to this design pattern is that it introduces a form of global state to your software which can cause unusual behavior if not guarded against. Singletons might also make concurrency difficult/impossible depending on the implementation of the class.

Another disadvantage is that classes which interact with the singleton must generally be aware of the fact that the class is a singleton. This introduces a tight coupling between the two classes. Using something like inversion of control and/or dependency injection would help to mitigate this coupling.

A simplistic implementation of the design pattern is to allow each singleton class to provide an instance of itself. I don't like the previous examples of making singleton classes a friend of the Singleton class. It needlessly exposes their entire interface to the Singleton class which may not seem particularly harmful at first, but could lead to problems down the road. I am a strong believer that you should limit the exposure of your interfaces to the bare minimum. It also does not allow for objects to be constructed properly. Even if they were to be constructed properly, the Singleton class now has the responsibility of understanding the dependency requirements of the class its instantiating.

Finally, by making the instance static in the Singleton class, you defeat the ability to achieve lazy instantiation which is often considered an advantage of the design pattern for reasons of efficiency and memory conservation. In this case, those singleton instances will always be present and always consuming resources.