|
|
Posted by ELINTPimp on 08/24/07 14:23
On Aug 24, 7:17 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> burgermeiste...@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.
> jstuck...@attglobal.net
> ==================
Actually, Jerry makes a good point. I guess I was just looking at
what you were doing rather than really analyzing WHAT you were trying
to accomplish.
IF this is all your trying to accomplish (discounting or rendering a
product "free"), a separate class would be incorrect. Thanks for
pointing that out, Jerry.
I think we need to step back and look at what you are doing a bit.
You have a Products class that is a child of the order class. Not
sure of the reasoning behind that from what you wrote, but I'll roll
with it. Your products class currently have two arrays, one for
standard products and one for free products. Why do these need to be
broken out into two arrays? I wonder about the db schema on how a
product is identified as "free". Is there a bit flag or something of
the sort, or maybe a discount column in percentage where 100% ==
free? Possibly something like this:
class product { //
private $_product_id;
private $_price;
private $_discount = 0;
private $_free_flag = false;
private $_quantity;
...
static public function getProduct($product_id) {
//returns the product by product ID, called from the PRODUCTS
class
//this can ensure you only have the product listed once in your
array.
//if it already exists, just adjust the quantity
}
public function isFree() {
//checks to see if the product is free
if ($this->_free_flag === true || $this->_discount == 100) {
return true;
}
return false;
}
} // end product class
class products {
$_products = array();
public function getFreeItems() {
//go through the array checking if the item is free
return $freeItems;
}
} // end products class
Navigation:
[Reply to this message]
|