> Newsgroups: comp.lang.java
(Added comp.lang.java. programmer because comp.lang.java is not valid.)
From: "Ted Dunning" <ted.dunn...@gm ail.com>
I should point out that using static methods is often an indication
of poor design.
I respectifully disagree with your generalization. If you are defining
a new data structure, different from anything already available in the
Java API, then it's appropriate to have one or more constructors to
create such structures and one or more methods to provide access or
mutation upon such structures. But if you are merely defining methods
that work with already-existing data structures and/or primitive data
types, that were defined in classes whose source you are not allowed to
modify (and might not even be able to see), then it is impossible for
you to make instance methods for processing those objects, so you have
no choice but to use static methods, which are completely appropriate
for such use.
Note: You might still choose to sub-class the API class, not define any
new data members if you don't need any, but do define additional
instance methods that are available only for types of your sub-class.
One problem with that tactic is that you can't directly apply your
methods to objects of the base class, as you can for static methods.
You can't even down-cast objects of the base class to apply your
derived-class instance methods to them. You need to construct objects
*originally* of your derived class, then you can apply methods of both
base and derived classes. Or if you are given an object of the base
class you need to pick apart all the data members and re-build an
object of your derived class, a royal pain. Better to just use a static
method which can be directly applied to base-class objects.
What indicates poor design is using an inappropriate type of method,
static method when instance method is more appropriate, or vice versa.