This website requires Javascript to function properly. Please go to the setting of your web browser and enable Javascript for this website.

Ad by

推荐 OXIO 加拿大高速网络，最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

Ad by

推荐 OXIO 加拿大高速网络，最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

for discuss

blaise(blaise)

For me derive ShoppingCart from hashtable is a bad choice. ShoppingCart is not a "hashtable", and the semantics of derive(supposing he is using public derive) is "Is-A".
ShoppingCart can derive from Device, but not a HashTable. Device can be a abstract class with public virtual function FindByName();/FindById(); HashTable is definitely a implemetation issue, not an interface one, so it can appear in it's Device's private declaration part as pure virtual function such like GetHashValue();which require derived class to implement. Or it can totally don't appear, because you choose other way to implement the find.
I can't guess out what the authod's guildline is. But mine are:1. respect to the semantics. 2, use more aggregation than inherent.
I am not sure if this apply to Java, because I don't know much of it.

(#161876@0)
Last Updated: 2001-8-10
This post has been archived. It cannot be replied.

Report

Replies, comments and Discussions:

工作学习 / IT技术讨论 / A small design issue -jabber(jabber); 2001-8-9 {759} (#161202@0)
I am re-architecting a project. There are a lot of "unnatural" things in the original design. This is a java project. For example, ShoppingCart extends the java.util.Hashtable class. I am not saying this is wrong.

I have two questions here for discussion:

1) If the original designer did that intentionally, what's his/her design guide line? Repeat again: I am not saying the old design is wrong or bad.

2) If you were at my position and would like to re-consider this design decision, what pattern would be your solution?

For those who are very experienced, please do not educate me how to make decisions. I am NOT seeking advice here. I raise the above questions simpy for helping those who are anew in the programming world.

my idea. -macsym(日进斗斤); 2001-8-9 {252} (#161213@0)
I'm not sure what you want. here just my point:
1.that guy should thinking like C + some OO design. He was not clear about the OO.

2.It's depend your project time limit and usecase.If you have enough time, you'd re-consider this design decision.
why not. -gemlan(gem); 2001-8-9 {431} (#161708@0)
first of all, I am a green hand, I just want to learn something.
1. why can not use the hashtable? you can create a user object whose properties is map the information of this user. use this object as the key. then, you can have another object which extends the vector , use this one as the container of the items. Can you?
2. of course to let shopping cart extends hashtable is not necessary, but I think it can also make sense.

My opinion--- for discussion, not for debate -jabber(jabber); 2001-8-10 {1232} (#162135@0)
本文发表在 rolia.net 枫下论坛1) java.util.Hashtable is a utility class. In any case, it is a bad idea to have your business class extend a utility class. Indeed, ShoppingCart looks like a hashtable. The more proper approach is to let ShoppingCart use a hashtable. By doing so, one can also hide those not-wanted functions of hahstable (it has a lot of methods and ShoppingCart does not need them).

public class ShoppingCart{
private Hahstable contents = new Hashtable();

}
This is the so-called Delegation Pattern. It is used everywhere in Java.

2) The patterns are a good thing. Usually, people like to follow some patterns. However, poeple may also play against patterns. In the software industry, there is a school of ANTIPATTERN. Both the life and software are complicated. So it may be possible that sometimes a designer finds a good reason to use anti-patterns, to say, writing a business class by extending a utility class. Whenever we see something unnatural, we have better try to avoid say other people are wrong. The best words is " I don't understand...."

3) I am not working on ChoppingCart now. Actually, I am working on healthwell and created the above problem according to the real one in my design activity.更多精彩文章及讨论，请光临枫下论坛 rolia.net

for discuss -blaise(blaise); 2001-8-10 {836} (#161876@0)
For me derive ShoppingCart from hashtable is a bad choice. ShoppingCart is not a "hashtable", and the semantics of derive(supposing he is using public derive) is "Is-A".
ShoppingCart can derive from Device, but not a HashTable. Device can be a abstract class with public virtual function FindByName();/FindById(); HashTable is definitely a implemetation issue, not an interface one, so it can appear in it's Device's private declaration part as pure virtual function such like GetHashValue();which require derived class to implement. Or it can totally don't appear, because you choose other way to implement the find.
I can't guess out what the authod's guildline is. But mine are:1. respect to the semantics. 2, use more aggregation than inherent.
I am not sure if this apply to Java, because I don't know much of it.

@Las Vegas

for discuss

Replies, comments and Discussions:

More Topics