Is there any true point to the Java interface? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

How are Java interface开发者_如何学编程s actually used?

I'm not talking from an accademic buzzword point of view but from a pratical developer point of view.

So taking the example:-

    Class1 implements Interface 
 public String methodOne() {
  return "This is Class1.methodOne()";
 }

 public String methodTwo() {
  return "This is Class1.methodTwo()";
 }
    }
Class2:

    Class2 implements Interface 
 public String methodOne() {
  return "This is Class2.methodOne()";
 }

 public String methodTwo() {
  return "This is Class2.methodTwo()";
 }
    }

Using the Interface:-

 Client {
  Interface intface = new Class1();

  intface.methodOne();
  intface.methodTwo();

  Interface intface = new Class2();
  intface.methodOne();
  intface.methodTwo();
}

But what are the benefits over just writting:-

 Client {
Class1 clas1 = new Class1();

clas1.methodOne();
clas1.methodTwo();

Class2 clas2 = new Class2();
clas2.methodOne();
clas2.methodTwo();
 }

And bypass the Interface altogether.

Interfaces just seem to be an additional layer of code for the sake of an additional layer of code, or is there more to them than just "Here are the methods that the class you are accessing has"?

---

When using standalone classes, you don't need interfaces. However, when you have a type hierarchy, interfaces are indeed indispensable.

Your simple example does not really do justice, but let's rename your interface to something more useful and concrete, e.g. a Sorter algorithm which can take a list of items and sort them. You can have several different sorting algorithms implemented, and you may want to change the algorithm used, based on the context (i.e. QuickSort is faster for large data sets, but BubbleSort is better for small data sets, etc.) So you don't want to tie the client code to one specific algorithm. By using the polymorphic Sorter type (implemented as an interface), you can pass different concrete sorter objects to the client, without it knowing (and caring) what algorithm it is actually using. And you can any time introduce a better sorting algorithm, or remove one which proved inefficient, without the clients noticing anything.

Such a feat would be impossible without interfaces. The alternative would be calling the sort method of choice directly from (possibly duplicated) if-else or switch blocks all over the place, with the inevitable possibility of introducing bugs when forgetting to update all places properly when a sorting algorithm is added/removed... not to mention that you would need to recompile all client code after each such change :-(

---

Suppose you want a collection of objects with both methods "Method1" and "Method2". And you don't want to programatically check each instance in the collection for its type.
A collection of objects the implement that interface saves you from doing this.
It calls Polymorphism and it is very useful.

---

The other folks have pretty much covered your question but, in a word: Yes!

The Java language was actually conceived as a fairly minimal object-oriented language, and interfaces were there from the very beginning. There are concepts of describing the relationships between classes that are hard or impossible to do without either interfaces or some performance-costly runtime type identification. All or almost all the patterns quoted in the famous Design Patterns book (here's the book itself) rely on interfaces.

---

(Not sure how I respond without it being seen as an answer but...)

Wow, so many answers so quickly, pretty impressive forum - cheers! :-D

So would it be reasonable to say that an Interface essentially sets the 'rules' for which the concrete classes must meet?

For example if I had classes Class1 & Class2, both of which have method 'getList()'. Without implementing an Interface Class1.getList() could return say a list of Strings and Class2.getList() could return Integers.

Essentially the Interface sets the rules that my Class has to have a method of getList() and that method must return List, so if both implement the Interface Lister with method 'public String getList();' I know that both Class1 & Class2 getList() returns a List of types String.

But concrete Class1 could be returning a list of departments whereas Class2 is a list of employees, but I know they both return a list of Strings.

This would probably become more useful if I had maybe half dozen or so classes each with half dozen methods all of which I want to ensure meet the .getList returns a list of type String 'rule'.

---

I use interfaces mostly for

• simulating multiple inheritance
• defining a service contract and a service implementation
• single method callback contracts

and because

• some dependency injection frameworks require interfaces to work
• mocking interfaces easier than mocking classes
• many AOP frameworks work better with interfaces than classes

And it is not really a layer of code between a service and its client, but more a formal contract.

---

Interfaces are useful if there is a chance that you'll need more than one implementation, maybe for another technology (different database) or for testing.

---

Interfaces define the contract of the type, without anu implementation details. This lets you program against the interface without knowing the actual implementation class.

An example of the advantage of interfaces using your code could be:

public void useInterface(Interface obj) {
    obj.methodOne();
    obj.methodTwo();
}

and calling it as in:

   useInterface(new Class1());
   useInterface(new Class2());

The Java collections classes make heavy use of interfaces, it allows you to switch implementations for lists and maps later without having to change the code using those instances.

---

Consider the following method which receives a list of 'intfaces', you don't have to know if you handle clas1 or clas2, you just want to handle something that 'is a' intface. You may add clas3 implement intface later on and it will stil work...

  public void callMethods(List<intface> intfaces){
    for(Interface intface : intfaces) {
      intface.methodOne();
      intface.methodTwo();
    }
  }