Static (class) methods have both advantages and disadvantages. I do just about all of my software development using an agile, test-driven approach, and I find that my designs still find a use for static methods.
The main advantage of a static method is that it does not need an object instance to be constructed in order to use it. This means it can be used from anywhere in the system without either: passing in an object (clutters constructors and/or method signatures), creating an object just to discard it (a pointless waste of resources), or messing with Singletons (vastly overused, dangerous, and a candidate for "anti-pattern" status).
The main disadvantages of a static method are that: (a) it ties the client code to a particular class implementation, thus preventing substitution with a different implementation at run time (b) it prevents child classes from overriding the behaviour, and thus severely limits the options for
polymorphism. These make static methods a poor choice for behaviour which might benefit from being replaced for testing or for configuration using run-time "wiring" or compile-time overriding.
For me, static methods still have their place, though. Static methods are really good at making small chunks of general-purpose behaviour available to many places in a class hierarchy. For example, I use static methods for the following common situations:
Converting an object to a printable
string representation without risking NullPointerExceptions:
Converting a string to an integer and gracefully handling missing values or parse problems:
And so on. Each of these cases would otherwise clutter up the application with "copy and paste" boilerplate code.
These static methods are small enough, fast enough, and simple enough that I feel I can rely on their unit tests to ensure that they work correctly, then just use them wherever required. For me, something such as:
Seems a pretty good expression of my intent.
Do I make sense?