RE: Objects and such

It's been our experience that creating sub-classes for business objects
is a waste of time. Object inheritance* can make a ton of sense when
dealing with runtime objects (strings, commands, connections, etc.) but
tends to make less sense with database objects.

We've tried (several times) to make sense of an inheritance tree for
business objects and failed each time. Sure, you could have a "trading
partner" class, and then say that the "customer" class and the "vendor"
class both inherit from that. Or if you have a rule that all your portal
users are contact, but not all your contacts are portal users you might
be tempted to say that "PortalUser" inherits from "Contact" but in the
end this usually breaks down. Heck, if all trading partners and Contacts
have addresses, then perhaps there's a base class called
"AddressableObject" so you have a tree of:


AddressableObject
|
+---------------------------+
| |
TradingPartner Contact
| |
+-------------------+ User
| |
Vendor Customer

Then you can have a method on AddressableObject called GetAddress()
which returns an address. Vendor may override GetAddress() to look in
the VendorAddress table, and Customer may override it to look in the
CustomerAddress table and Contact may override it to look in the
ContactAddress table, but it's still the "GetAddress()" method.

However, while this looks great on paper, implementing it is a
nightmare. Not to mention, what about PhoneableObject, or
BillableObject" should they be in the base tree?

-Walden

*don't get me started on multiple inheritance, does Java even support
it? I know .Net does NOT