The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Oh, I'd point my finger to efficiency. In order to appreciate how things work when they're done properly and to understand them, understanding the very basics of computers is a necessity. I'd suggest picking up a C book or ASM if you've got a bit of time. And while you're at it, go pick up the Pragmatic Programmer.

I know this isn't the answer you wanted. And I probably sound like a jerk. But there comes a time when people that call themselves programmers stop being lazy and be so quick to question why, why, why, when they should take that time to understand and read.

One of the reasons for using a singleton is not to use it - so to say.
The monostate (or static class) is actually a procedural call in disguise. That is to say there is no real structural difference between this expression :DB::SomeMethod()
and this one :DB_SomeMethod().

If you work with a OO code-structure, this is a conflict since you would introduce procedural code into the OO code. Using a Singleton instead gets you back on the pure OO track :$db =& DB::GetSingleton(); $db->someMethod()

Now you may argue that it's ridiculous to go through all that trouble just to suit formalities, but there is one added benifit of using Singletons.
If you should ever need to have more than one instance of the object in mind, you will need to make radical changes to all code relying on it if you used the static-class-approach - However if you did in fact use a Singleton in the first place, all you have to change is the places where you use $db =& DB::GetSingleton();

The monostate (or static class) is actually a procedural call in disguise. That is to say there is no real structural difference between this expression :DB::SomeMethod()
and this one :DB_SomeMethod().

If you are using static attributes I think there is a little difference.

Originally Posted by kyberfabrikken

If you work with a OO code-structure, this is a conflict since you would introduce procedural code into the OO code. Using a Singleton instead gets you back on the pure OO track :$db =& DB::GetSingleton(); $db->someMethod()

Hmm, I don't think this violates pure OO coding style much more than some if() then else, foreach() and while(){} code.

Originally Posted by kyberfabrikken

Now you may argue that it's ridiculous to go through all that trouble just to suit formalities, but there is one added benifit of using Singletons.
If you should ever need to have more than one instance of the object in mind, you will need to make radical changes to all code relying on it if you used the static-class-approach - However if you did in fact use a Singleton in the first place, all you have to change is the places where you use $db =& DB::GetSingleton();

That's a good point, but again why not to use global? I know that globals are evil, but in this example I can see no difference between them and Singletons.

If you are using static attributes I think there is a little difference.

No comprendes

Hmm, I don't think this violates pure OO coding style much more than some if() then else, foreach() and while(){} code.

Using global functions (witch it is) is not good OO. Using basic control-structures is part of the language syntax whether you write in an objectoriented or procedural paradigm.

I know that globals are evil, but in this example I can see no difference between them and Singletons.

Precisely the point. A singleton object is a global object, but it's easily replaceable by a normal object later on. It's a matter of your personal preferences whether you prefer this :

PHP Code:

$db =& $_GLOBALS['__db'];
$db->someMethod();

over this :

PHP Code:

$db =& DB::GetSingleton();
$db->someMethod();

The second one makes it easier to change the name of the variable if you encounter namespace-conflicts at some point. Besides it gives you the option to not instantiate the object until it's actually being used.

Hmm, I don't think this violates pure OO coding style much more than some if() then else, foreach() and while(){} code.

It makes sense if you look at it from a responsibilities perspective - in OOP responsibilities are given to objects, not collections of functions. That doesn't mean to say that collections of functions couldn't take on the responsibilities, just that in OO you tend not to.

The bigest single point of difference between the $db = DB::getInstance() and $db = $GLOBALS=['db'] is that you can ensure proper instanciation of the global in DB::getInstance() and in the global version you are implicitly relying on the fact that you have correctly instanciated the global variable before use.

The bigest single point of difference between the $db = DB::getInstance() and $db = $GLOBALS=['db'] is that you can ensure proper instanciation of the global in DB::getInstance() and in the global version you are implicitly relying on the fact that you have correctly instanciated the global variable before use.

Yes, lazy instanciation is a good example where Singleton is better than Monostate. But i can imagine some cases where lazy instanciation is not a plus.

Thanks, for the comments guys. I still see some place for Monostate in PHP, but now I know where the usage of Singletons will be better.

Global, Singleton, MonoState (the above wasn't strictly a MonoState, but near enough) and Registry all provide global access. A situation where I am forced to use globally accessable information is not one I want to be in, but if I am I'll choose the Registry first and the Singleton second.

The registry allows testing, because I can fiddle with the entries externally to the code being tested. Still awkward though.

The Singleton makes the global behaviour much more visible in the client code. The Monostate hides the global nature. This makes it easier to understand the code and to refactor in a very explicit way. the Monostate breaks the rule of least surprise.

The real issue of course is whether you really need this data global at all. OO provides a wealth of alternate patterns. We are certainly not short of ways to refactor our code to allow passing of the data around or localising it to the code where it is needed. Any kind of global data will cause issues, not least in testing.

Oh, I'd point my finger to efficiency. In order to appreciate how things work when they're done properly and to understand them, understanding the very basics of computers is a necessity. I'd suggest picking up a C book or ASM if you've got a bit of time. And while you're at it, go pick up the Pragmatic Programmer.

I know this isn't the answer you wanted. And I probably sound like a jerk. But there comes a time when people that call themselves programmers stop being lazy and be so quick to question why, why, why, when they should take that time to understand and read.

There are no stupid questions, only stupid people.
Why on earth would you discourage questions or discussions.
You're input was completely useless and not only didnt answer his question, but for no logical coherent reason tried to cut his learning by making him feel like he shouldnt ask questions.
If you have nothing productive to say, don't say anything.

As far as reasons for using singleton go - I prefer singlton because you don't have any extra code. If i need a db instance, I'll just use it:

PHP Code:

ConfigParams::GetValue("param_name")

so I don't have to write global $config_params at the start of every function. I find it cleaner code.
Other than there is little difference. They are both held globally.

Yes, I haven't read about monostate, but with that link posted it seems I'm using that.
There are very subtle differences, and in most cases there would be no difference in its use. In singleton the class has a static instance of the class itself - and there is just one instance of each member in the class because of this, and in monostate, the class just has static instances of the members which you access individually.
This seems to me that any difference would be in the behaviour of the class methods that provide behaviour on the data items, but I'm too tired to think about that right now, so I'm heading off to the land of nod =)

I find myself using monostate when there are several methods that logically relate to each other, but don't share any class properties, and a singleton when I have an object that stores properties, but only ever want one instance of it floating around. They both achieve that global access, but are subtley different in how it happens. The important thing about them as opposed to using global $variables; all over the place is that you can control how those variables are accessed and manipulated.

I find myself using monostate when there are several methods that logically relate to each other, but don't share any class properties

Witch is why I sometimes miss namespaces under php. PEAR does this by using underscores to sepearate packages. It may look ugly, but I kind of prefer this solution, since it allows for hierachies instead of just one level of namespace.
Eg. You can't do Http::Socket::Util but you could do Http_Socket_Util

I find myself using monostate when there are several methods that logically relate to each other, but don't share any class properties, and a singleton when I have an object that stores properties, but only ever want one instance of it floating around. They both achieve that global access, but are subtley different in how it happens. The important thing about them as opposed to using global $variables; all over the place is that you can control how those variables are accessed and manipulated.

For use or properties, you can use either and they work the same way. I can't see any difference in using these two below. In both situations, the properties you access will always be from one instance. Do you have an example where one would make a difference over the other? If it is where you have a group of methods without properties, why not just make a regular class and instantiate it?

If it really is a function lib, using a monostate class is a bit like a namespace. Using either syntax, it is impossible to say whether the class is storing internal state or not, but the bottom one looks like it isn't, so in a case where you don't, it might make it more descriptive.

For myself, I just make a PHP file, chuck in some functions, and code like this:

For use or properties, you can use either and they work the same way. I can't see any difference in using these two below. In both situations, the properties you access will always be from one instance. Do you have an example where one would make a difference over the other? If it is where you have a group of methods without properties, why not just make a regular class and instantiate it?

The main reason is that the properties of the MonoState class are static; if you were to create a couple of instances of the MonoState each instance would be sharing the same properties. This has the same effect as the singleton, but in some cases you might want your MonoState to have its own instance specific properties also. But in most practical applications you're correct, the end result is the same.

In that case the difference lies more in it's use. If you create a 'monostate' class with all class data being static, it's basically the same as a singleton (which has been how i've used it).
But if you create it with some other non-static class data also, it's basically a regular class with some static variables - which i suppose is the point of giving it a seperate name ('monostate').

And in that case, the static variables in a monostate's object are global to their own objects only, so there is still some data/information-hiding which is a plus.

Yeah, monostate when used in instantiated objects provides global data access only to other classes of the same type (until you add accessors etc). The PDF someone linked up above gives a pretty good explanation of it.