Best Coding Practice

"Toby A Inkster" <usenet200707@tobyinkster.co.uk> wrote in message
news:18g2q4-6po.ln1@ophelia.g5n.co.uk...
| burgermeister01@gmail.com wrote:
|
| > I needed to add an array class member to an object. It was exactly the
| > same as another class member, except that one array stored regular
| > products, and the other stored free promotional products. As such, I
| > needed a way to add products to the new, free array. Since all the logic
| > was the same between the two arrays aside from the price, I had a few
| > different options to do this.
|
| Frankly I think all the options you outlined expose too much of the inner
| workings of your class. What happens when you add a third category of
| products (products that cost money, free products & products we have to
| pay you to take away!)
|
| A better solution would be something like this:
|
| public function add_product (Product $p)
| {
| if ($p->price==0)
| $this->free_products[] = $p;
| else
| $this->products[] = $p;
| }

well, add_product shouldn't care about anything specific to $p outside of
it's price, availability, quantity, etc. since both 'free' and 'not-free'
product have them, add_product should look more like:

public function add_product(IProduct $p)
{
$this->productions[] = $p;
}

where IProduct is an interface having all of those shared attributes. if
add_product is the interface of an 'order' object, it should look more like:

public function add_product(IItem $item)
{
$this->items[] = $item;
}

where IItem is an interface implemented in a base 'product' class and a base
'service' class...a free product or service simply extends their base class.
the WHOLE time, the 'order' object couldn't care less. it just cares about
price, availability, quantity, etc.. ain't loose-coupling great!

;^)

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

"ELINTPimp" <smsiebe@gmail.com> wrote in message
news:1187982123.581945.190800@q4g2000prc.googlegro ups.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.

;^)

On Aug 24, 3:20 pm, "Steve" <no....@example.com> wrote:
> "ELINTPimp" <smsi...@gmail.com> wrote in message
>
> news:1187982123.581945.190800@q4g2000prc.googlegro ups.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.

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

no, i got that.

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

then you'd be giving me more credit than i'm due. ;^)

listen, i know about dead-lines and costs and don't even get me started on
scope-creep. i've been consulting on a project that i originally estimated
and priced as a three month project. now it's two years later...at least
they keep my extra income level high.

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

yeah, that's usually the way it goes. plus, the more times you try to help
open their eyes to potential problems they will most assuredly pay for down
the road, the more the see you as one who complains a lot...nothing more.

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

it works out that way sometimes too. that would be oop-creep when a more
simple solution lies at the fingertips of a few well written lines of code,
but is otherwise written to match oop. it is key to recognize this, which
you have it seems. when you sit down to write or rework code, that's the
question (of many) i ask myself. what's the best way to express a solution
that is stable, maintainable, and will last over the long run? (oh, and it
has to work, not cost much, and be done yesturday)

| I would still need two arrays to distinguish products

well, no, you wouldn't. using oop, you can tell the object type of $product.
if 'free' extends the product class, then you can tell by its
type...'freeProduct' (or whatever). you can then branch your 'order' logic
based on that if you need to do something special with 'free'.

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

well again, if you oop things, you can isolate one area of code to
consolidate the interactions with the db: one set of code to manage it, one
set of code to maintain it. that way, further development is kept clean and
not tied to poorly/redundantly designed db structures. if not contained this
way, you'll see the code become even more convoluted that the db and people
will copy and paste the already shitty code into new sections where it will
be modified slightly for whatever purpose need...propgating one nasty end
product.

hey, didn't mean to seem like i was getting on to you or anything like that.
i guess i was just preaching to the choir. ;^)

cheers

On Aug 24, 4:44 pm, "Steve" <no....@example.com> wrote:
> | 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.
>
> no, i got that.
>
> | 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.
>
> then you'd be giving me more credit than i'm due. ;^)
>
> listen, i know about dead-lines and costs and don't even get me started on
> scope-creep. i've been consulting on a project that i originally estimated
> and priced as a three month project. now it's two years later...at least
> they keep my extra income level high.
>
> | 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.
>
> yeah, that's usually the way it goes. plus, the more times you try to help
> open their eyes to potential problems they will most assuredly pay for down
> the road, the more the see you as one who complains a lot...nothing more.
>
> | 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.
>
> it works out that way sometimes too. that would be oop-creep when a more
> simple solution lies at the fingertips of a few well written lines of code,
> but is otherwise written to match oop. it is key to recognize this, which
> you have it seems. when you sit down to write or rework code, that's the
> question (of many) i ask myself. what's the best way to express a solution
> that is stable, maintainable, and will last over the long run? (oh, and it
> has to work, not cost much, and be done yesturday)
>
> | I would still need two arrays to distinguish products
>
> well, no, you wouldn't. using oop, you can tell the object type of $product.
> if 'free' extends the product class, then you can tell by its
> type...'freeProduct' (or whatever). you can then branch your 'order' logic
> based on that if you need to do something special with 'free'.
>
> | 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.
>
> well again, if you oop things, you can isolate one area of code to
> consolidate the interactions with the db: one set of code to manage it, one
> set of code to maintain it. that way, further development is kept clean and
> not tied to poorly/redundantly designed db structures. if not contained this
> way, you'll see the code become even more convoluted that the db and people
> will copy and paste the already shitty code into new sections where it will
> be modified slightly for whatever purpose need...propgating one nasty end
> product.
>
> hey, didn't mean to seem like i was getting on to you or anything like that.
> i guess i was just preaching to the choir. ;^)
>
> cheers

To Steve: I did feel a bit attacked by your previous posts, but just
as your intention wasn't to offend, my real intention wasn't to defend
myself either, so much as to make the circumstances clear for the sake
of conversation. I don't want this thread to be about me so much as my
circumstances, in case someone else that reads this is in the same
place.

With that said, I intend to double post, because I feel there is
really two issues going on here. In my OP what I was really trying to
figure out is which is better: clarity through redundancy, or
efficiency, with the added question of which efficient method would be
the least likely to cause further problems down the road. It seems
that earlier we had some concurrence that the former would be the
better choice. I'm still welcome to further comments regarding that
matter.

The second part of this question, is how could this whole situation be
fixed with an OO approach. As I think the rest of this thread has
established my specifics are fairly complicated and require much more
thorough details. It's going to take my awhile to write it all out, so
I'm going to get a lot more specific in a later post. Of all the time
I've been programming the people I've met and talked to about OOP that
really knew what they were talking about have been far and few
between, so I'm really interested in learning more about what other
would consider to be good OOP.

More details later tonight or tomorrow.

ELINTPimp wrote:

>
> Refactoring your code doesn't always mean you screwed up in the design
> or within the actual logic of the code. Most of the time, it has to
> deal with improving your code to meet new business requirements.

I understand all that... and how "refactor" doesn't necessarily mean
that everything's a mess.

In fact, I just "refactored" some code in which I was passing CSV
strings, but needed to change that to an array.

But I just told my payer that I did something fundamentally wrong, and
had to fix it before I went on. Had I said I need to "refactor" my code
, it wouldn't have been clear to her what happened. Worse, I think it
would have scared her into thinking that I was another one of many
coders she's hired before who bend over backwards to avoid admitting
that they made a mistake... while charging her for it.

I realize that in some circles, that kind of biz-speak is acceptable -
but those aren't my circles.

Sanders Kaufman wrote:
> ELINTPimp wrote:
>
>>
>> Refactoring your code doesn't always mean you screwed up in the design
>> or within the actual logic of the code. Most of the time, it has to
>> deal with improving your code to meet new business requirements.
>
> I understand all that... and how "refactor" doesn't necessarily mean
> that everything's a mess.
>
> In fact, I just "refactored" some code in which I was passing CSV
> strings, but needed to change that to an array.
>
> But I just told my payer that I did something fundamentally wrong, and
> had to fix it before I went on. Had I said I need to "refactor" my code
> , it wouldn't have been clear to her what happened. Worse, I think it
> would have scared her into thinking that I was another one of many
> coders she's hired before who bend over backwards to avoid admitting
> that they made a mistake... while charging her for it.
>
> I realize that in some circles, that kind of biz-speak is acceptable -
> but those aren't my circles.
>

But that's not refactoring. You changed the interface. Refactoring
does not change the interface - just the internal workings.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:

> But that's not refactoring. You changed the interface. Refactoring
> does not change the interface - just the internal workings.


What happened was that I had that Database->Baseclass->Implementation
structure going on, but I oopsed and put some features in the baseclass
that belonged in the database class.

Since the whole project relied on that wrong way of doing things, I had
to go to every page that extended the baseclass and modify it to reflect
the array way instead of the csv way.

That's refactoring, right?

btw - I just finished fixing up a working implementation and it's at
"http://www.kaufman.net/bvckvs/bvckvs_publication.php".

Except for a lot of cosmetology to do, I think it's what I wanted.

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> But that's not refactoring. You changed the interface. Refactoring
>> does not change the interface - just the internal workings.
>
>
> What happened was that I had that Database->Baseclass->Implementation
> structure going on, but I oopsed and put some features in the baseclass
> that belonged in the database class.
>
> Since the whole project relied on that wrong way of doing things, I had
> to go to every page that extended the baseclass and modify it to reflect
> the array way instead of the csv way.
>
> That's refactoring, right?
>
> btw - I just finished fixing up a working implementation and it's at
> "http://www.kaufman.net/bvckvs/bvckvs_publication.php".
>
> Except for a lot of cosmetology to do, I think it's what I wanted.

No, refactoring is changing the implementation without changing the
interface.

IOW, you change HOW you do things, but not WHAT you do. You changed the
interface.

An example of refactoring would be to change a class so that it gets its
data from a relational database instead of a flat file. The function
calls (interface) remain the same, but the code in the functions
(implementation) changes.

Refactoring in OO would mean you would not have to change anything
outside of the class itself.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================