Re: Mapping SQL Result Sets to Browsers

[john e <jacobus1968@xxxxxxxxxxx>]

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.


----------------------------------------
> Date: Tue, 8 Jul 2008 10:14:29 -0500
> From: joepluta@xxxxxxxxxxxxxxxxx
> To: web400@xxxxxxxxxxxx
> Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers
>
> Nathan Andelin wrote:
> > I guess the point, is that you may need to plan for a lot of flexibility, and change as business rules change.
> >   
> Agreed.  I'm sort of avoiding this very high-level discussion of 
> architectures because I've already been there and done that and I have 
> my own opinions, and rather than bollox up the list with my 
> pontification I'm enjoying the interplay (hence the "from the bleachers" 
> comment).  But hopefully I can help people avoid certain pitfalls I've 
> encountered.
>
> 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.
>
> An even trickier issue is when you get different values for different 
> users.  One specific example is social security numbers.  In at least 
> one system I've seen, a user with high authority gets to see the real 
> SSN, while someone with a lower authority sees a special garbled value.  
> Technically I suppose this is a presentation layer issue and the object 
> could contain both values, but then you have security concerns.  In any 
> event, it's something that needs to be considered.
>
> In any case, you're right - once you begin injecting business rules into 
> the ORM layer, a large number of issues come into play.  Everything from 
> authorization to latency needs to be addressed.
>
> Joe
> -- 
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.

_________________________________________________________________
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/