CODEWITHSUNDEEP
springoopstatic
Jeremy
Jeremy

Reputation: 5435

Is it reasonable to use a non-static class if that class does not contain state?

At my workplace there seems to currently be a crusade against static classes. I can understand part of that, they do sort of break the whole unit testing modularity thing. However, I am seeing an influx of code reviews that call for removing static classes.

A common case is a utility class this is spring-injected with a few other objects that are "known" at compile-time. It has no other member variables. If class M is calling this static class, I always see the suggestion to make this utility class non-static and inject it into class M.

This doesn't make sense to me. I don't particularly see anything wrong with it other than that it seems a waste of time and makes utility class less easily usable. As far as I can tell the justification is usually for unit testing, but I don't like the idea that valid code has to be changed to conform to a testing paradigm. Admittedly mocking a simple static utility class would probably be overkill.

Are static classes appropriate in this use case, or best avoided?

Upvotes: 3

Views: 141

Answers (6)

casablanca
casablanca

Reputation: 70711

Admittedly mocking a simple static utility class would probably be overkill.

You're absolutely right on this. Static classes should only be used for utility classes that are extremely simple, where there is no benefit of mocking such a class. If you're using them for any other purpose, you should rethink your design.

Is it reasonable to use a non-static class if that class does not contain state?

This really has nothing to do with state. For example, strategy objects often contain no state, yet they are not static; they usually implement a common interface and need to be interchangeable / mockable.

Upvotes: 1

Dave Newton
Dave Newton

Reputation: 160231

Depends, naturally.

  • How do you want to test the code that uses the static classes?
  • Do the static classes encapsulate behavior you'll need to mock often?
  • Will anybody ever need to modify the behavior of those static classes?

Finally:

  • Is there a compelling reason not to inject a Spring-managed singleton bean?

Upvotes: 1

nicholas.hauschild
nicholas.hauschild

Reputation: 42849

I avoid using static classes (assuming we are actually talking about classes that contain static methods), and I do it for the sake of testability.

If you are using static methods, you will have a difficult time mocking/stubbing the portion of your code that uses said static for your unit tests.

Consider this:

public String myMethod() {
    String complicatedStringOutput = MyUtility.createComplicatedStringOutput();
    //do some more complicated work on this String
}

To write a unit test for this method, how would you go about making it a 'true unit test' without needing to also test the creation of complicatedStringOutput? In my unit tests, I prefer to test only the method that is the focus of the unit test.

Change it to this:

public String myMethod(MyNonStaticUtility util) {
    String complicatedStringOutput = util.createComplicatedStringOutput();
    //do some more complicated work on this String
}

Suddenly, this class is much easier to write a 'true unit test' for. You can control the behavior of MyNonStaticUtility by either using a stub or mock.

All that said, it is really up to you (or your Business Unit). If you value unit tests and feel that it is important to have good test coverage of your complicated code, this is the preferred approach. If you do not have time/money to invest in 'fixing' your code, then it just won't happen.

Upvotes: 1

Facio Ratio
Facio Ratio

Reputation: 3393

If you pretend for a moment that your static class did not belong to you, that it was, say, part of the .NET framework, how would your team handle it? Their answer would be my answer. In other words, if their answer to that question is inconsistent with what they're asking you to do, then they should probably either change how they work with .NET static classes or with how they work with yours.

Upvotes: 1

Matt York
Matt York

Reputation: 16261

I think the differences in the two approaches are small, but as long as the class contain no state it is slightly better to make it static. Let's say I have this code in class A: 

StaticClass.utilMethod()

If I want to use this code in class B I can copy and paste. That's it. No adding member variables, injection, etc. cmd-c cmd-v.

Considering your existing code uses static classes and modifying that will take work, it's definitely best to continue using static classes.

Upvotes: 2

Bharat Sinha
Bharat Sinha

Reputation: 14363

I vote for using the static classes... i.e. A class with just static methods for purely Utility purposes. Even java has provided us such classes like java.util.Collections and java.util.Arrays

Upvotes: 1

Related Questions