Page 2 of 2
Posted: Fri Feb 25, 2005 12:47 pm
by smpdawg
Why go through the hassle of calling to Object::instance() and using the returned object in each scope? Why not treat the object for what it really is in this example which is a static object.
The primary difference between a singleton and a static class is that a singleton is instantiated once and only once and returns the same object handle whenever you call its constructor which is Object::instance() in this example. That is the core of a singletons behaviour - it is an instantiated object of which only one copy can ever exist during the lifetime of the application.
A static class on the other hand does not need to return an instance and in fact it doesn't. It is called via its static members and is never instantiated which is perfectly acceptable for what you are trying to do.
It seems that the only reason you are calling Object::instance() is the get a variable which can be used to access the object members. That basically makes it a shorthand method to access its members but you could still do it this way,
Whereas you would be doing this.
By accessing it as a static member, its origin is obvious.
Posted: Fri Feb 25, 2005 3:59 pm
by The Monkey
smpdawg, I like the way you are laying all of this out for us. I've been gone most of today, but I have been carefully rereading the "Introduction to Design Patterns" in Mr. Schlossnagle's book, and I still had no idea what the purpose of Singleton::getInstance() was.
I think that what I really want is not a Singleton, but a static object. Do I have everything straight?
- Monkey
Posted: Fri Feb 25, 2005 4:16 pm
by smpdawg
I think the only use for a singleton is if you have API's that require that you pass an object handle (or pointer) into them in order to do processing. I am sure in that case there would be lots of uses and I know that the Graphics Gems series of books discuss the implementation of singletons for use in graphics development. I'd have to pull them out to see an example of their use.
I guess the Windows use for a singleton would be an object that manages a device context. This would give you a means of access that would hopefully prevent you from creating multiple device contexts and would still provide a destructor to do clean up.
getInstance exists for only one reason which is you cannot call the constructor of an object because its default behavior is to create a new instance of the object and return a handle. So the typical implementation attempts to move the constructor out of scope by making it private and then introduces a new method that checks for the existence of an instance and returns it or creates a new instance of the object.
For what we (as PHP programmers) would tend to do, a static class makes more sense because we don't care about an object handle. We just want a container for behavior that doesn't require an instance to be created.
The reason I would still lean toward static classes rather than singletons is because people that are unfamiliar with the proper use of a singleton might be inclined to create a global variable to hold the handle of the singleton and then introduce the ugliness of globals to the system. With a static class this would be a little more difficult to do.
Posted: Fri Feb 25, 2005 4:40 pm
by The Monkey
Thank you, I think I will go with a static class. A Singleton would have added unneeded complexity (for the purposes of a dbms, anyway) that I was trying to avoid in the first place.
- Monkey
Posted: Fri Feb 25, 2005 4:50 pm
by smpdawg
I guess all that reading finally paid off.
You know what? Maybe I'll post in here more often. I really enjoy talking about theory and design. I don't mind troubleshooting code but I particularly enjoy bouncing ideas around and talking about what-if scenarios.
Posted: Fri Feb 25, 2005 5:53 pm
by The Monkey
Ah, I just discovered that Class::$var; will not work in PHP 4... I now understand the purpose of a static class variable!
There are some interesting work-arounds and other ideas documented on
This PHP Manual page.
Posted: Mon Mar 14, 2005 12:13 am
by lastcraft
Hi...
timvw wrote:if that is what you want i don't see a reason why you shouldn't use it....
You rob yourself of polymorphism. Use for syntactic sugar only. One of the problems with PEAR is that it is riddled with static methods. Use a factory object if you can.
timvw wrote:
if you want more info: just do a websearch for singleton pattern..
Please see
http://c2.com/cgi/wiki?SingletonsAreEvil
Also in Pattern Hatching (Vlissides from GOF) it's nasty side is uncovered. You can go a long way in PHP just creating an object once in the top level script and then passing it around. An individual PHP script doesn't cover the whole application, but usually just one slice. This means that complex tools like Java containers are rarely needed (although there is a port of Pico now).
Any Singleton you put in now, you will want to take out in about a year from now.
yours, Marcus
Posted: Mon Mar 14, 2005 10:15 am
by McGruff