Paul Davis wrote: > conceptually, i am not creating a distinct type of object - i want to > provide a particular set of objects with access to a limited set of > member functions belonging to an otherwise unified object.
But one point with this pure-abstract-base-class-as-interface line of thought is that you don't have to be describing an "is-a" relationship at all, you might be simply using the interface to express exactly what you're describing above: that there is a subset of the functionality provided by a particular class that may be of interest (as a bundle of related methods) to someone else. In other words, you aren't saying that your editor is an A, a B, a C and a D. You're just saying that it provides some interfaces that are described in A, B, C, and D. That doesn't help with your access protection problem, and it doesn't necessarily help at all if your other code actually needs various combinations of the things in A, B, C and D, but in principle -- and often in practice -- it can be a pretty tidy expression of what you intend. That said, I tend to just lump everything together and forget about it, myself. I count 270-odd members and nearly 5000 lines of code in Rosegarden's NotationView class (which doesn't even do the hard stuff, it just sets up the window and manages the menu functions) and that only has one abstract base -- with a single method in it! -- and one strictly implementation non-abstract one. In fact it's such a mess that I think I'll stop talking about conceptual shit like this right away because I clearly don't know what I'm talking about. *cough* Chris