Re: [Gnue-dev] Why the Object metaphor? (Was: Object-Relational Mapping?)

[Daniel E Baumann]

On Sat, Jan 18, 2003 at 11:12:11PM -0600, Jason Cater wrote:
> I am also not being arrogent to say one model is better than another.  The
> whole point of that last email was to make people question the assumptions
> they are making about their object view of the world. They say it is more
> intuitive for the end user. I ask WHY? All I get is the implication that I
> am misunderstanding the point and that I am talking at a lower logic
> level.  I turn around and say, well my point is being misunderstood too
> and that I'm talking about the abstraction layer presented to the user to
> customize. 

How is the relation more inuitive? Because people are used to making
spreadsheets is this the only reason? The most things I see people
doing to spread sheets is writing little equations. They don't use
things like sql, transactions, etc. SQL is a pretty big leap from a
spreadsheet. Granted I suppose 'keys' are referencing cells from other
spread sheets?

> I guess I am confused.  At one minute we are talking about how the end
> user will be presented with the business logic and functions so that he
> can expand it ("modifying system behavior") to fit his business needs. The
> next we are talking at some "conceptual" level and that I am just being
> overly reactive to specific terminology. I am trying to discuss the
> former. 
> 
> Unfortunately, I have not seen any concrete examples of the former, but
> hear that treating them as business objects will be more intuitive. All I
> ask is WHY it is more intuitive. What other options are there? I am not
> saying I have that answer, but was giving examples of how the
> end-user/customizing person can just as well understand a spreadsheet-like
> metaphor. Maybe it's not best, but WHY or WHY NOT? I certainly think the
> object metaphor will quickly fail outside of the most mundane
> customizations, but of course I've made no secret of that. 

I think objects are more intuitive because people like to categorize
things. We create type hierarchies in everyday life. These objects
have 'relations' too. However the relation model breaks encapsulation
so it has that drawback.

> Also, all I have to go on are the abstraction models I am seeing evolve in
> the App Server layer. My understanding is that will be the abstraction
> layer that will be presented to the user to customize. And that is an
> object model, with all its inherent problems I am trying to raise. Maybe
> there is another layer on top of that I am missing. If so, I apologize. 
> If not, I don't care if you call it a business object, or whatever. My
> question remains:  how does the user get anything accomplished? 
> 
> I understand the point you are getting across with the business rules;
> i.e., it is easy to add logic to a Purchase Order; e.g., POs cannot be
> issued on a Sunday as the office is closed on a Sunday. (Maybe that's not
> a realistic example, but I think it will work here.)  It is really easy to
> add that to a "Purchase Order" business object. The model works well for
> this case. 

You're admitting that objects are extensible? cool :).

> But what about after that? How does the user actually use the system
> afterwards. Business rules are only one part of the equation -- a part
> that objects work well with.  Business reporting, in my opinion, is
> another equally important part of the equation. Having custom business
> rules without easily being able to report against custom "enhancements"
> will be fairly useless. Will any custom reporting be left to an
> "application developer" as Dan says? If so, what's the point of only being
> able to modify business rules? The user can implement rules but not
> generate custom reports? That doesn't seem like a very extensible system
> to me. 

I never said it all should be done by an application developer and
it's not fair in placing those words in my mouth. Why would you not
have a UI or something like a report builder that would inspect the
business objects and, based on constraints the user types in then they
select what they want on their reports? Doesn't matter if its business
objects or relational data though. Perhaps business objects could
expose their methods so the user can see what functionality she/he can
play with. I dunno I haven't even looked at GNUe reports. Nor have I
given reporting much thought, but using 'business objects' doesn't hurt
having an extensible reporting system, imho.

> My wife has a used bookstore where books cost half the original cover
> price. She adds a "cover price" property to her inventory business object
> and adds a rule that [ price = cover price * .50] How does she make use of
> these customizations outside of the extra rule placed on integrity? 

She could extend the object and override it's price() method? She
could modify the business object graphically and change the 'rule' for
the "price" using our kewl new business rules language? There's LOTS
of possibilities. There could even be a business rules layer that sits
on top (which you hinted at before).

> > It would have helped a lot more if you would have explained what 
> > direction you see the abstraction going and how it will be presented 
> > to the user since that was the point to my emails.
> 
> I am trying to get people to justify their stance.  I gave some conceptual
> examples of tasks the end user may try to do themselves, and how I thought
> the terminology fails.  I am told I am thinking too low-level.  At what
> point is the line crossed?  Once the user gets out of defining business
> rules and into getting useful information out of the system? Or is it
> lower than that? Higher than that?

Well you need to give some people a chance as some of use don't write
a whole book at a time ;). I think I have addressed OO solutions to your
examples. There could also be relational solutions.

> > If that is not the direction of GNUe, please let 
> > me know and I will shut up.
> 
> One of the first lessons I learned when starting with GNUe is that the
> client tool developers are not taken seriously when the subject of
> business rules programming comes up. Just for the record, this isn't some
> academic exercise for me either. I don't want to end up with yet another
> heap of useless code on my hands that is worthless to my companies. 
> 
> For the sake of completeness, let me once more clarify: I am not trying to
> advocate one model over another... I am wanting people to ask themselves
> why they are making the assumptions they are. This will be my last email
> on the subject as I have failed in this goal. I've only seem to get
> reactions, not explanations :( 
> 
> But I am not ticked off.

Well I am trying to provide you with explanations, perhaps you will
give it one more chance and look at my 'propositions'. At any rate, I
don't want to have anymore object v. relational wars as it is just
plain stupid. If gnue is truly about choice then why can't we have it
so you can do it either way? Isn't this why forms, et. al. work in
2-tier and n-tier?

Dan
-- 
And if cynics ridicule freedom, ridicule community...if ``hard nosed 
realists'' say that profit is the only ideal...just ignore them, and use 
copyleft all the same.
      -- RMS

Was I helpful?  Let others know: 
  http://svcs.affero.net/rm.php?r=chillywilly