Deeply-nested class layout suggestions wanted

[Kirk Strauser]

At 2004-06-11T02:37:08Z, "Robert Brewer" <fumanchu at amor.org> writes:

> First thought: seeing two example classes named "POP3TiffFile" and
> "POP3ZipArchive" makes me wonder if this isn't a better candidate for
> delegation than subclassing. That is, a "POP3Retriever" would *possess* a
> "ZipArchive" handler rather than *be* a ZipArchive handler. Another
> instance of the same POP3Retriever class could possess a TiffFileHandler
> rather than *be* a TiffFileHandler.

There's something to be said for that approach, but I'm not sure if that
would work in my case.  For reasons too annoying to go into, the coupling
between the data sources and the end-result data objects is quite a bit
tighter than I'd like.

As an example, each of the "DataStore" objects carries a unique identifier
that associates it with some rows in our database.  In some cases, those
identifiers come from the name of the file as it appears in the email
attachment.  In another case, its determined from an image of a barcode that
I have to read.  In other words, a "DataStore" object doesn't directly have
the means to determine its own name; the higher-level "Collection" object
gets most of that responsibility.

> If by "keep all functionality as high in the inheritance hierarchy as
> possible", you imply "keep the module heirarchy flat", then delegation is
> a good technique. But I'd be interested to hear why you did not choose it
> (yet ;).

I meant something closer to moving functionality as close to the root of the
(possibly deep) inheritence tree.  The "delete()" method is identical for
every object in the POP3* classes, for instance, so I want to make the base
classes as fully-functional as possible and only add the barest amount of
overloading code to the "leaf" classes.  In XP terms, I want to refactor
mercilessly.  :)
-- 
Kirk Strauser
The Strauser Group
Open. Solutions. Simple.
http://www.strausergroup.com/