I’ve been meaning to get this off my chest for years. Header files are stupid.
I view header files as abstractions of programming code. In Cocoa, they not only tell the compiler what lives in a class file, but also tells Interface Builder what objects and messages it can use. Plus they let a human quickly determine what a class does. So it serves a tremendously important purpose.
But they’re still stupid. They shouldn’t need to exist. My problem is a conflict with my general theory of duplication – nothing should ever be typed twice. If data exists in one form, and it is needed in another form, that’s work a computer should do. Not a human.
If I have a class file I, even in my lowly state of knowledge, can create a corresponding header file. This isn’t an exercise of the mind, it’s menial duplication. Copy/paste with finesse.
Thinking in the opposite direction, if I have a header file, I can create the template of the class file. Not the code guts of course, but the raw objects and methods.
So why do I need to do this? Why can’t the computer? In my travels I’m certain to run across situations that might not fit the 100% bidirectional header<->class correlation. So fine, provide some manual override if needed.
Interface Builder gets a partial pass on this complaint. It can write a basic class file structure from within, based on the GUI. But only once; after that you’re supposed to do all editing in XCode (although I have successfully merged code from successive rewrites). One step in the right direction.
So in my ideal world, the header<->class<->IB relationship would be automated and semi-transparent to the programmer. Create anything anywhere, and all the other stuff should just populate. IB would be a bit more complicated but I think it could be done. But header<->class is an abstraction relationship which humans shouldn’t be bothered with.
I fully expect to re-read this when I’m smarter and be thoroughly embarrassed.