Method Declarations and Signatures

Imagine a drawing program where many different shapes need to be painted onto a screen. The drawing code wants to say, simply, stroke this shape with a pen. It does not care whether the shape is a circle, a polygon, or a piece of text. What it needs is a guarantee that every shape it receives knows how to be stroked.

Java gives you a construct for writing down that guarantee without writing any of the drawing logic itself. That construct is called an interface. This article answers two questions: what does an interface actually contain, and what rules govern the things placed inside it? Keep one idea in mind as you read: the interface describes a promise, and a class is the thing that keeps it.

Read the example from the outside in. The keyword interface opens the definition, and Strokeable is the name chosen for it. Inside the braces sits a single declaration, stroke, which accepts one Graphics parameter. The declaration ends with a semicolon. There is no body in curly braces, because the interface does not provide one. The body belongs to whichever class eventually implements Strokeable.

The example above is an illustrative reconstruction of the Strokeable example described in the source. The source specifies the interface name, the single stroke declaration, its Graphics parameter, and the semicolon. The return type is shown here as void for completeness, because Java method declarations always include one.

An interface is best seen as a container. The interface sits at the top. Inside it you may find method declarations, which describe behavior that implementing classes must supply, and variable declarations, which describe fixed values that implementing classes receive. The method branch carries an obligation: every class that implements the interface must provide a body for stroke. The variable branch carries a gift: every implementing class can use a declared constant without declaring it again. Keeping these two effects separate is the key to reading interfaces correctly.

A method declaration and a method implementation share the same first line, the part naming the method, its parameters, and its return type. They differ in what follows. The interface stops at the semicolon. A class that implements the interface writes the body in curly braces and does the actual work there. The diagram below places the two side by side so you can see what each one contains.

Because the two forms share a header, a class can be checked against the interface by comparing headers. The interface supplies the header, and the class must supply a body that goes with a matching header.

The method declaration inside an interface has several parts. Its return type, its name, and its parameter list together form the declaration that an implementing class must match. Modifiers come before the return type. For interface methods, the modifiers public and abstract are in effect even when they are not written, as the next section explains. The strip below annotates each token of the stroke declaration.

A modifier is a keyword such as public, abstract, static, or final. For interfaces, the source states fixed rules for which modifiers apply. Some are fixed by the language's rules, and writing them is optional because they are already implied. The distinction matters, because readers often assume that a missing keyword means something different. In an interface, the presence or absence of these keywords changes how the text reads, not what the interface requires.

The table below summarizes which modifiers are implied for each kind of member. The rule applies to what the compiler will treat the member as, so each row shows the status of a modifier in an interface.

When a program that uses interfaces fails, the most useful question is where the result first departed from what the interface promised. Start from the interface declaration and walk forward. Ask whether each declared method has a matching implementation in the class, and whether each constant is being used rather than redefined. The place where that comparison first fails is usually the place to look. The flowchart below traces that walk for a class that claims to implement Strokeable.