Static functions vs classes

Question

Let's say that I want to build some utility functions to do some basic maths with the BigDecimals, for example I want to have a function that computes the average of a List<BigDecimal>.

What is the best approach? A static function or a utility class?

public static BigDecimal computeAverage(List<BigDecimal> numbers)

or

public class BigDecimalUtil

public computeAverage(List<BigDecimal> numbers)

Answer 1

I'm probably going to give away my C# leanings in the worst possible way, but I'd always recommend static methods within utility classes. This gives you the best of both worlds. The organizational benefits of the class with the usability of methods accessed without needing to instantiate an object to use them. If your utility class has a reason to occasionally vary its behaviour, then you are already well positioned to do so by introducing inheritance/interfaces later should you need to. If you wish your design to be a little more portable, then you'll find the paradigm will more easily transfer to other OO languages.

Answer 2

If you want to do utility functions, connected by some theme, make a class for them, make them static in that class and make a constructor of that class private, to eliminate the possibility of accidental giving out an instance. So, use the second variant, but hide the constructor.

public class BigDecimalUtil

public computeAverage(List<BigDecimal> numbers)

private BigDecimalUtil(){super();}

There is one more possibility - to make no constructor and make this class abstract. But on this way you can't use instance of the class not only outside, but also inside it. So, I think, this second variant is too strict for you. Choose yourself.

Answer 3

I agree with @Gangnus that a static "wrapper" class makes sense if individual class methods will always be used in isolation, and this is often going to be a good answer.

However, there might be some value in a non-static class, with non-static methods, if you have related calculations likely to be used together. For example, construct a ListStatsUtil object with List<BigDecimal> passed into constructor, it might be convenient to access getStandardDeviation, getVariance, and getAverage in sequence without passing back in the object. This may be more elegant, but might also perform better, especially if computationally expensive operations are involved that can be optimized across operations by sharing private state within the object.

public ListStatsUtil {
    private final List<BigDecimal> numbers;
    public ListStatsUtil(List<BigDecimal> numbers) {
        this.numbers = numbers;
    }
    public BigDecimal getAverage() {
        // return average of this.numbers
    }
    public BigDecimal getStandardDeviation() {
        // return std dev of this.numbers
    }
    public BigDecimal getVariance() {
        // return variance of this.numbers
    }
    public BigDecimal getMax() {
        // return max of this.numbers
    }
    public BigDecimal getMin() {
        // return min of this.numbers
    }
}

Answer 4

I voted for codingoutloud answer and I'd like to expand on it a little.

Wrapping collections in classes is something I've come to try to always do--my rule is "Never pass a naked collection". The biggest failures of OO I've seen is when people are afraid to add methods where they belong. In your case the methods belong on the collection (Totally obviously if you think about it), so put them there by wrapping the collection, and to put the icing on the cake, only expose the functionality you need outside your new class (as codingoutloud did) so that you can look at your single, small class and easily understand everything manipulating that collection.

You don't have to solve every possible problem because it's all your code, you can edit the collection wrapper just as easily as you can edit the other classes that interact with it. This lets you pull other code into the class as necessary--if you don't ever expose the collection it will become quickly obvious what code belongs in the wrapper.

This also gives you complete control over the collection so you can prevent it from getting into a state inconsistant with it's function (For instance, if no entry in the collection can be null, just prevent anyone from putting a null in!)

Most of the bad OO code I've ever seen has been created because someone chose to write static utilities or inline code that belonged in objects they couldn't add code to instead of wrapping the offending objects in code of their own that they could modify.

Answer 5

If I'm not wrong and Java cotinues to be a pure OO language, you cannot have functions without wraping them in a class.

So your answer is: both, a static function wraped in a static utility class, not unlike Math class.

Answer 6

How about a CalcAverageStrategy interface that is injected, and you can then have mean/median/mode implementations injected where necessary.

Each implementation is easy to test, and also easy to mock for testing.