Separate header files for concrete classes - C++

Question

Background

I have an abstract class, something like

class IConverter{
    public:
    virtual void DoConvertion() = 0;
};

There will be many concrete classes which just implements DoConvertion method.

class TextConverter : public IConverter{
    public:
    virtual void DoConvertion(){
         // my code goes here
     }
};

class ImageConverter : public IConverter{
    public:
    virtual void DoConvertion(){
         // my code goes here
     }
};

There will be many concrete implementation like this. I have created a header file say, CharacterConverter.h which has the abstract class IConverter.

Question

Since my concrete classes just implement the DoConvertion method, is it required to create separate header files for each concrete class? I mean is it required to create ImageConverter.h, TextConverter.h and so on for all concrete classes? All these header files is going to contain the same code like IConverter abstract class.

Any thoughts?

Answer 1

The best answer to this is what's easier to read. One long source file is going to be difficult for you and other programmers to follow. On the other hand, many tiny (half screen-full) source files is just as bad.

Answer 2

One of the main points of creating an interface class is so that clients can be depend on the abstract interface rather than the concrete implementation, and you are then free to change the implementation without impacting clients.

Putting the concrete declarations in the same header files as the interface declarations defeats this, so now if you change an implementation detail of a concrete class, your clients would need to re-compile.

Answer 3

You'd probably be better off using factories or function pointers.

However, one particularly nasty way that springs to mind is using a macro to declare your concrete classes. For example:

At the bottom of IConverter.h include the following macro

#define DECLARE_CONVERTER_CLASS(CLASS_NAME) \
class CLASS_NAME : public IConverter\
{ \
    public: \
    CLASS_NAME() {} \
    virtual void DoConversion(); \
}; \

Then in MyConverter1.cpp

DECLARE_CONVERTER_CLASS(MyConverter1)

virtual void MyConverter1::DoConversion()
{
    ...
}

Yuck :-)

Answer 4

It is not required. It's basically a judgment call.

If the implementation is simple for each class you can put them all in one .h and one .cpp

If the implementations are a bit longer, then it's probably cleaner to use a separate .h and .cpp file for each.

Some advantages of using a different .h/.cpp for each class:

• It will keep the code organized and clean
• Reduced compiling work: A change in one of the implementations won't need to recompile all others
• Faster compiling time: Several compilers can compile multiple files at once such as Visual Studio's /MP switch. With several files you'll have a faster compile time.
• Other files can include only what they need instead of everything
• Faster link time: Linking time will be reduced due to incremental linking
• Using version control you can look back on only the changes to a particular derived class, instead of having to go through all changes made to the massive 1 .h/.cpp file to find that one change in a particular derived class.

Answer 5

You'll probably get answers both ways.

I'd say, for any trivial converters, having all of them in a single .h/.cpp pair is sufficient and that it's overkill to split every one into a single pair. I think the tradeoff of maintenance of lots of files vs. maintenance of a bunch of methods within a single file is worth it in this case.

Complex conversions probably deserve their own file pairs.

Answer 6

You will need definitions of the concrete classes to create objects, so you'll need to put those definitions into a .h file somewhere. Which file you put them in is up to you.