in reply to Re: Log::Log4perl and singleton design issue
in thread Log::Log4perl and singleton design issue

"No practical value"!? The value of a singleton is in where it's used. In this case, it may seem like less value, but if you wanted to switch from a singleton to a pool structure, the code change is nil.

Take for instance an object that used semaphores and locking to prevent multiple people exuting at once. For instance, a banks total available funds, not per account basis. One person would want to withdraw $50, but you don't want to create race conditions.

If taking out money starts to create contention, you can create pools of bank totals so that multiple people can withdraw and deposit at the same time without race conditions, and less contention. If $5 million were broken out into pools of $1 million, 5 people could withdraw and deposit at the same time w/o creating a race condition provided each person got a different object, one for each of the million. As pooled items aren't needed, they can be put away and dealocated.

Where does this all lead up to? If you use the singleton pattern, everyone would use the single, lockable object. If locking becomes a problem, then you can change the code in whatever creates your singleton instances to create a limit of 5 pooled objects. If all 5 are in use, you have to wait. if 4 are in use, you get a new one. Basically, a pool, as you and I know of. Using the pattern will result in less code change. If you use a global, you can't accomplish this. If you are using a singleton, it's a lot easier. In some OO languages, this is very easy to implement. In others, it takes foot work. But by far, it is not useless.

----
Give me strength for today.. I will not talk it away..
Just for a moment.. It will burn through the clouds.. and shine down on me.

  • Comment on Re^2: Log::Log4perl and singleton design issue

Replies are listed 'Best First'.
Re^3: Log::Log4perl and singleton design issue
by BrowserUk (Patriarch) on Dec 19, 2004 at 20:02 UTC

    There is no reason that the global in question cannot be an object. And no reason that object shouldn't actually represent a pool of things, performing locking, or whatever else you might require under the covers.

    Global is about scope, not encapsulation. If the resource has application wide usage, there is no reason that it should not have application wide scope. That the resource is an object (or represented by an object) is neither here nor there.

    Once you accept that an object that has application wide scope, is just a.n.other object with global scope. It's just another object that gets instantiated early in the program and lives for the life of the program. How it is implemented, a single thing, or a pool of things is irrelevant.

    The 'singleton pattern' makes a special case where no special case is needed.

    Of course, if the needs are simple, then I'd probably use a glob for logging, and if the needs became more complex, then I'd tie the glob.

    Examine what is said, not who speaks.        The end of an era!
    "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
    "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
      Yes, but you make it function accessable so you can create two, one or three on a whim. The singleton pattern allows control over that.

      ----
      Give me strength for today.. I will not talk it away..
      Just for a moment.. It will burn through the clouds.. and shine down on me.

[reply]
        ... so you can create two, one or three on a whim. The singleton pattern allows control over that.

        1, 2 or 3 instances of a singleton ... m'kay :)

        Examine what is said, not who speaks.        The end of an era!
        "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
        "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]

In Section Seekers of Perl Wisdom