Re (tilly) 7: Object Oriented Pattern help

[tilly]

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);
}

instead of like this:

{
  my $dbh;

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

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