Java: When to make methods static v. instance [closed]

Answer 1

Two important considerations which have not been mentioned are whether gene1.geneDistance(gene2) is always expected to match gene2.geneDistance(gene1), and whether Gene is and always will be a sealed class. Instance methods are polymorphic with respect to the types of the things upon which they are invoked, but not the types of their arguments. This can cause some confusion if the distance function is supposed to be transitive, but things of different types might compute distance differently. If the distance function is supposed to be transitive, and is defined as being the shortest transformation that either class knows about, a good pattern may be to have a protected instance method int getOneWayDistance(Gene other) and then have something like:

public static int geneDistance(Gene g0, Gene g1)
{
  int d0=g0.getOneWayDistance(g1);
  int d1=g1.getOneWayDistance(g0);
  if (d0 < d1) return d0; else return d1;
}

Such a design will ensure that distance relation behaves transitively, while allowing individual types to report shortcuts to instances of other types that those other types may not know about.

Answer 2

I prefer the second form, i.e. instance method for the following reasons:

1. static methods make testing hard because they can't be replaced,
2. static methods are more procedural oriented (and thus less object oriented).

IMO, static methods are ok for utility classes (like StringUtils) but I prefer to not abuse using them.

Answer 3

public static int geneDistance(Gene g0, Gene g1) would be part of a separate utility class like Collections and Arrays in Java whereas public int geneDistance(Gene other) will be part of the Gene class. Considering you have other operations like "trimmed versions of two genes, finding matches between genes, finding matches between animals (which contain collections of genes), etc" I would create a separate static utility class for them as these operations aren't semantically meaningful to what a Gene is.

If the the semantics of "gene distance" can be wrapped up into your equals(Object o) method then you could consume it there or else include it in your static utility.

Answer 4

The main reason to prefer the instance method is polymorphism. A static method cannot be overridden by a subclass, which means you can't customize the implementation based on the instance type. This might not apply in your case, but it is worth mentioning.

If gene distance is completely independent of the type of the gene, I would prefer using a separate utility class to make that independence more explicit. Having a geneDistance method as part of the Gene class implies that distance is a behavior related to the gene instance.

Answer 5

My rewording of Charle's answer :

If the method in question intends to use the state of the underlying object in any way, make it an instance method. Else, make it static.

Which depends on the way the object's class is designed.

In your case, alphazero, probably the int geneDistance(Gene g0, Gene g1) does not really depend on the state of the Gene instance it is called on. I would make this method static. And put it in a utility class like GeneUtils.

Of course, there might be other aspects of your problem that I am not aware of, but this is the general thumb of rule that I use.

P.S. -> The reason I would not put the method in the Gene class itself is because a Gene should not be responsible for computing it's distance from another Gene. ;-)

Answer 6

I think the problem domain should inform the answer beyond the general stylistic and/or OO considerations.

For example, I'm guessing that for the domain of genetic analysis, the notions of 'gene' and 'distance' are fairly concrete and will not require specialization through inheritance. Were that not the case, one could make a strong case for opting for the instance methods.