It all boils down to not trying to use inheritance too much.
I believe that was my original point. Trying to create a business object
model that you inherit from is a road fraught with terror.
Helper frameworks like Hibernate, how to use them? ... No business
logic
in there, just basic classes; are also known as POJO's. ...
That's why I don't like POJOs and the Hibernate model, I want business
logic on my classes. We've got something we wrote that's hibernate-like,
but acts as the base class for our objects. Allows us to keep
implementation details of the object private and still expose the
properties we want. Note, I'm not talking about inheriting
business-concept classes (Contact->User, Order->WebOrder) but rather
inheriting from an abstract base class that knows how to do IO to a
concrete business class (one level).
As far as inheriting concepts like address, our objects tend to follow
the database. So if you had address on customer and address on vendor
the address would just be properties on the customer and vendor object.
However, if you had an address table, and say a property on customer
with the customer's addressID and a property on Vendor with the vendor's
addressID then we'd have an address object and customer and vendor would
each have an address property that returned an address object given the
addressID. The address object may even have a business method on it
like, Validate() which would take the address object and perform address
validation, say via web services with FedEx.
-Walden
midrange.com
