Chapter 2 Introducing Interfaces Summary prepared by Kirk Scott

A class’s (public) interface is the collection of methods that can be called on it (If you declare instance variables public, they also become part of the interface) You can think of the interface as a contract or commitment to do what a descriptive method name implies The implementation of the interface consists of the code for the methods

As you know, Java elevates the idea of an interface to a separate concept A Java interface consists of the specification of the methods A class which implements the interface is committed to providing code which performs the desired actions for those methods Separating the interface specifications into a separate construct makes two things possible:

1. Two different classes can be declared to implement the same interface This means that instances of those two classes can play the same role in various pieces of code In other words, not only can you have a superclass reference You can also have an interface reference in code

2. A given class can implement more than one interface As pointed out in CSCE 202, interfaces are a substitute for multiple inheritance in Java More generally, you can observe this: It means that an object of a given class can play different roles in different pieces of software, depending on its interface reference

Interfaces allow for great flexibility in code design and implementation The simple idea of an interface reference can be extremely useful Interfaces also form the foundation for a number of different design patterns

Interfaces and Abstract Classes C++ and Smalltalk do not have interfaces They have abstract classes Java interfaces can be described as completely abstract classes Some authors don’t like that comparison, but in this book it is considered acceptable

Challenge 2.1 Write down three differences between abstract classes and interfaces in Java

Solution 2.1 An abstract class with no nonabstract methods is similar to an interface in terms of its utility. However, note the following. A class can implement any number of interfaces but can subclass at most one abstract class

An abstract class can have nonabstract methods; al the methods of an interface are effectively abstract. An abstract class can declare and use fields; an interface cannot, although it can create static final constants

An abstract class can have methods whose access is public, protected, private, or none (package). An interface’s methods are implicitly public. An abstract class can define constructors; an interface cannot.

It is possible to write object-oriented software without interfaces, using a language like C++ However, the existence of interfaces in Java is a net plus The book asserts that they are particularly useful in n-tier (multi-tier, client-server) development

The book next gives a moderately garbled interface definition in order to pose the questions in the next challenge This may not be the best way to emphasize the points they want to bring out, but the answers to the challenge do include some new information Consider the interface definition on the following overhead:

package com.oozinoz.simulation; public interface RocketSim { abstract double getMass(); public double getThrust(); void setSimTime(double t); }

Challenge 2.2 Which of the following statements are true? [Rather than putting all of the answers at the end, the challenge is presented in the form question/answer.]

A. All three methods of the RocketSim interface are abstract, although only getMass() declares this explicitly. True. Interface methods are always abstract, whether or not they declare it.

B. All three methods of the interface are public, although only getThrust() declares this explicitly. True. Interface methods are public, whether or not they declare it.

C. The interface is declared “public interface”, but it would be public even if the public keyword were omitted. False! An interface’s visibility may be limited to the package in which it resides. In this case, it is marked public, so classes outside com.oozinoz.simulation can access it.

D. It is possible to create another interface, say, RocketSimSolid, that extends RocketSim. True. For example, the List and Set interfaces both extend the Collection interface in java.util.

E. Every interface must have at least one method. False. An interface with no methods is known as a marker interface. Sometimes, a method high in a class hierarchy, such as Object.clone(), is not appropriate for every subclass.

You can create a marker interface that requires subclasses to opt in or opt out of participation in such a scheme. The clone() method on Object requires subclasses to opt in, by declaring that they implement the Cloneable marker interface.

F. An interface can declare instance fields that an implementing class must also declare. False. An interface cannot declare instance fields, although it can create constants by declaring fields that are static and final.

G. Although you can’t instantiate an interface, an interface definition can declare constructor methods that require an implementing class to provide constructors with given signatures. False. It might be a good idea, but there is no way for a Java interface to require that implementing classes provide a particular constructor.

Interfaces and Obligations The utility of interfaces, both generic public interfaces, and interfaces separately defined, comes from the idea of encapsulation On the one hand, code that uses a class cannot mess with the contents of the class On the other hand, code that uses a class doesn’t care how methods are implemented

These are constraints that limit the interaction between classes But the limitation is very helpful One class only needs to know the following: What is the interface for the other class What does the interface support (hopefully the method names are descriptive) How is the interface used (accessibility, parameters, return types, etc.)

In general, say with RocketSim, the developer is obligated to implement methods that fulfill the “contract” implied by the interface In other words, getMass() and getThrust() really ought to return correct values for these quantities for a given object of a class that implements the simulation interface

There is another, special case, where the implementer of an interface is not providing a service to the caller It turns out that implementing the interface makes it possible, in effect, for the caller to provide a service to the code that’s called

You will discover that you are already familiar with this situation The book introduces it as a challenge Because you’ve probably never thought about it in this way, as usual, you can’t predict what the answer to the challenge will be

Challenge 2.3 Give an example of an interface with methods that do not imply responsibility on the part of the implementing class to return a value or even to take any action on behalf of the caller at all.

Solution 2.3 One example occurs when classes may be registered as listeners for events; the classes receive notification for their own benefit, not the caller’s. For example, we may want to take action on MouseListener.mouseDragged() but have an empty body for MouseListener.mouseMoved() for the same listener.

You are familiar with the Java API approach to making this simpler In addition to a MouseListener interface, there is a MouseAdapter class Instead of implementing the interface and providing bogus method implementations, you can extend the class, inherit bogus implementations, and override only those of interest

The book returns to the idea of constants in interfaces, giving a concrete example: public interface ClassificationConstants { static final int CONSUMER = 1; static final int DISPLAY = 2; }

Summary [Direct quote from book.] The power of interfaces is that they delineate what is and isn’t expected in how classes collaborate. Interfaces are similar to purely abstract classes, defining expectations but not implementing them.

Mastering both the concepts and details of applying Java interfaces is well worth the investment of your time. This powerful construct is at the heart of many strong designs and several design patterns.

The End