I would say that just by reading your analysis, you're saying there are alot of static methods and singletons. Static methods shouldn't be an issue by themselves, but if they're being used to proxy calls to the singleton objects, I would work on making those either rock solid, or replacing them with a more sane object model.
Static methods are useful for purely functional purposes, and you'll find both the Scala and Clojure programming languages to use them alot, mostly because they don't need to worry about mutable state.
Reading from this blog post on Java Static/Class methods(I've highlighted a relevant bit):
Static methods use no instance variables of any object of the class
they are defined in. If you define a method to be static, you will be
given a rude message by the compiler if you try to access any instance
variables. You can access static variables, but except for constants,
this is unusual. Static methods typically take all they data from
parameters and compute something from those parameters, with no
reference to variables. This is typical of methods which do some kind
of generic calculation. A good example of this are the many utility
methods in the predefined Math class. (See Math and java.util.Random).
Preferably, rather than providing properties that specify how the object should be treated, the class-dependent behavior should instead be encapsulated inside an abstract method. For example, use:
obj.doSomething(); // Abstract method - subclasses override with appropriate behavior
instead of:
if(obj.getModelGroup() == ModelGroup.MyGroup) {
doSomethingWith(obj); // Behavior specific to one subclass
} else {
doSomethingElseWith(obj); // Behavior specific to another subclass
}
Having said that, there are perfectly legitimate cases where implementers of a method might not use instance-specific state.
As an example, consider the java.sql.Driver interface (it's not an abstract class, but it easily could be). If you have a separate class for each type of driver, its methods probably don't require any instance-specific state. The jdbcCompliant
, getMinorVersion
, and getMajorVersion
methods likely return hard-coded constants. The acceptsURL
and connect
methods likely have behavior that isn't instance-specific.
In short: it depends. Not using instance state in an abstract method implementation isn't inherently wrong; however, in some cases it may indicate that your code could benefit from being restructured.
Best Answer
In most OO languages, when you define a method inside a class, it becomes an Instance Method. When you create a new instance of that class, via the
new
keyword, you initialize a new set of data unique to just that instance. The methods belonging to that instance can then work with the data you defined on it.Static Methods, by contrast, are ignorant of individual class instances. The static method is similar to a free function in C or C++. It isn't tied to a specific instantiation of the class. This is why they cannot access instance values. There's no instance to take a value from!
Static Data is similar to a static method. A value that is declared
static
has no associated instance. It exists for every instance, and is only declared in a single place in memory. If it ever gets changed, it will change for every instance of that class.A Static Method can access Static Data because they both exist independently of specific instances of a class.
It might help to look at how you invoke a static method, compared to a instance method. Let's say we had the following class (using Java-like pseudocode):
Update
As COME FROM points out in the comments, a static method is capable of working with non-static data, but it must be passed explicitly. Let's assume the
Foo
class had another method:Add
is still static, and has novalue
instances of its own, but being a member of the class Foo it can access the privatevalue
fields of the passed-infoo1
andfoo2
instances. In this case, we're using it to return a newFoo
with the added values of both passed-in values.