views:

474

answers:

4

Gang of four uses a load balancer example to demonstrate the singleton pattern. I'm just wondering why a singleton needs to be used in that example? Are there any other real examples that specifically demonstrate using a singleton pattern?

I just want to know more specific reasons why I would want to prevent the creation of more than one instance of an object. And, I mean, if there were more than one load balancer instance, so what?

A: 

I just used one to instantiate a Flexwiki engine for an ASP.NET application because for that particular application I only needed the functionality to convert wiki syntax into HTML. The engine itself consumes a lot of memory, and I only need a small portion of it to fulfill my requirements. Additionally, it is not dependent on an individual user, so it can be stored in cache. Having another instance of the engine would be pointless as it serves no additional purpose other than to waste memory.

John Rasch
A: 

If you have a client-server app, then your service may require only a client per connection. For example, I need to register a callback with my service:

public class myClient
{
    public myClient()
    {
        myService = // get service somehow
        myService.Init(myCallback);
    }
    public void myCallback() { /* do something*/}
}

if you create a second instance of myClient, you will overwrite the first callback with the second.

TheSean
A: 

In one application, I had a manifest which was used to hold XML data retrieved from a server. This acted as a type of "cache" to prevent lookups from happening multiple times. Rather than passing a reference to the manifest from object to object, I created a Singleton which was accessed by whichever objects needed it at runtime.

bedwyr
I like this answer the best, but it still only discusses ease of use rather than the NEED fulfilled by the Singleton.I guess what I'm not getting is that, if I write MY code and only call the constructor for an object one time, isn't this the same level of control as making the class a Singleton?
David Droddy
If you are guaranteed to only call a certain constructor once, then by all means--keep it simple and don't use a Singleton. The question, however, is future extensibility and change. Can you guarantee you will never need to call the constructor again? If not, can you pass the class around via its reference, or will this further complicate your design? Controlling object construction is an important aspect of OO and really just needs some forethought. If you don't need a Singleton (or want to avoid some issues with their use), simplicity would dictate not using one :)
bedwyr
+2  A: 

A load balancer can't be very effective if there is more than one of them working at a time. If one load balancer assigns work to a device, then another balancer comes along and assigns work to the same device, the system can easily become unbalanced. The multiple load balancers would need to communicate with each other in order to do their job. It's simpler and more efficient to have a single instance of the balancer.

Another example of an application that calls for a Singleton is a software module whose job it is to talk to a device on a serial port. I recently implemented a class for communicating with a motor controller and I wanted to be very sure there was only one class accessing the serial line. Implementing this class as a Singleton insured that two instances could never be created, avoiding contention on the serial line.

Bill the Lizard
Thanks!!I guess the GoF load balancer is a silly one though because it uses a randomizer to select a server. So, regardless of the balancer being a Singleton, the randomizer will easily return the same server over and over again because random does not mean "non-repetitive."
David Droddy
What chapter is that example in? The Singleton chapter only has a generic example and the MazeFactory example, so I'm not seeing the load balancer anywhere.
Bill the Lizard