Well the topic is self explanitory.

Is it better to use static functions (c#) or class methods (ruby) than using a singleton pattern?

The reason i ask is because i've found (in ruby) using class methods is a good way to handle
most of the utility functions of my mud project. But on many other ruby projects i've seen they use the singleton pattern in their classes. Any opinons? I'm assuming David and Tyche will respond. :redface:

The singleton is useful when you want several ways to instantiate the one singleton, but you only want one instance at a time. If the singleton is only instantiable in one way, you might as well have a static class. Of course, the singleton is often used anyhow because it makes it easier at some point to change things than to have to hunt down the static variables. Also, having everything static can encourage somewhat sloppy behavior, due to the tendency of stuffing everything into that one namespace. When there's a singleton, the annoyance of having to do Class::getSingleton().method() can make you think twice about whether you really need it.

In Ruby, you can use the Singleton mixin if you want to ensure that only one instance of the class is created. It marks #new and #allocate as private and creates the instance the first time Class#instance is called. An example of this is the Engine class in TeensyMUD – you need an instance of the class, but you only want one hanging around.

I don't think this would change anything with regard to whether or not you want to use class methods – it's more so in the decision of whether or not you want to ensure only a single instance of a class is created.

here's what i've done so far with class methods.

once the socket object figures out which command the user has typed, instead of
having the player commands in the player class i've created several command classes. i pass the player object linked to the socket and the argument:

Cmd_move.send(cmd.method_name(player, argument))

Cmd_move is one of the 'static' classes, which will contain all the class methods for each move command. above is just a mockup, but i have a case statement that figures out the command type and then sends the cmd with the parameters above.

as david pointed out, i actually saw the wisdom in breaking up the classes for the command types due to the sloppyness factor. i also didn't want to have any namespace conflicts incase there are commands with the same name.

so now that you can see my approach, do you think its fine to do it this way? would singleton be better?

Not quite true since static methods can't be polymorphic. I have an abstract command class from which my concrete command classes are derived, but they're all singletons and instantiated the same way.

Edit: Just noticed we're talking in the context of Ruby, not C++, and I don't know what it's rules are on static methods and polymorphism.

Singleton is one of the most overused of the "patterns" in my experience; most of the times that people think they want to use it, actually they don't.

You use Singleton when there is some sort of state information that is relevant to the function you're calling, and where that state changes over time. Specifically, you use it in cases when there can only ever be one object of a given class at any one moment, but where you can have different instances at different moments in time.

A typical example might be some sort of object representing a database session. If your application works in that way, you will only have one DBSession active at any given moment, but it is possible to close that session and open another one without exiting the application. You therefore have a class method on the DBSession class which returns the currently active session (or nil, if there isn't one). That session might link to things like the current cache, current transation, etc. all of which are cleared down and recreated when you start a new session.