Re: How to generically look up the inheritance tree?

On Nov 14, 3:11 am, "Maarten Wiltink" <maar...@xxxxxxxxxxxxxxxxxx>
wrote:
    if Depth < inherited GetMaxDepth then
    begin
      inherited;
      Exit;
    end;

Given your implementation, that looks like a least bad solution.

Well, there's that, at least.

But I suspect, although I don't know for sure at this early hour, that
you're barking up the wrong tree. You're trying to use inheritance for
something it isn't suited for. If you have a solution that makes you
want to pull tricks like calling a random override somewhere along the
chain, your solution is wrong to begin with. (No offense.)

While I haven't grasped your problem in detail, I think you might be
better served with something more data-driven, in particular with
something along the lines of a routing table.

The trick there is that you need to be able to progressively walk down
the data from general to specific.

What I'm dealing with is this:

We have basically a homegrown object/relational mapping. There are a
whole bunch of classes that exist to pull data out of various tables,
with one class per distinct table structure. Each table has one or
more keys, and I want to be able to pass any object with the
appropriate information as a source of data for a full or partial key
lookup.

The table keys can be seen more or less hierarchically. One table
might have property, building, and unit. Another might have property,
building, unit, and a table-specific sequence number. A third might
only have property and building. (I used addresses as an example, for
simplicity.) There isn't a whole lot of consistency in the names of
the fields ('Prop' in one class might be 'PropNo' in another; this
reflects the mishmash in the underlying database).

My current approach to things involves creating an interface for each
distinct key (e.g just the property; property and building; etc.) and
having the data classes implement the interfaces that they have the
fields for. I then have a class for each key on each table; instances
of those table classes can be passed any object providing the
appropriate interface and will then use the interface to get the key
information they need. The problem is that if I want to look up all
the buildings in a property and all I have is an object with the
property key interface but not the property and building key
interface, I can't pass it to the property and building table, even
though I'll only be using the property from it.

So my current thought was to have the property and building table
inherit from the property table (and this works with the Liskov
substitution principle; a property and building lookup will behave
exactly the same as a property table if you only do the lookup on the
property) and use the technique of passing things up the inheritance
chain before looking for an interface, thus allowing me to use more
objects than I currently can.

Thinking about this from a routing table perspective, though, it
occurs to me that I can define unique names for each potential key
field (probably in an enumeration) and have every object implement a
method that takes the unique name as a parameter and returns a
Variant. Each table would then just have a list of names for its key
fields and would walk the list up to the specified number of fields.
I think that would work, and it would let me put almost all of the
lookup code in a base class, with each table just supplying its key
fields and associated data source. I may play around with this;
hopefully it'll be a little cleaner than the class inheritance model.
.

Relevant Pages