Programs are typically broken into pieces in order to make working with them easier. Related bits of code are collected into files, which can then be referred to from other files. However this leads to a problem when the code is collected into a runnable program, because all of the code must be compiled every time.
One solution to this problem is to have the system examine the modification dates of the files that make up the program. However this might tell the system to compile files that have had rather innocuous changes made to them, like fixing whitespace, or adding comments.
The header file provides a solution to this problem by separating out the parts that really have an effect when changed, from those that do not. Typically, header files are used to specify only interfaces, with the implementations left in the main code files.
In this case, they consist of "stub" definitions containing only the definition for the interfaces implemented in the main file, along with documentation for that code. This way the header file only changes if and when the very definition of the code changes, which is the time when other modules must also be recompiled as well. Now the system only has to look at the modification dates on the header files to see what needs to be re-built, which can result in significant savings.
On the downside a header file means two files to modify when a change is made. Newer languages (like Java) typically dispense with header files and instead put a little more smarts into the system to see if the changes really have any effect.
See also: