|
|
Posted by Steve on 08/24/07 20:20
"ELINTPimp" <smsiebe@gmail.com> wrote in message
news:1187982123.581945.190800@q4g2000prc.googlegroups.com...
| On Aug 24, 2:43 pm, "Steve" <no....@example.com> wrote:
| > | That being the case, I have some more specific inquires into the
| > | group's and ElINT's opinion on OOP. It's possible I'm not fully
| > | understanding the way you describe it, ELINT, so if I'm reiterating
| > | what you've already said, I apologize in advance. The approach I might
| > | take, is as follows:
| > | My Product class which is a member of the Order class, of which I
| > | mentioned in my OP, would be my parent class. My reasoning for this is
| > | because the Product class is already used in so many other scripts, I
| > | wouldn't feel entirely comfortable suddenly making it a child class of
| > | some other super class.
| >
| > i *completely* disagree...you are not programming for your *comfort*.
you
| > program to get it correctly. you should have an *item* class implemented
by
| > product which will further be extended and used by the free product
class.
| > additionally - and the main reason you should *not* make the base class
| > 'order' - your company could begin selling *services* and as far as
billing
| > goes, would be so similar in structure as 'product', you'd want to reuse
the
| > base that way. finally, since an 'order' consists of line 'items', you
can
| > use the 'item' interface to process the order (shipping, billing,
inventory,
| > etc.) without having to look at any other specific differences between
the
| > inheritors (product, free product, service).
| >
| > again, do it right so the code base is *sound*...don't avoid doing
something
| > because it is *uncomfortable*. the only reason to keep from refactoring
| > completely is because of costs.
| >
| > but that's just my 0.02 usd
|
| I think after analyzing his actual situation rather than what he was
| actually trying to do in the first place, Jerry is on the right
| track. For this particular situation, creating a superclass and
| concrete child classes isn't necessary and would, in my opinion never
| really be needed. His product class holds individual products
| (despite the name, which makes it seem like it should be a parent
| class for concrete product type classes).
|
| I don't think anybody was saying OOP was a bad solution in this
| situation, since they were still talking about using a array within an
| class. If he uses the product class as an object-wrapper around the
| array, it will would nicely (which is what I was getting at in my
| pseudo-code.
|
| The solution that both you and I offered up prior to Jerry re-
| emphasizing the problem is a sound way to program, keeping your code
| clean and ready for polymorphism. Only problem is that our solution
| wasn't relevant to this situation. =)
agreed. however (in the spirit of 'general programming' the op pondered), if
it is to be completely accurate as to the quoted text to which i responded
then, product is not a function of order (which is made up of items).
product should inherit an IItem interface and any other extesions to it,
like 'free product' should come from the product base class. an IItem should
also be implemented other order item types like service...any extentions
from that should also come from it, like 'free service' are from that. there
are other item types as well such as discounts, non-itemized taxes, etc..
these are all 'items' that can appear on an 'order'. so, extending products
using order as a base class is ass-backward and soon, you'd be refactoring
things to match exactly the structure i described.
btw, burgermeister was the above quoted that talked about complexity
decreases desire to oop. you, jerry, and i are 'comfortable'...i was trying
to pursuade burger to change his mind.
;^)
Navigation:
[Reply to this message]
|