views:

277

answers:

4

I have to implement a set of 60 functions, according to the predefined signatures. They must be global functions, and not some class's member functions. When I implement them, I use a set of nicely done classes provided by 3rd party.

My implementation of most functions is quite short, about 5-10 lines, and deals mostly with different accesses to that 3rd party classes. For some more complicated functions I created a couple of new classes that deal with all the complicated stuff, and I use them in the functions too. All the state information is stored in the static members of my and 3rd party's classes, so I don't have to create global variables.

Question: Would it be better if I implement one big class with 60 member functions, and do all the implementation (that is now in the global functions) there? And each of the functions that I have to write will just call to the corresponding member function in the class.

A: 

I think that the "one class one responsibility" rule should guide you here. The 60 functions can probably be divided into different responsibilities, and each of those deserves a class. This will also give a more OO interface to clients of the API that are not constrained by the need of global functions.

On Freund
@On, Are you suggesting 60 classes for 60 methods ? As earlier responses suggested, the functions need to be wrapped in a namespace, instead of going crazy with classes.
Jagannath
Of course not, but with 60 classes there are bound to be some distinct responsibilities (probably somewhere between 4 and 15).
On Freund
+2  A: 

Do the users of your code really need this big class?

If yes, implement it.

If no, don't waste your time on implementing it and don't waste the time of others mandated to test it or trying to understand what is the exact role of this class beyond the OOP look.

mouviciel
+4  A: 

All the state information is stored in the static members of my and 3rd party's classes, so I don't have to create global variables.

That is the keypoint. No, they should definitely not be put into classes. Classes are made to be used for creating objects. In your situation, you would use them just as a scope, for the data and functions. But this is what namespaces already solve better:

namespace stuff {
    ... 60 functions ...
    namespace baz {
        ... if you want, you can have nested namespaces, to ...
        ... categorize the functions ...
    }

    namespace data {
        ... you can put data into an extra namespace if you want ...
    }
}

Creating classes that consist purely only of static members is a bad idea.

Johannes Schaub - litb
+1  A: 

litb is probably correct. The only reason that you would even consider wrapping a class around a bunch of free functions is if you need to attach some of your own data for use in your wrappers. The only thing that pops into my head is if need a handle to a log file or something similar in the wrappers.

On a related note, fight the temptation of using namespace stuff;! Always refer to the functions using namespace qualification:

#include <stuff.h>
void some_function() {
    stuff::function_wrapper();
}

instead of:

#include <stuff.h>
using namespace stuff;
void some_function() {
    function_wrapper();
}

The benefit is that if you ever need to convert the namespace to a class full of static methods, you can do it easily.

D.Shawley
Disagree. Converting a namespace to a class full of static methods is hardly ever done. There is only one valid reason to do it, and it is _not_ about attaching your data for use in the methods. It's when you want to pass the resulting class as a template argument (poor man's Strategy pattern).