I am not sure it is more complex, it is different certainly. IMHO the difference between the factory and singleton pattern is simply that the factory object constructs an object that it no longer has a handle too while the singleton preserves a handle to enable global access. You are correct that there is no good reason to wrap a dbi connection in a seperate object, I was getting over-excited in an OO sense (scary picture right there). However I do stand by my criticm regarding using a singleton in this context. There is no reason to give global access so you should not.

The ONLY advantage of my more complex design is in design purity. IMHO it is well worth coding effort to show intent, and even to enforce intent. OO programming advocates this at many levels. The patterns in OO programming are useful only if they are used in the way intended, my original node described the intent for a singleton. It is my belief that in this case a singleton resolves many of the technical issues but does not clearly show intent.

Singleton Intent Ensure a class only has one instance and provide a global point of access to it.

There will not be one instance of the connection class and a global point of access is only required to work around a scoping problem. The factory and faceted combination would seem to be closer to the requirement.

In my mind an implementation of a factory and facteted combination would require VERY little additional coding effort.

Update
Just to address some of the points I missed first time around ;-) Pressed submit instead of preview.

I must first confess to ignorance, you talk about causing the webserver to control the number of database handles that are availible. I have no experience of doing this. I have always controlled connection pooling at an application level, but then most of my dev is in large scale app land not web stuff. I will therefore bow to your superior knowledge here. My instincts tell me that I would still like to control them directly but I cannot justify it technically as I know little of the pros and cons.
--

Zigster

Here are my basic premises.
1. If you have to write more code, and it takes longer to describe, then it is more complex. No ands, ifs, or buts.
2. I value simplicity more than abstract theories about correct ways to do things. My theory is that simple is easier to write, easier to learn, and easier to figure out how to change if you need to. I will need something concrete to get me to throw away advantages like those.
3. I am not a big label person. Oh, I like knowing what the labels are, but I generally avoid throwing them around without good reason.
So by these criteria I darned well know what I will do.

An incidental point. Your label is wrong. As I said I am not a big label person, so I don't really care. But for this to be a singleton design pattern, you need to have a class involved. Without a class this is plain old memoization. And plain old memoization has as its purpose allowing you to do work only once and then return the answer from cache. Which documents exactly our intent.

Don't believe me? Well look up Memoize. With that you could write the DBI method like this:

use Memoize;
memoize('dbi');

sub dbi {
  DBI->connect(yadda, yadda);
}
[download]

instead of like this:

{
  my $dbh;

  sub dbi {
    $dbh ||= DBI->connect(yadda, yadda);
  }
}
[download]

except that in one case we have let Dominus write a general caching mechanism, and in the other we rolled our own.

In fact with this insight, the dbi function might well take an optional argument specifying which of several databases to connect to. Conceptually this is still simple memoization. The case where we always returned the same thing is just the simplest case. With a little work we could return a connection to the database of your choice instead, defaulting reasonably. Now do you see why this is different from the Singleton design pattern? I have not imposed any structure on how the caching works, so I can move to a more complex structure without adding related structures.

And here is why I don't much like labels. Labels blind you. Labels turn into categorizations that are applied with little thought and foresight. This reduces the myriad of ways to understand problems into memorized channels that shall never be deviated from. I try not to limit myself like that.

This tendancy is most of what I dislike about OO programming and OO design. I only rarely read /., but I did last week when people were talking about an article of chromatic's. And so I ran into this little gem. Even though it is from an anonymous coward, I believe it is probably genuine. Not only is it written too well to be a typical troll, it also fits too well with things that I have seen...

I am going to let this drop now, the tone of your node seems to suggests that this is turning a little bit heated. I am not up for that kinda discussion. Suffice to come back upon a few points. I am not trying to have the last word. If you wanna come back then go for it, I will drop off now tho.

An incidental point. Your label is wrong. As I said I am not a big label person, so I don't really care. But for this to be a singleton design pattern, you need to have a class involved

I actually originally said:

This is a nice pattern to use, I am sure you realise that it is a variant of the singleton object. *REACHES for DP*

I am aware that this is not a singleton, however it exhibits enuff of the chars to allow it to be discussed as one. So that any points I made regarding singletons will also hold of for this 'thing'. Sorry for not being more explicit in my posts.

In fact with this insight, the dbi function might well take an optional argument specifying which of several databases to connect to. Conceptually this is still simple memoization

I quite agree this is in fact the jewel/facet pattern I have been talking about for the last few nodes. I assumed you were familiar with this pattern or I would have expanded (I do not intend this to be insulting, simply that noone knows every pattern and without a common frame of reference discussion is harder).

Now do you see why this is different from the Singleton design pattern? I have not imposed any structure on how the caching works, so I can move to a more complex structure without adding related structures.

I certainly do, you are no longer describing a singleton. See comments before about intent. A singleton has specific behaviour, as does a facet.

And here is why I don't much like labels. Labels blind you. Labels turn into categorizations that are applied with little thought and foresight. This reduces the myriad of ways to understand problems into memorized channels that shall never be deviated from. I try not to limit myself like that.

Here I think our viewpoints differ, I find PATTERNS very valuable. My take is that other ppl are smarter than me so I tend to copy other peoples bright ideas rather than creating my own. Most of the views I have stated in the last few nodes could be found in OO text books. I have a strong background in OO programming and do disagree with a number of the principles at hand, I do not follow like a blind little sheep, yet I tend to follow the prescribed route of pattern interaction UNLESS something tells me it is wrong to do so. Thus far I see no good reason for not using patterns.

Interestingly tho the poing you make about lables blinding you is quite true. If I had not hidden behind lables and had instead explained the facet pattern then maybe we would have agreed sooner.
--

Zigster