×

Loading...

Topic

This topic has been archived. It cannot be replied.
  • 工作学习 / 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.
枫下论坛主坛 /  工作学习 /  IT技术讨论