Static Vs Instance Methods : Performance

I have often been advised by some code analyzers to go for a Singleton class whenever my class had only static methods. Now, my purpose of having these methods as static is that they are usually utility methods that are passed some arguments and return the desired results, that's it. One of my friends has serious objection to this. He says that he had seen from his experience that if these methods were instance methods, the performance would be enhanced manifold. I must mention that these utility static methods are tucked inside a class that are used by Servlets/Other beans in my web-application.

I tried Googling, it seems to be a good topic to discuss, but none tells me as to which gives better performance. Moreover I don't see any reason why my class should be Singleton just beacuse all the methods it contains are static.
[ July 13, 2004: Message edited by: Yash Sharma ]

There are many considerations that would go into making this decision, but performance shouldn't be one of them. The truth is, in any event, that static methods will be vaguely faster, not slower, than instance methods. The reason for this is that while instance methods have to be looked up at runtime due to polymorphism, static methods don't.

The most important reason I can give you for using a singleton rather than static methods is that it makes testing easier: you can replace the singleton with a test stub if you want to, but you can't do that with the static methods.

you can replace the singleton with a test stub if you want to, but you can't do that with the static methods.

Just out of interest, could you elaborate on what you mean by this?

Makin this up as I go so the examples may be rough ... say you had a PayrollCalculator class that saved its results to a database. Maybe it has a Persistor to do the database stuff. If I'm testing the Calculator class I only want to see what values it comes up with, and I don't really care about the database right now. Maybe I can write a test like:

The calculator called the Persistor API on the mock (fake) persistor. The mock didn't write to the database, but stored the payments in a List or something where I could check on them later. Now I can test with no database, maybe even before writing the real Persistor or building the database.

This is possible if Persistor is a regular class (singleton or not) that implements an interface or extends a base class. It is not possible if Persistor is a utility class with all static methods because I can't override statics or substitute another class as easily.

Zat make sense? See how a desire to write the test first would lead me to code to interfaces? As one friend used to say: "Cool beans!"
[ July 13, 2004: Message edited by: Stan James ]

Stan -- couldn't have said it better meself.

I suppose that's useful... but you can (neeeearly) just as easily replace a class with static methods with one with blank static methods of the same name. Not quite as OO, I suppose.

What Stan's example emphasises more to me is the usefulness of singletons as a means of registering a service class with multiple client classes. The service class could be a specific implementation (following the persistence example) for Oracle or Sybase databases or whatever, as long as it implemented the "persistence" interface the clients are expecting.

The thing I can't do with statics is set the persistor at runtime.

I can only do that with an object instance. There are some interesting papers around the web on "inversion of control" with examples like this. Calculator doesn't control how things are persisted. The real system or my test driver does "dependency injection" by inserting a class that was unknown at calculator compile time. I've done a couple things lately with "application assemblers" that insert strategies and the like from configuration data. There is a lot of stuff like this:

We use the assembler to manage pluggable components and test components. It's pretty slick once you get into it.

At work, we're being encouraged to do something like this:

So to mock something, you just call setImplementation(myNewImplementation), whether the methods involved are static or not. This allows us to avoid making methods nonstatic merely for testing purposes. Of course it's completely useless if we need to mock a third-party class which didn't follow this paradigm. But it works well enough for classes we develop in-house. Seems to require slightly more verbosity inside the class we develop, with the benefit of having more flexibility in the API of the mocked class. I'm still not sure which I prefer. Does anyone know of a name for this pattern? Or the "standard" mocking patterns it replaces? (I.e. you either extend the class you want to mock, or you make sure the mocked class implements an interface which you can provide an alternate implementation of.)

My first gut reaction to this is pretty negative ... which tells me I should think about it a few days. So often that just means i don't get it yet.

Check out this article over at Object Mentor. There's lots of other good articles there too.

sev