Difference between Implementation Inheritance and interface inheriatance?

[Rohan Deshmkh]

I know what is Implementation inheritance but i don't know what's interface inheritance.Can anyone explain it with example?
Also i was reading a book , and it said that:

In case where you want to use implementation inheritance then it is usually provided by an abstract base class

For polymorphic interface inheritance, where the client wants to only deal with a type and does not care about the actual implementation use interfaces. If you need to change your design frequently, you should prefer using interface to abstract.

I could not understand the line about interface inheritance.Also why should we prefer interface over abstract classes when we want to frequently change our design?
What i think is other way round because if we add new method suppose in a interface then we will have to define this method in every classes that implements this interface.But if we add a new method to an abstract class, then we need not define it for every class that extends this class.So where am i wrong?

[Paul Witten]

Rohan Deshmkh wrote:I could not understand the line about interface inheritance. Also why should we prefer interface over abstract classes when we want to frequently change our design?

What they mean is "if you are forced to redesign your class often then that indicates that a polymorphic interface(s) would be preferable."

I think they mean that it's not desirable to be forced to redesign a base class often. Stability (of what code already exists) is the goal.

[Campbell Ritchie]

Which book? You should always tell us where such quotes come from.

[Rohan Deshmkh]

Campbell Ritchie wrote:Which book? You should always tell us where such quotes come from.

I read it from this book:
http://www.amazon.com/Java-J2EE-Job-Interview-Companion/dp/1411668243

[Rohan Deshmkh]

Paul Witten wrote:
What they mean is "if you are forced to redesign your class often then that indicates that a polymorphic interface(s) would be preferable."

Yes i understood that, but i wanted to know why polymorphic interface would be preferable?And also what advantages does interface have over abstract class when redesigning is the issue?

[Campbell Ritchie]

Thank you for quoting the book.
I don’t know whether our FAQ would help you. I did not think that passage from the book is very clear; it might be clearer in the context of the whole paragraph, however.

I don’t know whether this sort of example helps, but let’s try:-

package ...;
import ...;

public interface TaxCalculator extends Serializable
{
   void setTaxCode(String code) throws Exception;
   void setTaxPeriodType(TaxPeriod t);
   void setTaxPeriodNumber(int number) throws Exception;
   void increaseEarnings(BigDecimal currentGrossPay);
   Tax getTax();
}

public class BritishTax extends Tax ...

public class FrenchTax extends Tax ...

public class BritishTaxCalculator implements TaxCalculator ...

public class FrenchTaxCalculator implements TaxCalculator ...

[Rohan Deshmkh]

Campbell Ritchie wrote:Thank you for quoting the book.
I don’t know whether our FAQ would help you. I did not think that passage from the book is very clear; it might be clearer in the context of the whole paragraph, however.

I don’t know whether this sort of example helps, but let’s try:-

package ...;
import ...;

public interface TaxCalculator extends Serializable
{
   void setTaxCode(String code) throws Exception;
   void setTaxPeriodType(TaxPeriod t);
   void setTaxPeriodNumber(int number) throws Exception;
   void increaseEarnings(BigDecimal currentGrossPay);
   Tax getTax();
}

public class BritishTax extends Tax ...

public class FrenchTax extends Tax ...

public class BritishTaxCalculator implements TaxCalculator ...

public class FrenchTaxCalculator implements TaxCalculator ...

I could not understand how your above code is advantageous in code reuse.Here is the full context from that book:

Q. When to use an abstract class?:
In case where you want to use implementation inheritancethen it is
usually provided by an abstract base class. Abstract classes are excellent candidates inside of application
frameworks. Abstract classes let you define some default behavior and force subclasses to provide any specific
behavior. Care should be taken not to overuse implementation inheritance as discussed in Q10in Java section.

Q. When to use an interface?:
For polymorphic interface inheritance, where the client wants to only deal with a
type and does not care about the actual implementation use interfaces. If you need to change your design
frequently, you should prefer using interface to abstract. COCoding to an interfacereduces coupling and
interface inheritance can achieve code reusewith the help of object composition. For example:The Spring
framework’s dependency injection promotes code to an interface principle. Another justification for using interfaces
is that they solve the ‘diamond problem’ of traditional multiple inheritance as shown in the figure. Java does not
support multiple inheritance. Java only supports multiple interface inheritance. Interface will solve all the
ambiguities caused by this ‘diamond problem

[Campbell Ritchie]

We can’t win them all. Maybe somebody else will have a better example.

I am a bit worried about the book saying that multiple interfaces will solve all the ambiguities of the diamond problem. Here are two examples of what it doesn’t solve:-

// example 1
public interface Foo
{
   Foo foo(int i);
}

public interface Bar
{
   Bar Foo(int i);
}

public class Bazz implements Foo, Bar
{
  // Won't compile because of diamond problem ambiguity
}

Example 2 follows:-

public interface Foo
{
   /**
    * Swoggles the horn. Must not be used for flunking the dwyle
    */
   Foo foo(int i);
}

public interface Bar
{
   /**
    * Flunks the dwyle. Must not be used for swoggling the horn
    */
   Foo Foo(int i);
}

public class Bazz implements Foo, Bar
{
  // Compiles happily, but what does the Foo method do?
}

[Jeff Verdegan]

I don't agree with this statement: "If you need to change your design frequently, you should prefer using interface to abstract. " I don't think there's any inherent advantage to interfaces over abstract classes when it comes to frequently changing design. And "code reuse with the help of object composition" can be achieved just as easily with abstract classes or even concrete classes as with interfaces.

And in fact, I don't even buy into the idea that there is an "interface vs. abstract class" choice. The two serve different purposes, and while there is some overlap where you could use either one, it's not that large, and to me the choice has always been obvious. Is there some reasonable common/default behavior that could be provided for at least some implementations? Then use abstract class. Are we defining a pure abstract type? Then use interface. And in many cases we use both.

This bit is also nonsense, IMHO:

Another justification for using interfaces
is that they solve the ‘diamond problem’ of traditional multiple inheritance as shown in the figure. Java does not
support multiple inheritance. Java only supports multiple interface inheritance. Interface will solve all the
ambiguities caused by this ‘diamond problem

Interfaces don't solve the diamond problem. The lack of multiple inheritance of implementation solves some of the diamond problem. But using interfaces can still have its own diamond problem, at least in theory, though I've never run across it in practice.

public interface Cowboy {
  void draw();
}

public interface Artist {
  void draw();
}

public class CowBartOyIst implements Cowboy, Artist {
  public void draw() {
    // Do we draw a picture or draw our gun?
    // By simply having this method, our code will compile,
    // but we can't reasonably meet the contract of both interfaces
    // that we claim to implement.
  }
}

Our CowBartOyIst inherits from two parent types (yes, interface implementation is inheritance), so it's a potential diamond problem.

[dennis deems]

Jeff Verdegan wrote:Interfaces don't solve the diamond problem. The lack of multiple inheritance of implementation solves some of the diamond problem. But using interfaces can still have its own diamond problem, at least in theory, though I've never run across it in practice.

public interface Cowboy {
  void draw();
}

public interface Artist {
  void draw();
}

public class CowBartOyIst implements Cowboy, Artist {
  public void draw() {
    // Do we draw a picture or draw our gun?
    // By simply having this method, our code will compile,
    // but we can't reasonably meet the contract of both interfaces
    // that we claim to implement.
  }
}

Our CowBartOyIst inherits from two parent types (yes, interface implementation is inheritance), so it's a potential diamond problem.

Witty and instructive! Belongs in the Java Contrary Examples Hall of Fame.

[Jeff Verdegan]

I'm glad you like it, although I can't claim credit. Cowboy/Artist is a classic illustration of the diamond problem.

[Rohan Deshmkh]

Hey thanks Jeff , i got some of the things you mentioned but I didn't understand the following quote:

Jeff Verdegan wrote:. Is there some reasonable common/default behavior that could be provided for at least some implementations? Then use abstract class. Are we defining a pure abstract type? Then use interface. And in many cases we use both.

I understood about when to use abstract class but i am not able to understand this line:

Are we defining a pure abstract type? Then use interface.


Can you give an example about pure abstract type?

[Jeff Verdegan]

Rohan Deshmkh wrote:
I understood about when to use abstract class but i am not able to understand this line:

Are we defining a pure abstract type? Then use interface.


Can you give an example about pure abstract type?

java.util.Collection, java.util.List, java.sql.Connection, java.sql.Statement, java.sql.RestultSet.

In all cases, we define simply what this type must do. A Collection must be able to add, remove, etc. A List must be able to do everything a Collection can do, but since it is ordered, must also be able to retrieve, insert, or update elements at specific indices. And we don't care how it will be done. We're just defining what it must do.

For the java.util ones, even though the core APIs provide some implementations--and in fact there are abstract classes for Lists--they wanted to allow anybody to implement those interfaces however they want, without being bound to any particular parent class.

For the java.sql ones, the core APIs don't provide any implementation. DB vendors or possibly third parties provide libraries that can interact with the various DBs, and we don't know or care what their classes look like or how they're structured or implemented. All that matters to us is that if we have a Statement, we can call executeQuery() and get a ResultSet back, and we can in turn call next(), getXxx(), etc. on that ResultSet to get us our data.

Interfaces simply say, "If you want to call yourself X, here are the operations you must provide."

[Rohan Deshmkh]

Thanks Jeff for explaining it with the example, i understood what you said.