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


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.

  • 1
    Yeah, that's exactly what I thought initially, keeps things simpler
    – tux91
    May 15 '12 at 23:42
  • 1
    Yeah I don't know why people are allergic to stand-alone functions.
    – Doug T.
    May 16 '12 at 0:39
  • I also find the class approach preferable in languages which don't have namespaces (like PHP <=5.2). May 16 '12 at 8:53
  • @tux91: so what do you think now?
    – user186205
    Feb 4 '16 at 18:41

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.

  • 4
    Math in Java is a good example of a terrible, terrible design. Not something I'd ever want anyone to follow.
    – DeadMG
    May 15 '12 at 23:44
  • 2
    Regardless of religious opinion about utility classes in Java; this is the idiom that is historically most correct for Java.
    – user7519
    May 16 '12 at 0:10
  • 1
    Java has a lot of weird things people do in order to work around the fact that everything has to be a class though. You've shown one...another are objects with nothing but get/set pairs for every variable in the class. That's a record, not a class! May 16 '12 at 7:41
  • 3
    "things people do in order to work..." you could stop right there @CrazyEddie - as Stroustroup said, there are only two kinds of languages: the ones people complain about and the ones nobody uses.
    – gnat
    May 16 '12 at 7:56

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.

  • Could you elaborate on that example? At least in C++ one would use std::function or boost::function to store functions, so the advantage of what you show isn't really clear. May 15 '12 at 23:37
  • McConnell says that if only one object of a particular class in going to be created that it probably should even be in the app's class hierarchy, with the exception of singletons
    – tux91
    May 15 '12 at 23:37
  • Not that he's an absolute authority to me or anything, just saying. Something kinda seems funky to me about classes with no internal state
    – tux91
    May 15 '12 at 23:41
  • Your example does have state, actually; you just don't see it because the compiler generates it behind the scenes. But in order for the virtual methods to work, there needs to be a vtable, and a vtable pointer on the thingy. That's state data. May 15 '12 at 23:42
  • @MasonWheeler - no, that's meta-data. May 16 '12 at 4:26

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.

  • That's what I thought too. Problem is, I program in objective-c, which doesn't have namespaces. Also, going with free functions they would have to be C-style functions as opposed to objective-c-style functions, which have named parameters, which I think is very convenient. On the other hand, this would entitle me to use static methods and the whole thing will just look like it's dealing with objects, which it is really not.
    – tux91
    May 15 '12 at 23:22
  • @tux91 Classes tend to be a poor replacement for namespaces, although I don't know enough ObjC to know what's best in your case.
    – Pubby
    May 15 '12 at 23:26

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.

  • This specific set of functions is for a specific task that will only be used in one place of the source code, and there's really no point of having just one subclass of a class
    – tux91
    May 15 '12 at 23:59
  • @tux91 do you mean in your scenario there is no point of having just one subclass of a class? if not, i disagree, unless the base class is abstract. If you are so absolutely sure that there is not any possibility of an use for subclass, then you should probably use prefixes to your functions instead! May 16 '12 at 0:05
  • Why would you want just one subclass of a class? Put the subclass functionality in the base class, and therefore reduce the complexity.
    – tux91
    May 16 '12 at 0:09
  • 1
    let us continue this discussion in chat May 16 '12 at 1:41
  • 1
    @tux91 - "Why would you want just one subclass of a class? Put the subclass functionality in the base class, and therefore reduce the complexity." -- Because you might want to keep the base's clients from coupling to behavior they don't need. -- " You break the interface by altering existing behaviours." -- Not true at all. You break an interface by violating its contract. The whole entire purpose of polymorphism is the ability to change behaviors. Displaying data on a printer rather than screen, for example. May 16 '12 at 7:48

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.


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?

  • 2
    No namespaces in objective-c, only stupid prefixes before function names, updated the question
    – tux91
    May 15 '12 at 23:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.