Should a class without instance variables be considered a class?

Question

Say you need to implement a few closely related functions that provide a piece of functionality, but there is no need to track any state between those functions, they just sometimes pass some parameters between themselves. What would be the best decision from the design standpoint? Make it a class, or just a separate source file that contains these functions?

UPD: Objective-C, no namespaces

Answer 1

If you're in a language that requires that all functions be part of a class (Java, C#, etc,) you don't have much of a choice but to make them part of a class. Otherwise, just put them in their own file with its own namespace. That keeps things simpler.

Answer 2

You can group those functions into utility classes. Math in Java is a good example of this. It has no state and just lets you make static calls to do things. Putting these related methods in a class makes it clear that they are, in fact, related.

Answer 3

Well it's definitely a class, but I generally wouldn't refer to it as a 'class' in the OO sense of things as they're usually used in different ways.

For instance, in languages that lack free functions like Java, this is the workaround to provide them.

In C++ this is commonly used for function objects.

In your case it seems like a class provides no advantages and so you're better off having them be free functions possibly in a namespace.

Answer 4

Sure! Encapsulating data is certainly not the most important thing about OO!

struct thingy;

void fun(thingy & t) { t.do_stuff(); }

struct thingy {
   virtual ~thingy() {}
   virtual void do_stuff() = 0;
}

struct thingy_d1 : thingy {
  void do_stuff() { std::cout << "Doing stuff.\n"; }
};
struct thingy_d2 : thingy {
  void do_stuff() { std::cout << "Doing other stuff.\n"; }
};

The Command Pattern very often takes this form.

Answer 5

A class defines how objects are created. If the object does not require an internal state, the class won't have any instance variables. There are lots of reasons why this might be useful--things like objects implementing the Strategy pattern spring to mind.

Answer 6

No. That's a namespace. Calling it a class is just silly. Why would you pointlessly wrangle one feature into becoming ... a feature that the language already provides as first class?

Answer 7

There is a major difference that seems to be forgotten about classes vs namespace.

Classes can be extended, where as namespaces can't. Even in the scenario that you describe, it is unlikely that it can be totally ruled out that in future there won't be a reason to extend your group of functions to provide a slightly altered group of functions. And in that scenario the instantiation of the class has a property, which is the type of class.

In some languages where static methods cannot be overloaded in inheriting classes, a class with only static methods could be considered as nothing more than a namespace.

Answer 8

From a design perspective, classes are a way of thinking about the behavior, state, or both of a "something". If the combined functions cover the behavior of "something", then with or without state, you should use a class. If not, then use a file without a class. Using a class to group unrelated functions together should only be done in languages where there's no choice, everything is a class.