Some questions related to "Prefer interfaces to abstract classes"

After nearly two years' experience with Java, I have almost accept this principle "Prefer interfaces to abstract classes", but still my biggest concern about this is that - it is impossible to add a new method to a public interface without breaking all existing programs, but with abstract class, it is OK. So I want to know, when you guys design your system, how you deal with this.

two questions related to this:

1. Why Java is designed to only permit single inheritence, any stories behind the scene? I think some major reasons why "prefer interfaces to abstract classes" is accepted is rooted in this limitation.

2. Base on the fact that once an interface is out of box and widely implemented, it is almost impossible to change it. So how you guys design your interfaces? Could you share some? In my idea, I would design my interfaces as compact as possible.

[888 byte] By [bshya] at [2007-11-27 5:32:15]
# 1

> two questions related to this:

> 1. Why Java is designed to only permit single

> inheritence, any stories behind the scene? I think

> some major reasons why "prefer interfaces to abstract

> classes" is accepted is rooted in this limitation.

Yes, one of the reasons interfaces are better is that you can only extend one class, but implement many interfaces. Say you have a concrete class that should "implement" two different types. If those types were defined as abstract classes, you could only use one type. You could implement both types if they were interfaces though.

> 2. Base on the fact that once an interface is out of

> box and widely implemented, it is almost impossible

> to change it. So how you guys design your interfaces?

> Could you share some? In my idea, I would design my

> interfaces as compact as possible.

You could extend the interface and start using that if you didn't want to break existing code. You couldn't use that implementation as an Interface1 though, since the new methods only exist in Interface2, so that's not an optimal solution.

hunter9000a at 2007-7-12 14:58:11 > top of Java-index,Java Essentials,Java Programming...
# 2

> After nearly two years' experience with Java, I have

> almost accept this principle "Prefer interfaces to

> abstract classes", but still my biggest concern about

> this is that - it is impossible to add a new method

> to a public interface without breaking all existing

> programs, but with abstract class, it is OK. So I

> want to know, when you guys design your system, how

> you deal with this.

>

> two questions related to this:

> 1. Why Java is designed to only permit single

> inheritence, any stories behind the scene? I think

> some major reasons why "prefer interfaces to abstract

> classes" is accepted is rooted in this limitation.

It's not much of a limitation.

There are two kinds of MI--interface and implementation. Usually when people talk about MI, they talk about MI of implementation--code sharing. But that's not what inheritance--single OR multiple--is about. Inheritance is about TYPE. and MI of interface--which we have in Java--let's you define one thing to be of many types. THAT is far more important and useful than code sharing.

jverda at 2007-7-12 14:58:11 > top of Java-index,Java Essentials,Java Programming...
# 3

> > two questions related to this:

> > 1. Why Java is designed to only permit single

> > inheritence, any stories behind the scene? I think

> > some major reasons why "prefer interfaces to

> abstract

> > classes" is accepted is rooted in this limitation.

>

> Yes, one of the reasons interfaces are better is that

> you can only extend one class, but implement many

> interfaces. Say you have a concrete class that should

> "implement" two different types. If those types were

> defined as abstract classes, you could only use one

> type. You could implement both types if they were

> interfaces though.

So why java is designed to have this limitation? There may be some arguments before this is settled down. I always like to hear this kind of stories:)

> > 2. Base on the fact that once an interface is out

> of

> > box and widely implemented, it is almost

> impossible

> > to change it. So how you guys design your

> interfaces?

> > Could you share some? In my idea, I would design

> my

> > interfaces as compact as possible.

>

> You could extend the interface and start using that

> if you didn't want to break existing code. You

> couldn't use that implementation as an Interface1

> though, since the new methods only exist in

> Interface2, so that's not an optimal solution.

So we may always need to add a new interface when we just want to add a new method.

bshya at 2007-7-12 14:58:11 > top of Java-index,Java Essentials,Java Programming...
# 4
Sorry jverd , what is MI? interested.
bshya at 2007-7-12 14:58:11 > top of Java-index,Java Essentials,Java Programming...
# 5
> So why java is designed to have this limitation?It's not a limitation.
jverda at 2007-7-12 14:58:11 > top of Java-index,Java Essentials,Java Programming...
# 6
> Sorry jverd , what is MI? interested.What have we been talking about that has initials "M" and "I"?Hint: It rhymes with Fultiple Finheritance.
jverda at 2007-7-12 14:58:11 > top of Java-index,Java Essentials,Java Programming...