views:

517

answers:

5

Is it wrong to have static and non-static methods in the same class?

A: 

I guess not especially when dealing with singletons.

ken
+11  A: 

Not really in regular java programming.

But if you're working extensively with dependency injection you probably have few or no static methods at all. In such a context it's fairly common to have only a few utility classes with static methods, and no other static methods.

krosenvold
+7  A: 

No, it's not wrong. For example, a common use is to have static factory methods in a class definition.

tequilatango
+3  A: 

I think it's fine to create static utils classes, especially when you're not really sure (yet) what the design should be, because you're still learning about the problem domain.

Staticness is a "yet to designed properly" marker. Often the static solution is perfectly adequate; but sometimes, as the project progresses, you find you do have to rewrite that "whole part", but you have (at that later stage) a far more complete understanding of the problem domain, and are therefore in a position to actually design a "proper solution" to those problems.

I think us programmers hammer ourselves unfairly about "rework". You need to do the work in order to understand the work well enough to do the work properly. I see no way past this catch 22;

I can cite many examples of static from the core API. java.lang.Math, java.util.Arrays, java.util.Collections. BUT please note that these classes are "utils classes" which exist only to provide a bunch of static methods. IMHO, The presence of static methods in a "stateful object" is just begging to be refactored.

I'll betcha that todays API designers would love to be able to split-down Integer (and the other wrapper classes)... BUT they're well and truly stuck with what they've got. Which is a warning in itself... that static implies final, and there's a darn good reason that (unlike C++) java methods can be overridden by default. Static is inherently more "binding" than non-static... down the trick you CAN NOT adapt implementations to different situations, contexts, etc, etc, etc.

Cheers. Keith.

corlettk
In "stateful objects", how do you tend to refactor the static methods - move them to helper/util classes or just make them non-static? (How about private helper methods - would you make them non-static regardless of whether they use instance fields ?)
Jonik
If a method doesn't require state the last thing I would do, being a self-confessed dummy, is give it access to state, because then I'd have to worry about the state of the class whilste reading/writing/editing that method (hich could be quite a large chunk). I prefer to split classes into "stateful" and Helper. Witness my current C# project.. A GmlReader (google GML) is a static utils class with one public method: public static IGeometry ReadGeometry(XmlReader reader)... many folks mix serialize and deserialize into the DTO which doesn't scale well to multiple formats. Just how I do it. YMMV.
corlettk
A: 

I believe its a bad idea to have static and non-static methods in the same class with the same name. This can be very confusing. I would suggest trying to make the names different in this case.

Similarly, don't make methods with the same name but different case, or methods with the same name as the class in the same class. Both are legal, and even occur in the JDK, but are confusing IHMO.

Peter Lawrey