question about polymorphism

[Fonzie]

I'm having some difficulty grasping the usefulness of this. I understand the benefits to be had from it, but it seems there are some rather large drawbacks.

For example, lets say I have two classes, CreditCard and RewardCard. RewardCard is a child of CreditCard. According to my teacher, according to make use of polymorphism, this line of code would be employed if a user selected a reward card:

CreditCard name = new RewardCard(integer, "string");

and this line if they selected a basic one:

CreditCard name = new CreditCard(integer, "string");

So now I can make polymorphic use of the method charge, which is overridden in RewardCard. However, it seems that I cannot make use of any of the unique methods in RewardCard, that is, without casing, I cannot use the methods in RewardCard that are not in CreditCard. It seems like this drawback outweighs the benefits, as the only new methods of RewardCard I can make quick use of are the overridden methods.

My second problem relies with interfaces. In particular List and ArrayList. My book instructs me that in order to make an arraylist this line is used:

List<String> bag = new ArrayList<String>();

My first assumption of why this is done is so that it can make use of polymorphism. But then I realize (assuming I'm not crazy) that all the methods in an interface are just headers. Polymorphism can't even exist in this cirumstance. Doesn't this mean that the aforementioned line of code is imposing a restriction pointlessly? wouldn't the line:

ArrayList<String> bag = new ArrayList<String>();

be far more pragmatic?

[wtd]

Fonzie wrote:

I'm having some difficulty grasping the usefulness of this. I understand the benefits to be had from it, but it seems there are some rather large drawbacks.

For example, lets say I have two classes, CreditCard and RewardCard. RewardCard is a child of CreditCard. According to my teacher, according to make use of polymorphism, this line of code would be employed if a user selected a reward card:

code:

CreditCard name = new RewardCard(integer, "string");

and this line if they selected a basic one:

code:

CreditCard name = new CreditCard(integer, "string");

So now I can make polymorphic use of the method charge, which is overridden in RewardCard. However, it seems that I cannot make use of any of the unique methods in RewardCard, that is, without casing, I cannot use the methods in RewardCard that are not in CreditCard. It seems like this drawback outweighs the benefits, as the only new methods of RewardCard I can make quick use of are the overridden methods.

This is just how statically-typed languages like Java work.

As far as the Java compiler is concerned, the variable "name" is of type CreditCard. The CreditCard type only has a certain set of methods.

Fonzie wrote:

My second problem relies with interfaces. In particular List and ArrayList. My book instructs me that in order to make an arraylist this line is used:

code:

List<String> bag = new ArrayList<String>();

My first assumption of why this is done is so that it can make use of polymorphism. But then I realize (assuming I'm not crazy) that all the methods in an interface are just headers. Polymorphism can't even exist in this cirumstance. Doesn't this mean that the aforementioned line of code is imposing a restriction pointlessly? wouldn't the line:

code:

ArrayList<String> bag = new ArrayList<String>();

be far more pragmatic?

In many cases, yes, you would use this latter bit of code.

However, the "restriction" can be quite beneficial when you consider method parameters.

By using the List type for a parameter, you can ensure that whatever is passed in has a certain set of methods. At the same time, though, you don't require that those methods be implemented in any particular way.

For instance, the list you would pass in would not have to be an ArrayList.

[Aziz]

I'm gonna dip into SWING to take a look at this, or rather AWT in general.

All widgets, or whatever, things, you add into your GUIs are 'Components'. And in many containers, you can call 'getComponent(index)' that returns a Component object. Now if you know that component is either a button or a label, a piece of code could be:

code:

//class members JButton button; JLabel label; //in a method Component comp = panel.getComponent(0); if (comp instanceof JButton) {   //for button   button = (JButton) comp;   label = new JLabel("label"); } else if (comp instanceof JLabel) {   //for label   label= (JLabel) comp;   button = new JButton("button"); } else {   //not button or label   label = new JLabel("label");   button = new JButton("button"); }

maybe that helped, maybe not. Also, in your CreditCard object, by extending CreditCard to RewardCard, you can create a RewardCard:

code:

RewardCard = new RewardCard();

or, if simply have a CreditCard passed:

code:

public void buySomething(CreditCard ccard) {   if (ccard instanceof RewardCard) {     RewardCard rcard = (RewardCard) rcard;     //do stuff with the reward card   }   //do normal stuff whether its a reward card or simple credit card }

[ericfourfour]

Why not just declare it

Java:

RewardCard name = new RewardCard(integer, "string");

so you have access to RewardCard's methods. Since a RewardCard "is a" CreditCard, RewardCard has access to all of CreditCard's public and protected members. If ever you have a method that requires a CreditCard parameter you can send a RewardCard in because it "is a" CreditCard. I really don't see where you see the drawbacks. If you want to use a RewardCard just declare it as one.

Here is an example I thought up by using my surroundings. Let's say I want to make a pepsi bottle and a water bottle. What is common between the two? They "are both" bottles. In that case we would make a bottle class. In that class we would keep all of the attributes that are common between the bottles (like volume). Then we would make another class for the pepsi bottle (that has sugar and carbonation) and the water bottle (that has water and minerals) and they would extend the bottle class.

In one case, if I wanted to drink the pepsi bottle and use its distinct attributes, like sugar to give me energy, I would declare it as a pepsi bottle. If I wanted to drink the water bottle and use its distinct attributes, like water (duh), I would need to declare it as a water bottle.

In another case, does the recycling bin need to know that it is specifically a pepsi bottle or a water bottle? No, it only cares if it is a bottle. In that case, we would only need to declare it as a bottle. (Speaking of recycling, I have 4 pepsi bottles and a water bottle sitting on my desk and floor).