Interfaces in Java

Imagine that someone else has written a subroutine and you want to call it. Before you write the call, you have to answer a few questions. What is the subroutine called? How many values does it expect you to pass in, and what type is each one? What type of value does it send back? If any of these answers is wrong, the call cannot be made correctly. The information that answers these questions is the subroutine's specification.

A functional interface is one way to write that specification down in a Java file. In this article you will learn what a functional interface records, how to read one, how to predict what its file contains, and how to locate the exact point where a call disagrees with the specification. Keep the calling picture in mind as you read: the question we are working toward is what a functional interface contains, and how you can tell from the code whether a use of it matches what it promises.

The specification records three facts about that one subroutine. The first is its name. The second is its parameters, meaning how many there are and what type each one has. The third is its return type, which tells you what kind of value comes back to the caller.

The source's first example is a whole functional interface squeezed onto one line. It is saved in a file named FunctionR2R.java, which matches the name of the interface. The declaration is written out here as a single line inside the interface's braces:

Read it from left to right. The name of the interface is FunctionR2R. Inside the braces there is one line that names a subroutine, valueAt. That line lists one parameter, which has type double and is called x. The word double before valueAt is the return type. So the entire declaration says: there is a subroutine called valueAt, it takes one double, and it returns a double. The diagram below labels each part of the line.

Once you can name each part of a declaration, you can trace the whole specification by walking through it in order. Work through the valueAt declaration this way, and use the result to decide what a caller must supply and what the caller will receive.

The source gives a second example with a different shape. It describes a subroutine that does not return anything and takes two parameters, an array of strings and an int. The source does not give this declaration a name, so the example below uses a placeholder name, printLines, to show the structure.

The two declarations have the same structure even though their contents differ. Each one names a single subroutine and then states its parameters and its return type. A return type of void is still a return type. It tells the caller that no value comes back. The shape never changes; only the values placed into it do. Here the parameters are a String array and an int, and the return type is void.

Once you know the three facts, you can debug a broken use of a subroutine by asking where the use departs from the specification. Suppose some code calls valueAt with two numbers instead of one. The specification says there is one double parameter, so the mismatch is in the number of parameters. You do not need to guess; you compare the call against the declaration line by line, fact by fact.

A functional interface holds the specification of a subroutine, while a class that provides the subroutine holds the working code for it. Opening the interface file, you should expect to find the name, the parameters, and the return type, and you should not expect to find a body that does the work. The table compares the two files for the valueAt subroutine.