[stayscrisp]

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!

[(Cryptic)]

stayscrisp, on 21 February 2011 - 10:06 AM, said:

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.

1A - I don't know...

Spoiler

CSingleton mySingletone;

int main(int argc, char** argv)
{
   mySingletone = new CSingleton();
   bool forever = true;
   do{

     forever = mySingletone.Update();

   }while(forever);

}

class CSingleton
{
  CClass1 myClass1;
  CClass2 myClass2;
  CPlayer myPlayer;
  
  int x,z,y;

  void CSingleton()
  {
     // This becomes my initialization spot

     myPlayer = CPlayer();
     x = 0;
     y = 0;
     z = 0;
  }

  void ~CSingleton()
  {
     // Clear everything
  }

  bool Update();


}

I wasn't joking when I said I don't know. Good practice though.

REDBUULLLLL

This post has been edited by (Cryptic): 21 February 2011 - 10:48 AM

[ButchDean]

Then do some research, (Cryptic)!

[(Cryptic)]

ButchDean, on 21 February 2011 - 10:59 AM, said:

Then do some research, (Cryptic)!

Yes Sir!

[ButchDean]

(Cryptic), on 21 February 2011 - 06:08 PM, said:

ButchDean, on 21 February 2011 - 10:59 AM, said:

Then do some research, (Cryptic)!

Yes Sir!

Good man!

[calebjonasson]

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.

2. Varies on the employer.

[stayscrisp]

@(Cryptic) you certainly do not need to do everything through a singleton.

This post has been edited by stayscrisp: 22 February 2011 - 05:11 AM

[diego_pmc]

stayscrisp, on 21 February 2011 - 10:06 AM, said:

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

The only way I could think of (and also the only implementation I was able to find on the web) of a base/template Singleton is something like this:

Spoiler

template<class T>
class Singleton
{
  public:
    static T* Instance()
    {
        // Meyers singleton
        static T obj;
        return &obj;
    }
};

However I see several problems with having a template Singleton:

• 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

[stayscrisp]

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

Spoiler

#include "Singleton.h"

class Foo
{
   public:

     // some methods

   private:

   Foo(); // private constructor
   friend class Singleton<Foo>; // you can see that this class is a singleton
};
typedef Singleton<Foo> TheFoo; // a nice typedef

[diego_pmc]

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. )

This post has been edited by diego_pmc: 22 February 2011 - 06:06 AM

[ButchDean]

Yes, no need for a friend in a Singleton's implementation, but I also can't see it doing any harm.

[diego_pmc]

I think I'm not very clear about what I mean. Let me try through code. Why should I have this...

Spoiler

template<class T>
class Singleton
{
  public:
    static T* Instance()
    {
        static T obj;
        return &obj;
    }
};

class Foo
{
  friend Singleton;

  protected:
    Foo();
    Foo(const Foo& other);
    ~Foo();
    Foo& operator=(const Foo& other);
};

... instead of this...

Spoiler

class Foo
{
  public:
    static Foo* Instance();

  protected:
    Foo();
    Foo(const Foo& other);
    ~Foo();
    Foo& operator=(const Foo& other);
};

All I'm basically doing is removing the need to declare the Instance() function for every class with the need to include one more header (for the template) and to declare a friend.

This post has been edited by diego_pmc: 22 February 2011 - 06:49 AM

[stayscrisp]

I can't see friend causing any harm in this case, in fact I think it might be a good use of friend. One of the great things about a template class like this is that you can create classes like this:

#include "Factory.h"
#include "Singleton.h"

typedef Factory<GameObject> GameObjectFactory;
typedef Singleton<GameObjectFactory> TheGameObjectFactory;

[diego_pmc]

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.

This post has been edited by diego_pmc: 22 February 2011 - 08:54 AM

[dorknexus]

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.

Spoiler

template <class T>
class Singleton {
private:
    static T *instance;

public:    
    static T* getInstance() {
        if (instance == NULL) {
            instance = new T;
        }
        return instance;
    }
};    

template <class T> T* Singleton<T>::instance=NULL;