2.8 Java1616: polymorphism and interfaces, part 1  (Page 6/7)

Receiving parameters as interface types

Methods can receive parameters that are references of interface types. In this case, the author of the code that calls interface methods on the incoming reference doesn't need to know, and often doesn't care, about the name of the class from which the object was instantiated. (For a discussion of this capability, see my tutorials on the Java Collections Framework, which you can read about here .)

A common example

A very common example is to store references to objects instantiated from different classes, (which implement the same interface) in some sort of data structure ( such as list or a set) and then to call the same methods on each of the references in the collection.

Heart of the Delegation Event Model

For example, this methodology is at the heart of the Delegation Event Model , which forms the basis of Graphical User Interfaces and event-driven programming in Java.

This often entails defining classes that implement standard interfaces such as MouseListener , WindowListener , TextListener , etc. In this case, the programmer defines the interface methods to be appropriate for a listener object instantiated from a specific class. Then a reference to the listener object is registered on an event source as the interface type .

Later when an event of that type occurs, the source object calls one or more interface methods on the listener object using the reference of the interface type. The event source object doesn't know or care about the class from which the object was instantiated. In fact, it doesn't even care how the interface method behaves when it is called. The responsibility of the source object ends when it calls the appropriate interface method on the listener object.

Model View Control

This same methodology is also critical to the use of the Model View Control paradigm in Java using the Observer interface and the Observable class. In this case, view objects instantiated from different classes that implement the Observer interface can register themselves on a model object that extends the Observable class. Then each time the data being maintained in the model changes, each of the views will be notified so that they can update themselves.

JavaBeans Components

This concept is also critical to the use of bound and constrained properties in JavaBeans Components. One bean can register itself on other beans to be notified each time the value of a bound or constrained property changes. In the case of constrained properties, the bean that is notified has the option of vetoing the change.

Java Collections Framework

The Java Collections Framework is also totally dependent on the use of interfaces. As I mentioned earlier, you can read all about this in my tutorialson the Java Collections Framework, which you can read about here .

Iterators and Enumerators

If you appreciate data structures, you will also appreciate iterators. In Java, Iterator is an interface, and an object that knows how to iterate across a data structure is an object of a class that implements the Iterator interface.