4

I know that static methods/variables are associated with the class and not the objects of the class and are useful in situations when we need to keep count of, say the number of objects of the class that were created. Non-static members on the other hand may need to work on the specific object (i.e. to use the variables initialized by the constructor)

My question what should we do when we need neither of the functionalities?

Say I just need a utility function that accepts value(s) and returns a value based solely on the values passed. I want to know whether such methods should be static or not. How is programming efficiency affected and which is a better coding practice/convention and why.

PS: I don't want to spark off a debate, I just want a subjective answer and/or references.

gnat
  • 21,442
  • 29
  • 112
  • 288
Vedant Agarwala
  • 775
  • 1
  • 8
  • 16
  • 3
    related http://programmers.stackexchange.com/questions/134448/where-should-i-put-functions-that-are-not-related-to-a-class – jk. Jul 04 '12 at 09:20
  • see also: [Can't I just use all static methods?](http://programmers.stackexchange.com/q/98083/31260) – gnat Jul 14 '13 at 20:13

4 Answers4

4

Methods which are not attached to any specific class like these are called "free functions", and as you have adequately noted, OO does not provide for them, and some languages also do not provide the facilities for them.

In a language like C++ you can just place the function in a namespace. But if you're working in Java or C# you must pointlessly place them in a class and make them a static member for no good reason at all.

DeadMG
  • 36,794
  • 8
  • 70
  • 139
  • Yes I had thought the same but I wanted to know does making them static use less or more memory and/or CPU time. And as we can see the newer languages (including C#) are removing support for functions. There must be a good reason for this – Vedant Agarwala Jul 04 '12 at 09:16
  • 1
    nope, no memory or speed issues the only effect it may have is it may make the compiler ever so slightly simpler to write if functions are always in a class – jk. Jul 04 '12 at 09:18
  • 7
    The Internet is a very negative place... If you don't like a design decision, that doesn't give you an excuse to slander the designers. Have you sat down and had a long conversation with the designers of C#? Until you have, you have no room to say their decisions were pointless or they were incompetent. If you disagree, do it respectfully. – Phil Jul 04 '12 at 11:55
  • 1
    @Phil: Sorry. I guess that when they came to design their Standard library and somebody said "What do we do about `sin`", it's perfectly OK for them to have just completely ignored it and pretended that it did belong in a class. No problem at all. It's not blatantly obvious whatsoever that `Math` is just a namespace. – DeadMG Jul 04 '12 at 14:34
  • 1
    see also [Why C# is not allowing non-member functions like C++](http://stackoverflow.com/q/1024171/71059), and [Eric Lippert's followup blogpost](http://blogs.msdn.com/b/ericlippert/archive/2009/06/22/why-doesn-t-c-implement-top-level-methods.aspx) – AakashM Jul 05 '12 at 14:41
  • 2
    @DeadMG I know that all good programmers should have something of an ego, maybe even a superiority complex - but calling people such as Anders Hejlsberg 'hardcore incompetent' is just taking it to the extreme. – MattDavey Jul 05 '12 at 15:39
  • @MattDavey: When you make gigantic cockups, like this one and shipping without generics, then people get a very negative opinion of your skills. That's what happens. – DeadMG Jul 05 '12 at 20:31
  • @DeadMG some people will have negative opinions about almost anything - thankfully most of them choose not to share those opinions with the world in such a belligerent manner. Please keep your comments constructive. – MattDavey Jul 06 '12 at 09:23
3

It's pretty standard in Java to make such methods static and put them in "classes" with other static methods. You certainly wouldn't want to make the methods non-static--you'd confuse everybody, including the optimizers. I suppose the designers could have thought of a name besides "class" ("namespace"?) to hold these methods/functions, but most of us have enough to remember as is. I'll admit, having to add a private constructor to a "static" class seems a bit silly, but it gets the job done without adding new rules.

C# is a bit more explicit, with a static class (no double quotes around static), no need for a private constructor, and enforcing of the static-methods-only rule.

(Java has a "static class", but it's something completely different, primarily intended, no doubt, to confuse discussions like this one.)

RalphChapin
  • 3,270
  • 1
  • 14
  • 16
1

If those utility functions are relatively small and not similar to others then you can use static functions. Also, the most important thing, they should not be related with the abstraction of the object (the class) and also you should not abuse them; they do not represent a OOPish way of programming.

I mentioned about size, because if they are large then you should use objects in order to obtain a better cohesion (share some data between functions by instance variables). I mentioned about similar functions because you might want to use the power of polymorphism.

Regarding efficiency static methods might be a little faster, but you would not gain any considerable performance gain from this.

Random42
  • 10,370
  • 10
  • 48
  • 65
1

Continuing with the example of System.Math in C#, some languages such as Nemerle allow you to add a using statement which effectively lets you use a classes behaviour as free functions, as well as direct access to its constants & other static members.

using System.Math // using statement at class level

public class Example
{
    public TestMethod() : void
    {
        def radians = Pi; // direct access to Math.Pi

        def x = Sin(radians); // direct access to Math.Sin & Math.Cos
        def y = Cos(radians);
    }
}

In essence this allows you to treat a class as a namespace, which as DeadMG pointed out is basically what System.Math is...

MattDavey
  • 7,096
  • 3
  • 31
  • 32