Question

I have a base class called EventArgs. Derived from this are many, many specializations that represent event arguments for a particular kind of event. Consumers of these events may need some, many, or very few of these argument classes.

My question is, would you provide a header file for each type (e.g, 50+ header files for the varying ones), would you try to group them in to families and have a 'common' header file for those, or would you throw caution to the window and throw them in to one easy-of-use header file that can just be included?

Another approach might be to have 50 header files, and then I could introduce some "family" header files that included particular ones. Not sure about the naming conventions for these kinds of things so it is obvious what is where.

I know there may not be a hard and fast rule, but wondering what other developers have done when they find themselves writing many little classes.

Thanks in advance.

Was it helpful?

Solution

I would have to put two classes into separate headers in one of the following cases:

  • they are huge
  • they are unrelated or unlikely to be used together
  • each of them introduces its own header dependencies

Otherwise, it does not make much sense to separate them. I know some people have this "one class per header" rule, but it does not look reasonable in your case.

What is for "families" including plenty small files, in certain build systems (and file systems) this might have impact on compilation time, and in any case I don't see a point in doing this - usually people will use documentation or IDE to find classes, not looking at headers file names. So you would only do that to simplify inclusion, but then why not putting them into the same header.

OTHER TIPS

I would group them in families according to classes that users would likely want to use together. 50+ tiny header files seems excessive in any case.

Couldn't all the variants be templates?

I've been in a similar situation where I was developing a GUI library. Initally all components (they were small classes) were sharing the same header and source file. This worked pretty well. I later attempted to put them in separate files but it really didn't improve anything. It only added the burden of spending a lot of time searching through these files.

That aside, maybe you can draw some inspiration from Poco C++ library. This library usually follows the one class per header idiom, but there are exceptions. For example the entire exception hierarchy is coded on one header and source file using a macro based system (see Exception.h and Exception.cpp).

if they belong to same inheritance hierarchy, put them to the same .h file. It helps you decide correct order for the classes. One of the less known compile-time checking in c++ relies on the correct order of classes in .h file.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top