Should all methods be static if their class has no member variables

Question

I\'ve just had an argument with someone I work with and it\'s really bugging me. If you have a class which just has methods like calculateRisk or/and calc

Answer 1

While you could use JMockit or any similar tool to mock out the static methods, my own personal choice would be to avoid statics where possible since static methods often increase coupling.

Some of the answers implies that the method is stateless, but I don't really want to see it that way. The method accepts state in form of method parameters. What if those parameters were state in an object instead?

Answer 2

If it is not a clearly requirement to have it as "static" I would recommend you to make them instance.

Not only because this would generate a healthy practice, but, if you're using this in production code that might change in the future, it may happen that some day you really need to change the implementation for an specific module and don't want to break the whole application only for this reason.

Again, this might not happen with your specific code, but I was once in this app with tons of classes like this ( 40 - 60 or more )

A lot of times, having these classes as statics, prevent us from changing some modules easily and causes a lot of misery and tears.

It would've been easier if I could have inject new implementations for those specific parts.

The lines of code of this app in 500k and not all of them were in java which make the refactoring harder.

If you're using this in a 1k line project, then it doesn't matter at all.

Answer 3

The answer is yes and no. It all depends on the purpose of the method behavior. For example:

1. if these methods are simply utility methods then it makes perfect sense to make them static.

2. If the methods represent some sort of business logic of your application (let's say... a web application) then you may want to make them as flexible as possible. In this case, they would become a simple POJO class, as instance methods. This has the not so obvious benefit that they can be converted to Spring transactional beans, or even EJB3 session beans with very little effort. It also makes the methods easier to test. You can also create interfaces for this bean and add additional aspects to it the way you need.

Answer 4

I would make the whole thing static.

Answer 5

The class you describe is simply just a set of functions that operate on inputs only. It's perfectly reasonable to make such functions static methods of a class. Doing so groups them logically and eliminates possible name conflicts. The class in fact acts as a namespace and nothing more.

Answer 6

I recently came across same problem. I was usnig static method. This method basically returns the folder path I need to save all the user defined settings. Now the problem is that I need to write a test case that basically wipes out everything from the folder. I'd definitely not want to delete actual files and therefore I'd want that method to return something else. Yakes .... I can't casue I can't mock the method as it's static. Left with no luck but to change it to a not static method and have the class implement the interface with that method. Then I can easily mock that interface and have the method return any path I want.

End result. Making it a not static gives you more functionality. Make class Singleton and you have everything a static does for you plus loosely coupling.