Essentially, for "public API" type of stuff (whether it's truly a public API, or just a sufficiently self-contained module), I tend to split the interface (header) almost completely from the implementation (source files) whenever possible (except for some one-liner accessors and similar) and trying to also keep the header as readable as possible, so that it can be used as a reference documentation directly.
On the other hand, for "business logic" type of high-level code (and also any internal helper classes for specific single-file module implementation), I just tend to put it directly into source file (or sometimes header files included from the main source file, if the main source file grows too large). This tends to be code that is messy no matter what, so spreading it around in too many files just makes everything even more confusing.
For stuff that's somewhere in the middle between the two, I tend to write headers initially, then as the stuff matures I tend to move larger functions (or methods) into their own source file mostly for the purpose of keeping the header more manageable and for taking advantage of separate compilation (which is useful for speeding up incremental builds, but obviously only when the stuff is mature enough that you're not tweaking it completely).
Anyway, I feel like trying to keep things modular, trying to split stuff into reusable components, is generally more useful than stressing about a particular scheme for organizing files... except as far as it's easier to reuse something if it's in it's own source file, obviously.
