Re: Mapping SQL Result Sets to Browsers

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

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