posted 4 months ago
Just as a practical observation, more often than not when I've defined a method as a static method I eventually end up having to convert it to an instance method.
There are times when a static method is the way to go, but most often, instance methods are what you'll need.
Here's an example of what I mean.
I define a class for money conversion, Say, US dollars to Euros and back. I could have a class with a static method for each direction.
But currency conversion rates fluctuate. Suppose I have a system where I need to make the conversion in effect at a given time/date? If I made the conversion rate a static property, that would be impossible. But if I made e converter instances, each with its own rate, I could work with a whole set of times and just swap them in and out.
And what if I want to convert to/from Pounds Sterling s in a way I can plug in this alternate converter in place of the original dollar/Euro converter? You can likewise subclass an abstract currency converter for that so that the currency types are also plug-replaceable.
One of the classic cases where I've had to refactor static methods to be instance methods was a temperature converter. You'd think that that would be too simple to make instances of, but again, there are more than just two temperature scales out there.
The problem with getting rid of the "undesirables" is that sooner or later someone will decide that YOU are an undesirable.