Solved

is this an appropriate subclass?

Posted on 2004-03-23
18
278 Views
Last Modified: 2010-03-31
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..

0
Comment
Question by:rosshind
  • 10
  • 3
  • 2
  • +3
18 Comments
 
LVL 13

Expert Comment

by:Webstorm
ID: 10659052
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.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10659060
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;
}
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10659089
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

0
 

Author Comment

by:rosshind
ID: 10659234
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...
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10659271
>>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?
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10659325
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;      
}
0
 
LVL 2

Expert Comment

by:Moroni24
ID: 10659354
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 :)
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10659660
>>(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
0
 
LVL 2

Expert Comment

by:Moroni24
ID: 10660154
Why would you say it's a bad case for a descendant?
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 
LVL 86

Accepted Solution

by:
CEHJ earned 500 total points
ID: 10660245
There's only one attribute that's different and that's quite a bit of overhead for one attribute, as well as inheritance's problems, which i referred to with the Gosling thing. Take a look at this ;-)

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10660342
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...
0
 
LVL 2

Expert Comment

by:Moroni24
ID: 10660797
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. :)
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10660845
>>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

0
 
LVL 92

Expert Comment

by:objects
ID: 10662579
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;
   ..
}
0
 
LVL 30

Expert Comment

by:GrandSchtroumpf
ID: 10662662
Excellent article CEHJ, i enjoyed it a lot.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10662717
:-)
0
 

Author Comment

by:rosshind
ID: 10822370
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.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 10822398
;-)
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

This was posted to the Netbeans forum a Feb, 2010 and I also sent it to Verisign. Who didn't help much in my struggles to get my application signed. ------------------------- Start The idea here is to target your cell phones with the correct…
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
Viewers will learn about arithmetic and Boolean expressions in Java and the logical operators used to create Boolean expressions. We will cover the symbols used for arithmetic expressions and define each logical operator and how to use them in Boole…
Viewers will learn one way to get user input in Java. Introduce the Scanner object: Declare the variable that stores the user input: An example prompting the user for input: Methods you need to invoke in order to properly get  user input:

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now