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.
I would have to put two classes into separate headers in one of the following cases:
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.