Re: Objects and such

Walden H. Leverich wrote:

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.

Walden, we have experienced similar "challenges" in the past but have overcome many of them. Can I assume you were using a standard object class ((POJO) Plain Old Java Object)) for this work? For example: a customer class would have variables such as:

int custId
String name
String address1
String city
String state
String zip

?

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.

Again assuming a standard POJO approach, ROI is difficult. IMHO POJOs are main factor in limiting true productivity and adoption. What have you used for persistence? If you use an intelligent dynamic field approach, inheritance works great and often you don't need subclasses to override. So basically instead of basic class with "static" set of fields, you create a class with a "collection" of FIELD objects. Each FIELD is intelligent and understands it's data type, rules, security, business meaning, size, etc. You can have Field subclass objects that represent things like address, city, state, zip, credit card number, etc. The dynamic field collection then enables you to create class hierarchies that can generically provide services. In my experience, this is where you can true productivity.

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

Depending on your needs here, you could build "phone" or billing functionality into either a superclass or you could have a "helper" class that can extract phone or billing information from you database row object. IE... DatabaseRowObject.getField(PHONE_FIELD); // this method loops through it's fields and finds the field for representing a phone #. The ability to loop through fields helps in many places and is the key enabler to solving the issues you outlined.

My .02 anyway. Have a good day, Paul Holm