Interfaces

An interface is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface. An interface is not a class. Writing an interface is similar to writing a class, but they are two different concepts. A class describes the attributes and behaviors of an object. An interface contains behaviors that a class implements. Unless the class that implements the interface is abstract, all the methods of the interface need to be defined in the class. An interface is similar to a class in the following ways:

An interface can contain any number of methods. An interface is written in a file with a .java extension, with the name of the interface matching the name of the file. The bytecode of an interface appears in a .class file. Interfaces appear in packages, and their corresponding bytecode file must be in a directory structure that matches the package name.

However, an interface is different from a class in several ways, including:

You cannot instantiate an interface. An interface does not contain any constructors. All of the methods in an interface are abstract. An interface cannot contain instance fields. The only fields that can appear in an interface must be declared both static and final. An interface is not extended by a class; it is implemented by a class. An interface can extend multiple interfaces.

Declaring Interfaces:
The interface keyword is used to declare an interface. Here is a simple example to declare an interface:

Example:
Let us look encapsulation: at an example that depicts

/* File name : NameOfInterface.java */ import java.lang.*; //Any number of import statements public interface NameOfInterface { //Any number of final, static fields

//Any number of abstract method declarations\ }

Interfaces have the following properties:

An interface is implicitly abstract. You do not need to use the abstract keyword when declaring an interface. Each method in an interface is also implicitly abstract, so the abstract keyword is not needed. Methods in an interface are implicitly public.

Example:
/* File name : Animal.java */ interface Animal { public void eat(); public void travel(); }

Implementing Interfaces:
When a class implements an interface, you can think of the class as signing a contract, agreeing to perform the specific behaviors of the interface. If a class does not perform all the behaviors of the interface, the class must declare itself as abstract. A class uses the implements keyword to implement an interface. The implements keyword appears in

the class declaration following the extends portion of the declaration.

/* File name : MammalInt.java */ public class MammalInt implements Animal{ public void eat(){ System.out.println("Mammal eats"); } public void travel(){ System.out.println("Mammal travels"); } public int noOfLegs(){ return 0; } public static void main(String args[]){ MammalInt m = new MammalInt(); m.eat(); m.travel(); } }
This would produce following result:

Mammal eats Mammal travels

When overriding methods defined in interfaces there are several rules to be followed:

Checked exceptions should not be declared on implementation methods other than the ones declared by the interface method or subclasses of those declared by the interface method. The signature of the interface method and the same return type or subtype should be maintained when overriding the methods. An implementation class itself can be abstract and if so interface methods need not be implemented.

When implementation interfaces there are several rules:

A class can implement more than one interface at a time. A class can extend only one class, but implement many interfaces. An interface itself can extend another interface..

Extending Interfaces:
An interface can extend another interface, similarly to the way that a class can extend another class. The extends keyword is used to extend an interface, and the child interface inherits the methods of the parent interface.

The following Sports interface is extended by Hockey and Football interfaces.

//Filename: Sports.java public interface Sports { public void setHomeTeam(String name); public void setVisitingTeam(String name); } //Filename: Football.java public interface Football extends Sports { public void homeTeamScored(int points); public void visitingTeamScored(int points); public void endOfQuarter(int quarter); } //Filename: Hockey.java public interface Hockey extends Sports { public void homeGoalScored(); public void visitingGoalScored(); public void endOfPeriod(int period); public void overtimePeriod(int ot); }
The Hockey interface has four methods, but it inherits two from Sports; thus, a class that

implements Hockey needs to implement all six methods. Similarly, a class that implements Football needs to define the three methods from Football and the two methods from Sports.

Extending Multiple Interfaces:

A Java class can only extend one parent class. Multiple inheritance is not allowed. Interfaces are not classes, however, and an interface can extend more than one parent interface. The extends keyword is used once, and the parent interfaces are declared in a comma-separated list. For example, if the Hockey interface extended both Sports and Event, it would be declared as:

public interface Hockey extends Sports, Event

Tagging Interfaces:
The most common use of extending interfaces occurs when the parent interface does not contain any methods. For example, the MouseListener interface in the java.awt.event package extended java.util.EventListener, which is defined as:

package java.util; public interface EventListener {}

An interface with no methods in it is referred to as a tagging interface. There are two basic design purposes of tagging interfaces: Creates a common parent: As with the EventListener interface, which is extended by dozens of other interfaces in the Java API, you can use a tagging interface to create a common parent among a group of interfaces. For example, when an interface extends EventListener, the JVM knows that this particular interface is going to be used in an event delegation scenario. Adds a data type to a class: This situation is where the term tagging comes from. A class that implements a tagging interface does not need to define any methods (since the interface does not have any), but the class becomes an interface type through polymorphism.

Interfaces VS Abstract Classes

When should you use an abstract class, when an interface, when both? Interfaces and

abstract classes seem superficially to provide

almost the same capability. How do you decide which to use?

When To Use Interfaces When To Use Abstract

Interface Details Abstract

classes When To Use Both Summary Table

Details Links

When To Use Interfaces

An interface allows somebody to start from scratch to implement your interface or implement your interface in some other code whose original or primary purpose was quite different from your interface. To them, your

interface is only incidental, something that

have to add on to the their code to be able to use your package. The disadvantage is every method in the interface must be public. You might not want to expose everything.

When To Use Abstract classes

An abstract class, in contrast, provides more structure. It usually defines some default implementations and provides some tools useful

for a full implementation. The catch is, code using it must use your class as the base. That may be highly inconvenient if the other programmers wanting to use your package have already developed their own class hierarchy independently. In Java, a class can inherit from only one base class.

When to Use Both

You can offer the best of both worlds, an

interface and an abstract class. Implementors can ignore your abstract class
if they choose. The only drawback of doing that is calling methods via their interface name is slightly slower than calling them via their

abstract class name.

Summary Table
Interfaces vs Abstract Classes feature interface abstract class

Interfaces vs Abstract Classes feature interface abstract class

A class may extend only one abstract class.

A class may multiple implement inheritance several interfaces. An

An abstract class interface can provide default cannot complete code, implementa provide any default code, code at all, and/or just stubs tion much less that have to be default code. overridden. Static final constants only, can use them without qualification in classes that Both instance and static constants are possible. Both static and instance intialiser code are also possible to

constants

Interfaces vs Abstract Classes feature interface

implement the

abstract class
compute the constants.

interface.
On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional.

Interfaces vs Abstract Classes feature interface

An

abstract class

interface A third party class third party implementati must be rewritten on may be to extend only from convenience added to any the abstract
existing third class. party class. Interfaces are often used to describe the peripheral is-a vs -able abilities of a or can-do class, not its central identity, e.g. An An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Dalmatian descendants are Dogs, they are not Automobile merely dogable. class might Implemented

Interfaces vs Abstract Classes feature interface

implement the

abstract class

interfaces enumerate the Recyclable general things a interface, class can do, not which could the things a class is. apply to In a Java context, many users should otherwise typically totally implement the unrelated Runnable objects. interface rather than extending Thread, because theyre not really interested in providing some new Thread functionality, they

Interfaces vs Abstract Classes feature interface abstract class

normally just want some code to have the capability of running independently. They want to create something that can be run in a thread, not a new kind of thread.The similar is-a vs has-a debate comes up when you decide to inherit or delegate.

multiple inheritance for

Interfaces vs Abstract Classes feature interface abstract class

further discussion of is-a vs has-a You can write a new replacement module for an You must use the abstract class asis for the code base, with all its interface attendant baggage, that contains good or bad. The not one stick abstract class author has imposed of code in structure on you. common Depending on the with the cleverness of the existing implementati author of the abstract class, ons. When this may be good or you bad. implement the interface,

plug-in

Interfaces vs Abstract Classes feature interface

you start from scratch without any default implementati on. You have to obtain your tools from other classes; nothing comes with the

abstract class

interface
other than a few constants. This gives you freedom

Interfaces vs Abstract Classes feature interface

to implement a radically different internal design. If the various implementations If all the are all of a kind various and share a implementati common status and homogeneit ons share is behaviour, usually the method an abstract class y signatures, works best. then an Another issue interface thats important is works best. what I call "heterogeneous vs. homogeneous." If

abstract class

Interfaces vs Abstract Classes feature interface abstract class

implementors/subcl asses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homogeneous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards

Interfaces vs Abstract Classes feature interface abstract class

a common base class. If all they share is a set of method signatures, then tend towards an interface. If your client code talks only in terms of an interface, maintenanc you can e easily change the concrete implementati on behind it, using a Just like an

interface, if
your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a

factory

factory method.

Interfaces vs Abstract Classes feature interface abstract class

method.
Slow, requires extra indirection to find the correspondin g method in the actual class. Modern JVM (Java Fast Virtual

speed

Machine)s
are discovering ways to reduce this speed penalty.

Interfaces vs Abstract Classes feature interface abstract class

terseness

The constant You can put shared declarations code into an abstract class, in an interface where you cannot into an are all interface. If presumed public interfaces want to static share code, you final, so will have to write you may other bubblegum to leave that arrange that. You part out. You may use methods cant call any to compute the methods to initial values of compute the your constants and initial values variables, both of your instance and static. constants. You must declare You need not all the individual

Interfaces vs Abstract Classes feature interface

declare individual methods of an

abstract class
methods of an abstract class abstract.

interface abstract.
They are all presumed so. If you add a new method to an interface, you must adding functionality track down all implementati ons of that If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without

interface
in the

Interfaces vs Abstract Classes feature interface abstract class

universe and change. provide them with a concrete implementati on of that method.