Inheritance and Inner/Nested Classes

[Peter Hansen]

Paul Morrow wrote:

> I'm creating a framework that you parameterize by supplying objects that 
> contain particularly named attributes.  The attributes tell the 
> framework what to do, when to do it, etc.  So I'm trying to find a nice 
> and clean object structure that uses a minimum of syntax.
> 
> The framework parameters (in the object the developer supplies) fall 
> into a number of categories, so it seemed like a good idea to group 
> them, hence the inner classes idea.  And yes, since we are talking about 
> objects, a more traditional object-oriented layout such as...

Thanks for the clarification.  Based on what you are saying
here, I strongly suggest abandoning the idea of keeping
these attribute classes as inner classes.  I think doing that
couples together two unrelated things and will cause much
more trouble in the long run than the modest reduction in
extra typing will save you.

The objects that are being parameterized (the ones the developer
supplies) are not the same thing as the parameterization objects.
The former are for the developer, and presumably have something
to do with the problem domain (whatever the framework is helping
the developer solve).

The parameterization objects, however, are *for* the framework,
not for the problem domain (if I'm understanding correctly)
and shouldn't be coupled with the other ones.

Even if they appear to be related (maybe because the types of
parameterization involved come directly from the problem
domain as well), I would still keep them very separate.  Otherwise
you are mixing together the whole parameterization feature
with the rest of the system and the result will probably grow
unmanageable or at least complicated in due time.

-Peter