Link to home
Start Free TrialLog in
Avatar of rosshind
rosshind

asked on

is this an appropriate subclass?

Hi,

I am building an ECommerce application.

 What i need to do is to 'counter sell', for example if you go into a shoe store, normally at the counter, the sales attendant will try to sell you shoe polish, laces, a shoe horn etc.  Thats what I need to do on the site.

One part of the datebase has this structure:

two tables, tblAccessoryProduct and tblProduct

For every Product field(e.g. the shoe) there can be many AccessoryProduct fields (e.g. the laces, or the shoe polish)


The Product table holds the usual stuff, ProductID, product name, price, short description, long description, RRP etc.
The AccessoryProduct table only has 3 columns.

ProductID  //this is the main product.  i.e. the ProductID of the shoe
AccessoryProductID  //This is the ProductID of the shoe polish, the data for which is held in the Product table, like all the other products
AccessoryProductDescription // this is a field to hold a description specific to this relationship e.g.In this example "Remember the tan shoe polish to use especially for your Dr Martin boots."


The question (finally) is :

Should AccessoryProduct be implemented as a subclass of my Product Object, or should it be an object on its own.  In essence AccessoryProduct is a Product, but is has an association with another specific product as well as a description.

What say you?

Thanks in advance..

Avatar of Webstorm
Webstorm

I think AccessoryProduct should be implemented as a subclass of my Product Object.
If you encounter some problems extending the Product class, post your code.
Avatar of CEHJ
The way this is often implemented in ecommerce apps is to have an ancillary class, containing a list or map. So you could have

class Product {
      private Map accessoryProducts;
}
Or


class Product {
    private Collection accessoryProducts;
}

would probably be better. There may be no need for a subclass, i.e. the Collection could be of type Product

Avatar of rosshind

ASKER

Thanks,

The resolved many to many relationships in database have been handled fine, because there is no information to be stored about the actual rielatioship, fields are just realted to eachother or they are not, so my DAO object can generate an ArrayList of related objects of the same type and leaves it at that, no extra classes.

There is greater complexity in this one because info has to be stored which is specific to the relationship i.e. the AccessoryProductDescription.  Thats why I though I might need to subclass...
>>so my DAO object can generate an ArrayList of related objects of the same type and leaves it at that, no extra classes.

Yes, as i said - probably no need for further types - they're probably all Products anyway i would think.

>>i.e. the AccessoryProductDescription.  

As distinct from the normal description? i.e. how/why is this Product related to its parent?
As i think the answer to that question of mine is almost certainly yes, this suggestion ties up with two of my earlier comments. Let me know if you need more comments:


class Product {
    private Collection accessoryProducts; // collection of type AccessoryProductMapping
}


class AccessoryProductMapping {
      private Product key;
      private String description;      
}
Hi Rosshind,

The only need I see for a subclass is where you're trying to perform the "up sell" or what you called the "counter sale". We're still talking about an item, but now we've included the up sell text (A perfect case for a descendant) . You're subclass should be responsible for dispalying the up sell text in addition to any other specific accessory related tasks (i.e. price discounts, etc). The other functionality such as adding it to the invoice, or whatever, should already be contained in the ancestor.

Hope that helps :)
>>(A perfect case for a descendant)

It's actually quite a bad case for a descendant ;-)

On a related matter, at a recent Java conference James Gosling was asked what he would do differently if he were designing Java all over again and he replied "I'd do away with classes". By this he really meant class inheritance, in favour of interface implementation
Why would you say it's a bad case for a descendant?
ASKER CERTIFIED SOLUTION
Avatar of CEHJ
CEHJ
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Also, what we're talking about here is two entities of essentially the same type and it's been decided that they are in some way related. That relation is itself a candidate for an abstraction, leaving the entity type unchanged. If anything, it's the type of of the relation class (AccessoryProductMapping in my example) that could be a candidate for having an inheritance hierarchy.

AccessoryProductMapping may be too specific a name on reflection as it doesn't sound abstract enough. ProductToProductMapping could be better...
Hi CEHJ,

I took a few minutes to read the article you posted. Additionally, I read many of the scathing comments posted about the article.

All in all I found it useful, thanks for posting it.

However, the problem with implementations is the need to re-write each implementation rather than just the new code as extend provides for. I really have a hard time with that. It feels counter productive.

In Roshind's case, he really is just extending the functionality of his products class. You're right that he could rewrite it as an interface, but I suspect that it's more work than what he's looking for.

As to the additional overhead, I don't see how extending is more overhead then two verbose interface implementations.

Anyway, I think everyone has given good suggestions and any would work for him. :)
>>the problem with implementations is the need to re-write each implementation ...

Yes i agree - and of course i'm not backing any of this necessarily. I don't think implementation inheritance is going to disappear any time soon.

The reason i don't think a subclass is appropriate is really more to do with my last comment

From what you have said it is a seperate data class, storing the relationship between product and accessory.

class AccessoryProduct
{
   ID ProductID;
   ID AccessoryProductID;
   String Description;
   ..
}
Excellent article CEHJ, i enjoyed it a lot.
:-)
Thanks CJ, great stuff.  Sorry about the delay in responding.  My brain is turning to code and i'm getting a bit behind with clearing up the posts,  thanks.
;-)