Reusabilty of code lack in using interfaces for polymorphism

I just like to know that ..am i thinking right...

By using interfaces we lack reusability benefit in polymorphism,
interface X { void joke(); }
class A { public void method(){} }
class B extends A implements X { public void joke(){} }
class C extends A implements X{public void joke(){ <some code> } }

so we can see by suclassing we have to write code for method() once and reuse it in other classes ... but we have to implement joke() in every class....so we are lacking reusability benifit in this type of polymorphism....

-Atul

Hi Atul,

Interfaces define a way as to how a class implementing it should behave. This is nothing related to code reuse. Every class implementing an X interface will have to privide implementations of the method(s) defined in the interface. This is a basically a contract. However, each class implementing the interface method(s) can have different implementations for that method(s). I mean to say that the functionality implemented by each class might be different or specific to that class.

Chetan ,thanks for the reply, i understand what you like to say.. but one of the main benefits of polymorphism is code reuse..and i want to say , when we want to achieve polymorphism through interfaces , we lack code reusability.. which can be removed if we can extend more than one class but that has its own problem of deadly diomond of death structure...

so , i just thought of that and complety agree with you too..

-Atul

It's true that inheritance is a way to reuse code - that's what abstract classes are good for!

On the other hand, it is a typically problem for people new to OO to *overuse* inheritance for reusing code, and to not make enough use of the alternative: composition.

Just for fun, let's step around to the other side of reuse. If you write a class that uses only Interface references then THAT class is more reusable. For example, if you write:

we can only use your class when we have an ArrayList in hand. But if you wrote

we can now use your class with any kind of collection. Reusability goes up! In short, use the most abstract thing that will work, and an Interface is more abstract than an abstract or concrete class.

But you were exactly right at the top - creating an interface doesn't create any reusable method implementation code. Sometimes you'll see an interface and a default implementation bundled together as a neat compromise.

Abstract classes give more code reuse. As Ilja says, it's easy to accidentally overdo this. But it's common in frameworks that provide some default behavior yet give you the chance to plug in custom bits or override the defaults. Google for the "Hollywood principle" of design, a joke on the old line "don't call us, we'll call you."

You forgot to memtion the downside to programming to interfaces. You usually use access to some methods in the concrete class. Unless of course you cast, which defeats reusability.

In this example, if you needed an ArrayList, think long and hard about using a Collection or List reference. If you know for a fact that the class will ever only need an ArrayList, then why bother? If you know that you will need a specific method not in the interface, then what?

Not that anyone suggested it, do not blindly use interface references. There are many benefits but costs as well.

In this example, if you needed an ArrayList, think long and hard about using a Collection or List reference. If you know for a fact that the class will ever only need an ArrayList, then why bother?

Even if I knew that right now I only need an ArrayList, those requirements might change. Even if the method actuallu uses an ArrayList behind the scenes, there's no reason to expose that to clients.

There is no reason, unless you need to use methods from ArrayList that are not in Collection or List.

There is a tradeoff.

To quote myself ... "In short, use the most abstract thing that will work..."

The "that will work" part is important of course. If you need to call methods that only exist on ArrayList then accepting any Collection would be a poor choice.

Originally posted by Robert Hill:
There is no reason, unless you need to use methods from ArrayList that are not in Collection or List.

In my experience, it's *much* easier to change code from using a Collection to using an ArrayList than the other way around.

Originally posted by Robert Hill:
In this example, if you needed an ArrayList, think long and hard about using a Collection or List reference. If you know for a fact that the class will ever only need an ArrayList, then why bother?

Because you can't possibly know that for sure.

Software that is used needs to be changed, and often in unexpected ways. It's vitally important for the source code to be ductile. And using the most abstract type you can get away with makes the code more ductile.

Hi all,

back to the question,

Atul Shukla posted October 13, 2006 12:35 AM

I just like to know that ..am i thinking right...

By using interfaces we lack reusability benefit in polymorphism,
interface X { void joke(); } class A { public void method(){} } class B extends A implements X { public void joke(){} } class C extends A implements X{public void joke(){ <some code> } }
so we can see by suclassing we have to write code for method() once and reuse it in other classes ... but we have to implement joke() in every class....

But you only have to implement it once, you can reuse your code say in class D:

as you inherit the joke() method (and you are implementing X automatically).

Or am I misunderstanding you?

Yours,
Bu.

hey thanks for bringing my post again to the front.

Originally posted by Burkhard Hassel:

But you only have to implement it once, you can reuse your code say in class D:

class D extends C {}
as you inherit the joke() method (and you are implementing X automatically).

hey but what if D only implement X without extending C, then i again have to write code for joke().

To piggyback Burkhard�s point, if indeed you wanted the same implementation of joke() in class B and C, then the most logical thing to do is to make A implement the interface and since B and C both extend A, then they will inherit the method. If on the other hand, you need different implementations of the joke() method in all your classes, then there was no opportunity for code reuse to begin with.

Originally posted by Ilja Preuss:

Because you can't possibly know that for sure.

Software that is used needs to be changed, and often in unexpected ways. It's vitally important for the source code to be ductile. And using the most abstract type you can get away with makes the code more ductile.

Agreed, but mindlessly using the most abstract type you can get away with, can lead to problems as well.

I agree with the premise that you should use the most abstract type you can get away with. The key words here are "that you can get away with". It is like the design principle "Favor composition over inheritance". People forget the word favor or take it to mean always. That is flat-out wrong.

Using a more abstract reference type might be what you need. It might not either. My point is not to not use abstract type references, but to think about why you are doing it and how will the tradeoffs effect the program and its useability.

Originally posted by Robert Hill:
Agreed, but mindlessly using the most abstract type you can get away with, can lead to problems as well.

Well, doing *anything* mindlessly can lead to problems. So I'm all for doing things mindfully...

Using a more abstract reference type might be what you need. It might not either. My point is not to not use abstract type references, but to think about why you are doing it and how will the tradeoffs effect the program and its useability.

As I think about it, I actually quite often use List where I probably also could get away with Collection. I do that because *conceptionally* I do care about order at those places.

I can't imagine a situation in which using List in place of ArrayList would get me into trouble, though.

...I can't imagine a situation in which using List in place of ArrayList would get me into trouble, though.

It could make a difference if somewhere in the method you were doing a binary search for an element in the List. Doesn't make much sense to do a binary search on a LinkedList
[ October 17, 2006: Message edited by: Garrett Rowe ]

Originally posted by Garrett Rowe:
It could make a difference if somewhere in the method you were doing a binary search for an element in the List. Doesn't make much sense to do a binary search on a LinkedList

Well, for that purpose you should instead check for the RandomAccess tagging interface. That's what Collections.binarySearch does, by the way.

Yeah, but the performance will still be significantly better (for large N) with the ArrayList in that case. There's a valid point here where there are times where it makes a great deal of sense, performancewise, to use a an ArrayList rather than LinkedList, or vice versa, and in such a circumstance one shouldn't be too careless about changing to a different type later. It's also possible that one section of code works best with ArrayList, while another works best with LinkedList, and it may even make sense to copy from one type to another to avoid nasty performance hits. Checking for RandomAccess can help in some cases, but not always.

To take another example, you can also make a list with Arrays.asList(someArray). Which works great for some things. But try to add or remove an element, you'll get UnsupportedOperationException. And here you can't really look at the type to resolve the problem - unless you want to look at the private nested class type, assume the private implementation won't change in the future, and also assume there aren't any other specialized types of Lists which might cause you problems. (There are.) So what it boils down to for me is, to do most anything other than iteration, you shouldn't really trust any List that you don't know how it was created (usually in code you control). It's possible to be overly agnostic about the specific type you're dealing with.

And yes, I do still most always end up declaring my Collection variables as either List or Set (occasionally SortedSet), because using the most abstract type possible is generally a good thing. But there are limits. And the type alone often doesn't tell me all the details I need to know anyway.