RE: framework question

> From: CWilt@xxxxxxxxxxxx
> 
> 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.

This would be pretty useless if I were trying to get a price for, say,
standard pricing of work in process.  Have you ever actually coded a
pricing system?  I have.  It's a lot more complex than just figuring out
the price at invoice time.  There's also quotes, requisitions, purchase
orders, RMAs, not to mention the various material pricing done for WIP.


> Suddenly you have absolutely no way of knowing how prices should be
and
> are being calculated without digging into the code.

Same with OO.  In your case, someone would have to guess which class the
pricing actually was in, since you don't follow normal OO strategy where
the attribute belongs to the object, and you just kind of put things
where you see fit.  So now I have to know that your pricing is done in a
class called InvoiceItem, which is a component class of Invoice.  Yeah,
that's intuitive.


? 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.

This is a procedural issue that needs to be worked out for any
circumstance.  But in MY environment, the CS people would be calling a
pricing server, so they'd get the same price as the invoice.  They may
not know WHY the price is that way, but again, that's a procedural
issue.  If it were necessary for someone to know that, one would place
the annotation in the customer notes file.


> 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."

Why yes, that's exactly what I'd say.  As well as "how much have they
ordered in this shipment, how much have they ordered this year, whether
they have negotiated split pricing with another item, whether they have
preferred customer pricing, and whether this due to a special
consignment."  Not to mention whether or not Ed in sales closed a
special deal with this customer that they can buy at a 15% discount if
they but 5000 units this month.


> 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.

We sure do.  It seems that for you programming is about modeling
theoretical problems into an elegant solution space.  For me,
programming is about making the client's business work.

Joe