|
|
Posted by burgermeister01@gmail.com on 08/24/07 14:20
On Aug 24, 6: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
> ==================
Jerry,
Initially I was going to answer your post with a description about how
Product classes are active records and FreeProducts aren't *really*
active records. However, the more I thought about it, the more I
realized that that's in fact no justification for a child class in
this case. In fact, because of the way the Order class stores
products, i.e. basically $products['product_id_number'] = $quantity,
this would only add an extra layer of complexity and not really make
storing the products any easier. This leads me back to what you and I
originally concurred about being the better solution (or something
like it, such as passing in an array, as you suggested, or denoting
the appropriate array by product characteristics as per Toby).
To others this may not sound optimal, but this system is rather large,
and has become rather convoluted over time, and as such it's hard to
describe the different factors I need to account for; I really do
think that an OO approach would be overcomplicated in this case. I'm
sure that by this point I sound a bit like a crazy-man that can't make
up his mind, but I think for me this is been more of lesson in how
difficult it can be to keep code in your head over time and be able to
talk with others about it intelligently.
Navigation:
[Reply to this message]
|