|
|
Posted by burgermeister01@gmail.com on 08/24/07 21:17
On Aug 24, 3:20 pm, "Steve" <no....@example.com> wrote:
> "ELINTPimp" <smsi...@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.
>
> ;^)
For the record, I think my second post has been terrible
misinterpreted. Product is not an extension of orders, orders contains
products in an array.
And Steve, I'm by no means saying you're wrong in claiming that OOP
would truly be the BEST, way to go. If it were up to me, I would be
doing exactly what you're saying. However, I came into this project
four months ago, after it's been under constant development with
continuous scope creep for the last 3-4 years. And the programmers
before me, as far as I can tell, don't understand OOP nearly as well
as I do, and that offsets them either further from you, because I can
concede that you probably do know more about OOP than I do. In any
case, the code is already at the point where it needs to be
'refactored', and I've told my boss this in different terms on a
number of occasions. However, the company is small enough that we
simply don't have the resources to do that, and the client isn't going
to be willing to pay for the man hours to essentially make their code
cleaner. All they care about is that it works. I know, I know...it's
the wrong way to look at things, and I've made my best efforts to
persuade others of that, but it's unfortunately vain efforts.
As for the specific circumstance we were addressing in the first
place, I'm not trying to say that I don't want to use OOP simply
because I think it's going to make things more complex for me, or
something like that; I don't want to use it because I don't think it's
going to add anything to make any feasible solution any better. I
would still need two arrays to distinguish products because the
database is structured so poorly, and redundantly, which I probably
should have made more clear in the first place, but I really feel that
this conversation is leaving the context of the original question I
was trying to have answered. And I understand your desire to promote
OOP as the 'right' solution, because usually it is; I love objects and
polymorphism. I just don't think it's going to help in these specific
circumstances.
Navigation:
[Reply to this message]
|