Polymorphism - retrieving type informati[Ref:C520982]

Question

Hi Tim.
Just a few thoughts on your question, based on some of the work we've done here.
We use your solution (1) to deal with this type of problem. As an example we
deal with it:
We have class called Constraint, with several subclasses (eg. Permanent,
TimeBased, ) requiring different attributes.
They are all stored in the database table Constraint, with an additional column
for the class of constraint - we call this ConstraintType.
On reading from the database, we have a class called GenericConstraint which
contains all the attributes from all the subclasses and the ConstraintType
column. We read from the database into an array of GenericConstraint.
To convert GenericConstraint into the proper subclass, we instantiate the
correct class, determined by looking at the ConstraintType attribute, and then
calling it's create method, which takes a Generic Constraint parameter. (An
alternative would be to call a method on GenericConstraint which did something
similar and returned the correct class).
This works very well for us, as the GenericConstraint class and methods which
use it provide a nice interface between the class structure we use and the
database structure in the database, and therefore flexibility.
Looking at the pattern of nulls to determine which class to instantiate may be
much more restrictive. The separate table idea that you mentioned sounds like a
one-to-one relationship - is there much benefit in implementing this separately
and then having to join the additional table ?
Hope this helps.
Steve Elvin
Frontline Ltd.
UK.
-----Original Message-----
From: INTERNET [email protected]
Sent: Monday, June 15, 1998 12:29 PM
To: Stephanie Mahay; Steve Elvin; X400
p=NET;a=CWMAIL;c=GB;DDA:RFC-822=forte-users(a)sagesoln.com;
Subject: Polymorphism - retrieving type informati [Ref:C520982]
Suppose I have a class structure containing one base class with several speciali
sations. Say, "Vehicle", with specialisations of "Car", "Van" and "Truck". All v
ehicles are persisted in the database, in a rolled-up table, and I want a generi
c retrieval mechanism, which fetches a vehicle based on the license plate number
. (It will probably be a service object, which I will call a Persistent Object M
anager).
I wish to retrieve ALL vehicles, and calculate the road tax for each. However, c
ars, vans and trucks are all subject to different tax rules, and require a diffe
rent method to calculate their road tax. To put it another way, there is a polym
orphic method 'CalculateRoadTax' on the "Vehicle" class.
Q: As each vehicle is extracted from the database, how does the rest of the Fort
e application know what type of vehicle it is?
I am sure that others must have solved this problem before, but it is new to us.
We have come up with the following solutions:
(1) Add a "sub-type" column to the "Vehicle" table. Use the type information to
instantiate a Forte object of the correct type
(2) Maintain a completely separate table linking the vehicle licence plate to i
ts sub-type.
(3) Deduce the type of the object from the pattern of null columns in the row.
I think (1) is the best solution, but I'm interested to know what the experts sa
y!
Incidentally, if Express can help or hinder in this situation, I would be intere
sted in that as well.
regards,
Tim Kimber
EDS (UK)
<< File: untitled.dat >>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1