Java interfaces

An interface is a like a class — well not really — it’s an interface, it contains 100% abstract methods. There is an explanation on abstract methods in this post . When you define interfaces, you are not reusing any behavior, you are enforcing behavior, you are guaranteeing that whoever inherits this interface, will provide operational capabilities to all the declared behaviors. That’s what an interface is, it is a way to enforce object contract (I’ve explained object contract in the discussion about Abstract classes).

Unlike abstract classes, which are capable of partial implementation (some methods can be abstract some methods can be concrete), interfaces do not provide any implementation at all, it only provides method signatures, hence all methods are abstract.

Java interfaces are defined using the “interface” keyword, followed by the interface name, you can define abstract methods and variables inside its body, like this.


//
//

interface Phone {

void answer();
void call();

}

I’ve defined an interface called Phone, and has 2 abstract methods, call() and answer()f. Any class that will implement the Phone interface, must provide implementation for all the signatures defined in the Phone interface, that is how the object contract is enforced.


//
//

interface Phone {

void answer();
void call();

}

class CellPhone implements Phone {

public void answer() {
//code to implement answer
}

public void call() {
//code to implement call
}

}

Class CellPhone implements the Phone interface, it overrides the 2 defined signatures on the Phone interface, notice also that the override must have public access, the reason for this is; all method defined in an interface is automatically abstract, and automatically public — you could be verbose and put these methods in the interface declaration, but you don’t need to be, it is implicit. Hence, remembering the rules on overriding, the overriding method cannot be more restrictive in access than the method being overriden.

Why bother with interfaces?

Like abstract classes, using interfaces is a design decision, programmers don’t normally discover in the middle of the coding that they need interfaces — well, normally, but sometimes they do (I do), specially on iterative environments, you will get to build the code, inspect it, tear it down, build it over again — refactor is the word I think that is being used to describe that cycle.

Anyway, back to interfaces, it is a design decision, you will know beforehand (sometimes from hindsight), that there will be behaviors you want to enforce across certain classes, but you don’t know what the operational details are, hence you will defer implementation on the derived classes.

Interfaces for multiple inheritance

The limitation of a single rooted class inheritance does not exist in interfaces, you can implement as many interfaces as you like, this is the way to achieve multiple inheritance in Java.

Let’s take this example.


//
//

interface Phone {

	void answer();
	void call();

}

interface Printer {
	void print();
}

class Fax implements Phone, Printer {

	public void answer() {
		//code to implement answer
	}

	public void call() {
		//code to implement call
	}

	public void print() {
		//code to print
	}

}

The Fax class implements from 2 interfaces, Phone and Printer. If you will implement more than one interface, just separate them with a comma, like the code above.

Questions you might have

Why didn’t we just put the print function inside the Phone? Answer – because a phone doesn’t print, remember the process of abstraction? Define the most frugal signatures for all your abstracted objects, until you cannot reduce it anymore.
Why didn’t we just put the print function as a concrete method in the Fax class? Answer – because there could be other classes wherein you would like to enforce the Printer behavior, this is just what I think at least, like I’ve mentioned, the use of interfaces and abstract classes is a design decision, and all decisions at the end of the day, needs to be in pursuit of development goals, meaning, your design decisions just needs to be defensible, if there were 10 designers, you might see 10 designs (some are better than others, of course).

Lastly, on interfaces

While the primary reason for having interfaces is to enforce object contract, there are interfaces in Java that doesn’t even have any signature. If you inspect the java.io.Serializable, you will find that it doesn’t define a single method!

java.io.Serializable

So what then is it used for? Imagine when you enter a building for the first time, you don’t work there. You will be challenged for your identity, you cannot just wander around in the building now can you? What you might do, is register with security, you will log your name and other information, then you will be given an ID, a temporary pass, so that when the other members of security sees you in the building, they will see your guest badge, it means you have a business to be there, you have been cleared to be there.

Think of of interfaces as guest badge, it allows you to go to certain places, where otherwise, you would not have been allowed. The Serializable interface is a guest badge, it allows you to access I/O (input/output) areas of Java, which is restricted, only authorized personnel can go there, and of course people (Classes) who have a guest badge.

If you want to show appreciation for my efforts dear reader, you could buy me a tall hazel nut Americano ($2) via PayPal. Thanks
Post navigation
(previous post)
(next post)
| | | | .

{0 Comments .. you can add one }

Leave a comment