Re: To static or not to static
Wojtek wrote:
If I have a class such as:
------------------
public class MyClass
{
public MyClass()
{
super();
}
public void printThis(String parm)
{
System.out.println(parm);
}
}
------------------
I can run the method like this:
(new MyClass()).printThis("Hello World");
Since printThis only uses passed parameters, I could also have this:
------------------
public class MyClass
{
public MyClass()
{
super();
}
public static void printThis(String parm)
{
System.out.println(parm);
}
}
------------------
and then I can run the method like this:
MyClass.printThis("Hello World");
Both ways are valid, and functionally equivalent. The main difference
being that the first way instantiates a class whereas the second does
not.
Robert Klemme wrote:
static!
It depends!
The example presented does call for static, because there are no thread safety
issues (that I can see), the parameters completely define the data involved
and there is no link whatsoever to any instance information. This reasoning
applies to methods; static variables are a whole lot more troublesome.
Many times I face this choice there is an argument to prefer instance
implementations. It has to do with whether the instance holds state that is
relevant to the method, such as resource handles. It's more object-oriented
to define an object that holds such state than to pass the state separately as
a parameter.
A compromise situation occurs where the static method applies a default
operation on an instance of the same class, such as to provide a connection
string or other lookup of a control parameter. The instance has the option to
use its own version of that lookup, or to use the static default method.
Factory methods, of course, are often static, particularly in the idiom where
the factory method creates instances of its own class.
--
Lew