On Fri, 2005-01-07 at 21:55, Bob Jamison wrote:
Bryce Harrington wrote:
This is a technique where a main header is kept extremely terse using forward declarations of classes instead of having to include the respective header, and by moving private details of a global class out into an 'Impl' object (see the Inkscape::Application class in inkscape_gtkmm for an example).
I would like to amplify that, going so far as saying that any major API item should be separated into interfaces and implementations; the interfaces being pure virtual with -NO- link dependencies.
Indeed. I think this should go in our coding style document (there should of course be exceptions for things like certain types of simple utility classes or generic algorithms).
One other thing to consider is that once you're doing this, you need not have a 1:1 Interface:Implementation mapping. Often you can share a single interface among several related classes.
For example, instead of having SPReprElement, SPReprElementImpl, SPReprComment and SPReprCommentImpl, SPRepr would simply become an interface that SPReprElement and SPReprComment would implement (and the latter two would not really be public outside the XML subtree). All the sp_repr_* functions would become methods on that interface.
At least on the large scale[1], inheritance should be used to specify interfaces, NOT to share implementations. Use composition for implementation sharing[2].
-mental
[1] On fairly small scales, implementation hiding does become counterproductive in C++.
[2] One exception might be where you have a large interface, and have one or more base classes that provide convenient default implementations for many of its methods. But it's still probably a good idea to "compose in" much of its functionality.