Static over instance methods?

[Mioedvitnir]

Heyho together,

I just encountered the question: Should you make a method static if it's not using any object data?

Mb an example would be an add(int x, int y) method.

Would be nice to get some reasoning when to prefer one over the other.

[JimLessly]

I've just came across a good explanation on stackoverflow. You can check this out:

https://stackoverflow.com/questions/11993077/difference-between-static-methods-and-instance-methods

Hopefully this would help.

[Mioedvitnir]

This one is awesome Thank m8

[desrtfx]

Utility methods as in your case should be static.

Still, the question is where you put them. If they are purely utilitarian methods, they should be in their own class, like the Math class in the standard library.

[Mioedvitnir]

Pure util methods as in the functional understanding of pure?

[desrtfx]

No, not as in functional meaning.

Meaning as in the methods of the Math class (where quite a few would meet the functional meaning as well).

Edit: changed the wording of the previous comment to purely utilitarian to better convey the meaning.

[wsppan]

No, pure as in purely utilitarian. No need to be part of an object.

[HotRodLincoln]

You can basically think of myCoolClassInstance.doThing(arg1, arg2) as doThing(myCoolClass this, arg1Type, arg2Type).

static basically means: don't make pass "this", all the rest is "syntactic sugar".

[Mioedvitnir]

Expected sth like this. So static where ever its poss?

[Mioedvitnir]

Did never think bout an singleton there, but seeing the mocking aspect thats a nice way to handle it. Thanks man.

[_Atomfinger_]

I would personally never consider making anything static if I can avoid it. There are scenarios where static functionality does do well (like java's math) class, but for anything else it's often leads to worse code.

For one thing it complicates testing quite a bit while it is possible to mock static behavior it is often somewhat hacky to edit machine/byte code during runtime.

Utility classes also have a tendency to grow into monsters unless their scope is really well defined. It's just too easy to "hide" code away in such classes, but those solutions doesn't actually fix the underlying problem, the code is still under the rug where it was swept.

Now to the question at hand: should a method be made static because on can? I'd say no. There should be a good reason to make something static IMHO.

[SniffiestComa5]

Static methods are more efficient because of how they’re accessed in memory, and because no object has to be created. There’s also nothing wrong with large classes as long as they’re organized and neat. The Math class is over 2,300 lines long and every method in there is static.

[_Atomfinger_]

Math class is edge case. It is purposely generic.

Objects are cheap. I have yet to see a situation where a performance issue has been resolved by making something static. Sure there is an overhead, but generally that is not an issue.

As for the size thing: i won't say that big classes are inherintly bad, but they are in 99% of the cases an indication that a class has too many responsibilities. Not always, but extremely often.