Jump to content
  • Advertisement
Sign in to follow this  
NUCLEAR RABBIT

Polymorphism and Interfaces in Java

This topic is 1409 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

 

So I recently learned about Interfaces and thought I had a good grasp, but I'm not sure why this example does what it does. It creates an interface object and assign it to an ArrayQueue<T>() object. Why not just write it as an ArrayQueue object to begin with, is there an advantage? I think my question relates more to polymorphism maybe, but I also thought that interfaces aren't objects that are initialized, just implemented from in another class.

 

Can anyone help clear the air? I would really appreciate any help! huh.png

Edited by NUCLEAR RABBIT

Share this post


Link to post
Share on other sites
Advertisement

Glass_Knife is right, you're sound a little confused about how an assignment works, and that's a use of Interfaces.

 

But, you're right about that particular line being more related to polymorfism than interfaces.

 

Yes, he could have used ArrayQueue<String> on the left too, but in OOP it's a good practice to keep things general. If you can use an interface or a base class to define a variable you should do it. That way, if you found ArrayQueue is not the best QueueInterface implementation, you only need to change one word in the code. It doesn't sound that great (change one word instead of two), but in bigger projects and complex situations it can make a difference, mainlly in the readability and mantainability of the code.

 

If you do it with base and derived classes you can get different behaviours if you're not carefull with abstract and overriten methods, but with interfaces you won't have too much troubles.

Edited by DiegoSLTS

Share this post


Link to post
Share on other sites


You've got this backwards. The code creates an object of type ArrayQueue and assigns it to a reference of type QueueInterface. Because ArrayQueue implements the QueueInterface, ArrayQueue "is a" QueueInterface. It is valid for a QueueInterface to point to an ArrayQueue.

Ohhhh, okay. I was def wrong on how the assignment was going on. Makes a lot more sense now!

 


Yes, he could have used ArrayQueue on the left too, but in OOP it's a good practice to keep things general. If you can use an interface or a base class to define a variable you should do it. That way, if you found ArrayQueue is not the best QueueInterface implementation, you only need to change one word in the code. It doesn't sound that great (change one word instead of two), but in bigger projects and complex situations it can make a difference, mainlly in the readability and mantainability of the code.

I see your point about "general programming", not sure why I skipped that aspect. I guess I was just confused when I thought an interface object was being created, which didnt make sense to me because the methods aren't defined. Totally forgot that myQueue was a reference type and it makes sense for it to refer to a type that extends QueueInterface because it "is-a" type of QueueInterface

 

Thanks guys! biggrin.png

Share this post


Link to post
Share on other sites

TL;DR;

 

The object you create is of type ArrayQueue, because that is what stands right after the new keyword. If ArrayQueue implements QueueInterface, then it declares that every ArrayQueue can be treated exactly as if it were a QueueInterface. This is why you can assign an object of type ArrayQueue to a variable of type QueueInterface. Then on, you use a variable of type QueueInterface to refer to an object that is, in fact, ArrayQueue. Since QueueInterface is an interface, all method calls (myQueue.enqueue("Jim"), etc) on the variable myQueue are actually calls to methods with the same signature in ArrayQueue.

 

Don't use interfaces for all your variables, this is wrong and evil. Since it is evil, it is done only when it will save your life. Unless you have purpose and a concrete problem to solve, don't use interfaces.

 

The Long Story

 

What @DiegoSLTS said is correct, technically.

 

However, "If you can use an interface or a base class to define a variable you should do it" is correct mostly for certain types of projects, and not in all places.

 

Scope is important. Methods perform short tasks, and in a short tasks you should be quite certain whether or not to use an ArrayList. Therefore, it doesn't make sense at all to use for a local variable List instead of ArrayList, unless you accept is as a parameter or it comes as a field. The more general a piece of code is, the more difficult it gets to understand.

 

Using an interface instead of a concrete implementation (class) is only done on purpose - you usually apply design patterns so that other programmers can more easily decipher your intent. A very common mistake is to program in some extensibility (e.g. use interfaces instead of a class) and provide no practical way for your class/module to be extended by clients.

 

People that teach teach OO in universities are usually scientists, and they publish papers. Code for papers is rarely available even a few years after publication, it is never maintained, and "big" projects for papers are 10,000 lines of code. Also, code is sometimes written by bachelor students or masters, and teams are rarely bigger than 5 people. What is more, researchers are rarely given the chance to analyze or apply their theories on code "in the wild", as companies are keen on keeping their IP.

 

What I am trying to say is that there is a very big divide between what in theory is good, e.g.

 

If you can use an interface or a base class to define a variable you should do it. That way, if you found ArrayQueue is not the best QueueInterface implementation, you only need to change one word in the code. It doesn't sound that great (change one word instead of two), but in bigger projects and complex situations it can make a difference, mainlly in the readability and mantainability of the code

 

and practice. Both researchers and programmers "in the wild" (the jargon they sometimes use for us) agree that complexity is your enemy in software engineering.

 

What is simple is to be given a task and do it in the simplest possible way. Using interfaces for everything is wrong, because it is needless complexity. We programmers love code that is "good", that we can brag about, and this is why smart hacks and complexity spread like an infectious disease in code. Doing really good code requires you to have the discipline to refrain from adding that fancy design pattern before you need it. This discipline takes a lot of practice.

 

 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!