Re: Mapping SQL Result Sets to Browsers

john e wrote:

Off topic... but couldn't resist... :)

Joe said:

Different rules for different object types is important. The OO answer
is to have different classes for each, but all of a sudden you end up
with a complex and fragile object hierarchy. Not necessarily a bad
thing, just something that happens and is not always handled well by ORM
software.

A complex and fragile hierarchy is always a bad thing.

Introducing different account classes because of different calculations for "available balances" is a bad idea. Instead it's better to factor out these calculations into a different type of object, for example an "account-type" object which may delegate this calculation even further to a "balance" type.

In general, subclassing is not re-use and is often misused resulting in brittle code. A good OO design has a clean distinction between object types (interfaces) and their implementations (classes) and uses composition over subclassing (because the latter breaks the encapsulation principle because you deal with implementation issues directly).

A good OO design gives you software that is easy to adapt to changes and is extendible.

Not really off topic, John. In fact it does point out the problem with using terms like "business object" too loosely. If you're talking about true OO, you have to take into account the hierarchy issues. Also, too often the term "business object" is used in conjunction with ORM frameworks, which further confuse the issue because they rarely follow practices like the ones you're suggesting, where different business rules are encapsulated in different classes.

In a *proper* OO design, a single row from an RDBMS may actually require instantiating objects of multiple classes. And, perhaps less frequently, multiple rows from an RDBMS may result in a single object (typically this happens with what we call "extension files" in the enterprise world - files with the same key as a standard master file, used to hold site-specific customizations). Most ORM tools don't even begin to handle that level of complexity.

In any case, the whole discussion of "business objects" is too vague for my taste. When you aren't specific about languages and implementations, talking about relative performance and scalability is like trying to decide whether Superman is tougher than Batman - fun perhaps, but ultimately impractical in the real world.

Joe