× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I am trying to learn here, so if this is a really stupid question please be kind.

Why would the Address class have a name attached to it? A name is a name, not an address. Wouldn't there be two classes? A name class with certain rules quite different from address rules? If one looks at addresses, without names or other arbitrary restraints, doesn't the address class become very very inheritable?




Paul Holm wrote:
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








As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.