6 Feb
2003
6 Feb
'03
2:10 p.m.
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