Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
3  
    
@MasonWheeler It's not without its advantages though :) –  tux91 May 15 '12 at 23:48
    
Not immediately relevant, but there is a draft proposal to add namespaces to Objective-C. –  Keith Thompson May 15 '12 at 23:59
    
@KeithThompson who is that guy that wrote the draft? Just a random guy or an Apple/LLVM employee? –  tux91 May 16 '12 at 0:01
    
@tux91: I don't know. –  Keith Thompson May 16 '12 at 0:19
show 4 more comments

8 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
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). –  Matěj Zábský May 16 '12 at 8:53
add comment

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.

share|improve this answer
2  
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. –  Jarrod Roberson May 16 '12 at 0:10
    
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! –  Crazy Eddie May 16 '12 at 7:41
2  
"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
add comment

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.

share|improve this answer
    
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
add comment

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.

share|improve this answer
    
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. –  Benjamin Bannier 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. –  Mason Wheeler May 15 '12 at 23:42
    
@MasonWheeler - no, that's meta-data. –  Crazy Eddie May 16 '12 at 4:26
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
2  
No namespaces in objective-c, only stupid prefixes before function names, updated the question –  tux91 May 15 '12 at 23:45
add comment

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.

share|improve this answer
    
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! –  d_inevitable 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 –  d_inevitable 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. –  Crazy Eddie May 16 '12 at 7:48
show 19 more comments

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.

share|improve this answer
    
I would disagree that covering only state qualifies for a class. That would be a struct. Anything more complex than s struct should have behaviour to it. –  tux91 May 16 '12 at 15:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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