Posted by Jerry Stuckle on 08/24/07 11:17

burgermeister01@gmail.com wrote:
>>> Anyways, this is also more of an opinion based question than one
>>> seeking a definite answer. Recently, while maintaining a rather large
>>> system. 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. I'm interested in polling
>>> which way some of the group members feel would have been the best.
>>> Naturally these are abbreviated versions of what I envisioned as
>>> possible solutions.
>>> #2. (These next two are arranged as such, because the class using
>>> these functions is included in many script files,
>>> all of which I may not be aware of, so there would have to be some
>>> default value for the array that was always used
>>> before this new array was needed)
>>> public function addArray($object, $free = NULL){
>>> //logic
>>> if(!$free){
>>> $a[] = $object;
>>> }else{
>>> $b[] = $object;
>>> }
>>> }
>> not very good practice. when you start using conditional statements
>> within your code, it's a good canidate for refactoring. Seeing this
>> as a possibility, I probably would have created a abstract base
>> Products class, which it's child concrete classes would act as
>> containers for product items. The base class would contain all the
>> core functionality, and the child classes the specific elements.
>> Then, come time to add a new sibling class, it simply inherets from
>> the superclass and your good to go.
>>
>
>
>
> Frankly, I can't believe that I didn't think of a more OO approach to
> begin with. I've been working in a shop that went through a series of
> really terrible programmers, and me, wanting to stick to convention
> just for consistency's sake, it appears I have begun to lose some of
> my 'good' habits. I will have to consult this group more frequently to
> ensure that doesn't happen any further. In fact, this code is so fresh
> I may still go back and rewrite it.
>
> 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. Additionally, the data used to instantiate the
> Product class is being pulled from a separate database table (like an
> active record) however, the free products essentially are the items
> from the Product table, only with their price overridden to $0 (that
> in itself may not make a lot of sense, but apparently, after
> communicating with the client its the best way to interface with their
> inventory system). Therefore, in my mind it would make sense from an
> OO standpoint to make a FreeProduct class which extends the Product
> class and simply overrides the price member, or the function that
> returns it.
> Further thoughts and opinions on this matter are welcome and
> appreciated.
>

Why would you have a FreeProduct class? All a FreeProduct is is a
Product with a cost of 0. Cost is an attribute, and different values
for attributes should not determine new products. Would you have a
ProductCostsNinetyNineCents class? Just set the cost to zero, instead
of overriding it.

Or is there something I'm missing?

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

[Back to original message]