views:

210

answers:

3

I have on occasion used a header file purely to import a group of related header files that describe the interfaces on all public components of a module. This was done for convenience. Anyone using the module need only import the one header file.

Is this practice recommended, and if so does said practice have a name? I am trying to name the header files something that explicitly states that they are a group imports and am wondering if there is any convention?

+4  A: 

All Cocoa frameworks do this: For example AppKit.framework contains a header name "AppKit.h" so that one can include all of AppKit using #import <AppKit/AppKit.h>. It simply contains a list of ~ 180 header import statements.

I don't have a name for this pattern but I use it in my own libraries as well (static or framework).

Nikolai Ruhe
+1  A: 

In case of Objective-C the situation is a little bit better with the #import directive, however, in C/C++ this would be a very bad thing to do, since any change to any of the interfaces described in those headers would trigger an inevitable rebuild of all .c/.cpp files including the one you use.
Should you at some point discover things like TDD or at least just unit tests, you'd have to fight with potentially very complicated dependencies introduced by such header.
I would personally recommend to avoid such solutions, unless you know what you're doing.

Dmitry
However if you were talking about using such infrastructure with something similar to SDK/framework, where the interface to a "module" doesn't change, then it sure can make life easier.
Dmitry
Of course every compilation unit depending on the "library header" has to be recompiled when the library changes. Can you explain what this has this to do with TDD? And why is the situation better when using `#import`?
Nikolai Ruhe
I have to apologize first, initially was thinking about a bunch of .c's/.h's/.cpp's or .m's, and "interfaces" in them, not about "libraries" and their interfaces. Secondly TDD was mentioned because of unit testing practices, and I think you'd agree that include dependencies don't help you test your code. And thirdly, the #import directive ensures single inclusion of a header, as opposed to the #include that has to read at least through "include guards" of every header being included, essentially making your build slower.
Dmitry
First I wanted to let you know that you didn't have to apologize, I just wanted to know what you mean. Second, I agree that dependencies should generally be avoided (not only in TDD). Third, gcc and other compilers (or rather preprocessors) know of the header include guard pattern and special case it to avoid reloading the file. The only difference between `#import` and `#include` is that one can omit the stupid include guards in Objective C.
Nikolai Ruhe
A: 

It's OK, but with one caveat: as much as possible, try not to include header files that you don't need.

If fewer headers are included, then there is less dependency on the headers, and hence between modules, and fewer files will need to be recompiled if a header changes.

A common pattern in C for embedded systems is to have one header (provided by the processor manufacturer) which includes all the separate headers defining the registers for the processor's peripherals, with that one header included in every source file. Besides that, source files only include the headers they actually need.

(In the above, "header" means a header file with .h extension, and "included" refers to the #include preprocessor directive).

Steve Melnikoff