this says header files are bad design, but I don't know why. The answers specified there are about the inefficiency of header file when building. Why it is bad design is not really touched upon.
As far as I know:
- headers lets you break the source file up so you can compile smaller things faster
- headers lets you separate the interface from the implementation
- headers lets you specify functionality in only one place. ie. no repeating
Yet using includes, include guards, headers, etc. are considered bad design. How so? What are the alternatives?
-- EDIT: re. DRY issues
A common argument is that it violates DRY in that you repeat changes in signatures in both the .cpp and .h files. However, if the code is designed to reuse functionality specified in outside files, is it not unavoidable that header files must be used?
The question asks why header files are bad design, yet without the headers, is modularity not lost? If modularity is lost, is that not itself a design issue? Thus using header files averts a separate design issue.
Repeating in general is a bad idea, I get that, but it seems unavoidable if you require common functionality. In which case headers are bad, in terms of signature repetition. In terms of how you design your software, I'm inclined to say that splitting code up/modularizing, and reusing code means your code is designed well.
Startup(int iCount)
. And then I discover my class needs something else for this method, say a data structure, like so:Startup(int iCount, void *pS)
. So I not only need to change the signature of the method in the .c/.cpp file but also in the .h file. I am doing the same work in two different files.