RE: framework question

[CWilt@xxxxxxxxxxxx]

> Charles said: 
> 
> > I'd be interested in hear what your "few lines of RPG" and
> "appropriate
> > place" are.
> > 
> > This seems to imply to me that you're adding an "if custnbr = 'XYZ'
> then
> > <...>" in your pricing program.
> > 
> > SAY IT AIN'T SO JOE!
> 
> IT IS SO, CHARLES!  REALLY!  I WRITE CODE WITH IF STATEMENTS!
> 
> 
> > Perhaps the world doesn't have time for OO.  But surely it doesn't
> have
> > time to maintain such code either.
> 
> How elitist!  Sorry, but that line of perfectly acceptable procedural
> code is just as maintainable as anything else.  If it turns out it's a
> permanent issue or requires generalization, I'll persist it in my
> database, but if it's a one-off temporary change this is 
> EXACTLY how I'd
> address the issue.  

If it really is a one-off temporary change that you're going to take out the
next day, then maybe just maybe with a lot of pressure from the top I'd
agree it was ok.

But, come-on Joe.  How often is this really the case?  Sure the powers that
be who are requesting it may say that's the way it is, but how often has
that actually been the case?  More likely, it will be there at least a week,
month, maybe a year.  Even more likely is more than one customer will get
this deal at some point and that this deal or something similar will be
repeated in the future.


> 
> It's certainly more maintainable than adding another class that
> overrides the pricing method, and then changing the factory class to
> create an instance of the new class based on the customer number.

It seems to me that you're coming from the idea that the Item class
calculates the price for itself. That may be how it worked in Marc's
examples and even in some OO books I've seen.  But it's a poor way of doing
it IMHO and is a direct result of being too in love with OO.  The thing to
keep in mind is even OO is procedural at the method level and that some real
work needs to get done somewhere.

It seems to me that in the real world, whatever class did the pricing would
already need to know about customer.  Off the top of my head, I'd have
pricing method in the Invoice class or an InvoiceItem component class of
Invoice.

> 
> In any event, if you don't like the IF statement, Charles, 
> then we have
> completely different ideas of what programming is all about.

It's not the IF statement that I have a problem with Joe. It's the custnbr =
'XYZ'.

Suddenly you have absolutely no way of knowing how prices should be and are
being calculated without digging into the code.  What happens next month or
next year, when the guy orders the same product and pays 10% more for it.
He calls in wondering why.  The customer service people check, well there's
been no price change to the product, it wasn't on special, and your terms
haven't changed.  Guess well have to call IT and see if they can figure out
what the dammed AS-400 is doing now.

How do you answer your auditors when they ask you how a customer's price is
calculated?  "Well, that depends on what day and what customer it is."

If you really don't see any kind of a problem with that if statement
Joe...perhaps we do have completely different ideas of what programming is
all about.


Charles