Re: Objects and such

I agree with Cor that this is out of place on an RPG list, but it's so darn
interesting I can't help myself. That being said, I'll try to keep it
brief:

1) Inheritance, while powerful and a staple of OO theory, should probably be
kept as shallow as possible.

2) Interfaces are very cool, as long as you are willing to write the
implementation yourself.

3) In the case of multiple addresses/phone numbers, usually I would say
these shouldn't be handled by the object, but rather a collection within the
object. So the tree might look more like this:

CustomerObject:
- has a Collection of IAddressable objects
*may have any combination of*
- HomeAddress - implements IAddressable
- MailingAddress - implements IAddressable
- BusinessAddress - implements IAddressable
- has a Collection of IPhonable objects
*may have any combination of*
- HomePhone - implements IPhonable
- MailingPhone - implements IPhonable
- BusinessPhone - implements IPhonable

Each class then implements its own business rules within the construct of
the common Interface. This is a poor example, as I doubt the business rules
would be different based on the type of address, so it would probably
actually be like so:

CustomerObject:
- has a Collection of Address objects
- has a Collection of Phone objects

Where both Address and Phone expose an Enumeration of possible types. The
Address and Phone types would then contain the business rules, whatever they
may be:
- Phone numbers must be ten digit (assumes US)
- Addresses must include valid Zip codes (possibly verified by an outside
source)

Etc. etc. And of course, the business rules implemented could be based on
the type (again exposed by the Enumeration), so that a Canadian mailing
address might have different rules than a US address.

And how you expose the Collection is up to you, so if you still want to have
"GetMailingAddress()" style methods you can.

4) Business rules are whatever your requirements say they are, and there can
be multiple layers of Business Rules:
- The rules discussed above are specific to the Address or Phone objects.
These are essentially formatting and validation rules, so they would live at
the Address and Phone supporting layer.
- Rules such as "are all three addresses required?" and "Can you have more
than one Home phone number?" would be controlled at the BusinessObject layer
since those rules are incumbent on the definition and requirements of a
Customer and not an Address/Phone.


OK, so I failed the brief part, my apologies. Fortunately, I know nothing
about Hibernate so I can't comment on that, but I am learning how to use
CSLA (http://www.lhotka.net/cslanet/) and in that Framework the
BusinessRules are implemented in the BusinessObjects, so not all Helper
frameworks separate the data from the rules.