On Java's Interface
Xah Lee, 20050223
In Java the language, there's this a keyword “interface”.
In a functional language, a function can be specified by its name and
parameter specs. For example:
f(3)
f(3, [9,2])
f("some string")
are usage examples of 3 functions all having the same name, but having
different number and type of arguments. In this way, a function is
essentially known to outsiders by its name and parameter specs. The
gist in this concept is that the user don't need to know the
implementation details of the function. All she needs to know is the
function's name, and parameter specs and return value spec. (and of
course what the function is supposed to do.) In this way, interface
and implementation are separated. The implementation can change or
improve anytime, and users don't need to know.
In Java, the above concept of function name and parameter spec is
called a method's signature.
For another example, usually a program needs to talk to another
software such as a database software. The database software may have a
set of functions for the purpose of communicating to other software.
In essence, making the database useful to other software. Such a list
of function spec is often called API, which stands for Application
Programing Interface.
The API terminology is abused by the marketing-loving Sun Microsystems
by calling the Java language's documentation as “The Java API”, even
though Java the language and its paraphernalia of libraries and
hardware-emulation system (all together jargonized as “the Java
Platform”) isn't a Application nor Interface. (a API implies that
there are two disparate entities involved, which are allowed to
communicate thru it. In the case of “The Java API”, it's one entity
talking to itself.).
In general, the interface concept in programing is a sort of
specification that allows different entities to call and make use of
the other, with the implication that the caller need not know what's
behind the facade.
In the Object Oriented Programing Paradigm, a new concept arose, that
is the “interface” aspect of a class.
As we've seen, a function has parameter spec that is all there it is a
user needs to know for using it. In Java, this is the method's
“signature”. Now, as the methodology of the OOP experience multiplies,
it became apparent that the interface concept can be applied to
Classes as well. Specifically: the interface of a class is the class's
methods.
This concept is then turned into a OOP machinery, in hope of
extracting usefulness in software engineering. That is to say, now in
the Java language, a programer can actually write a piece of code,
whose sole purpose is to define what methods and variables a class
contains. This, is done with the keyword “interface”. Once a interface
is defined, other classes can say which interfaces they implement, so
that if class C implement interface I, then programers don't need to
know the details about C. All they need to know is the interface I.
(which specifies all the methods, constructors, variables, a class
must have.)
(the Java's interface, is essentially the “signature” of a class, in
Java's own jargon.)
A programer may ask, what's the big deal anyway? Since in Java,
classes are well documented anyway. What difference does it make to
know the documentation of C versus the documentation of interface for
C?
The thing about interface in Java is that the complexity grows. A Java
interface, can be inherited, just as classes. The idea is that
interfaces can also form a hierarchy just like classes.
In pure OOP such as Java, the object entities used to solve computing
problems are thought to form a relation as of a tree, thus we have the
class hierarchy. In a similar way, it is thought that interface, can
also form a hierarchy fruitfully. A good example is the list data
type. The explanation follows.
In computing languages, often there's a data concept variously known
as lists, aggregate, sequences, array, vector, tuple, set, matrix,
trees... The basic idea is that it is just a list of things. This list
may not allow repetitions, elements may be lists themselves, may have
certain dimension stipulations (e.g. matrix), may have certain
computational properties such as speed of retrieving a element or
adding a element or memory footprint... etc and so on. Different
requirement and different computational properties have given them
various names to go by. One can however organize them by the interface
perspective. In Java, they are known as Collection, and all have the
interface of Collection. (See http://java.sun.com/j2se/1.5.0/docs/...ollection.html
http://java.sun.com/docs/books/tutor...ces/index.html
)
Consider a Set and List. One does not allow repetitions, while the
other allows. Other than that, both concepts are the same. They both
need methods like adding elements, deleting, inserting, sorting etc.
Therefore, from interface point of view, they share a parent. In Java,
both Set and List are interfaces, inherited from the parent interface
Collection.
So now, in Java, we have two hierarchies of separate category: Classes
and Interfaces. The Classes hierarchy is one single giant tree.
However, the interfaces are not all together as one tree. They are
more like forests, of many trees. It is important to remember that
interfaces and classes are separate entities. A class can implement a
interface. A interface can never inherit from a class.
In Java, it so happens that a class can implement more than one
interfaces. When a class C implements interfaces I1 and I2, C is
guaranteed to have all methods declared by interface I1 and I2. For
example, in Java, class Integer has interfaces Comparable and
Serializable. And the class ArrayList has these interfaces: Cloneable,
Collection, List, RandomAccess, Serializable.
The interface in Java, from a simple useful idea, has mutated into a
incomprehensible complexity.
In Java, Interface is no longer the sole thing a programer needs to
know about a class or function. It is no longer a concept that
separates a function's user spec from implementation detail.
For example, the ArrayList class has these interfaces: Cloneable,
Collection:List, RandomAccess, Serializable. As one can infer from the
names, they are more about what properties ArrayList has, than a
syntax facade that hides implementation irrelevances.
For example, see the Java documentation on these interfaces: •
interface RandomAccess http://java.sun.com/j2se/1.5.0/docs/...domAccess.html
• interface Serializable http://java.sun.com/j2se/1.5.0/docs/...ializable.html
• interface Comparable http://java.sun.com/j2se/1.5.0/docs/...omparable.html
One can see that these “interfaces” are really not interface in
nature, but properties. One might ask, in “interfaces” suchas
RandomAccess that doesn't have a single variable or method, in what
technical definition that a class is said to satisfy such interfaces?
And, given the existence of these property-like interfaces, can a
programer define their own arbitrary computational property contract?
For example, suppose i want a property ConstantTime for the classes in
game i'm developing. Once i declared a class to have “interface”
ConstantTime, apparently my class is not going to magically become
constant time. How do i define arbitrary properties to the compiler,
and how's the compiler going to check? The following are the answers.
20050224
Java's Interface has mutated so much from the interface concept that
it also functions as a pure label. If a interface does not have any
variables or methods, any class can declare it as a interface. There
is no restraint whatsoever. For example, the RandomAccess interface in
Java does not have any variables or methods. Any class can declare it
as a interface, randomly accessible or not. When interface is used as
a label, it is called a “marker interface” by the Java documentation.
For example, see http://java.sun.com/j2se/1.5.0/docs/...domAccess.html
Because the multi-inheritance nature of Java interface, and its double
role as a label, it no longer function as a communication facade that
is the meaning of interface. If a Java class have interfaces A, B, C,
D, E, one cannot be sure just exactly what methods or variables the
class have. (it will be a union of them, and some of them do not serve
any function with respect to the language.) Further, using interface
as a inert label to indicate computational properties (e.g.
RandomAccess) is a egregious incompetence in the design of a language
for computation. The gist of the problem is that it is a piece of
mathematical irrelevance in the language. As a labeling mechanism in a
language, for the possible benefit from the software engineering
perspective, then it should not be designed as part of the Class
Interface, since labeling and programing interfaces are semantically
disparate.
On the Inanity of Standard Java Tutorials
The standard Java tutorials out there are often inane, in that none of
them actually tried to teach what the language actually manifestly do,
but instead, often talk in some purportedly good engineering
perspective.
For a incomprehensible metaphysical intro to interface using bicycle,
see this page of the Official Java Tutorial:
http://java.sun.com/docs/books/tutor...interface.html.
For a more detailed account of Interface using baffling financial
stocks, see this page of the Official Java Tutorial:
http://java.sun.com/docs/books/tutor...interface.html.
(the official Java Tutorial has went into major changes in 2006. For
the version of the above two pages, see local copy as of 2005
PS the official Java tutorial thru its update history has changed its
stance about what's a interface:
before 2005:
Definition: An interface is a named collection of method definitions
(without implementations). An interface can also declare constants.
sometimes after 200501:
Definition: An interface is a device that unrelated objects -- objects
that are not related by class hierarchy -- can use to interact with
each other. An object can implement multiple interfaces.
Complexer and complexer. Note its use of the word “device”.
In its current incarnation (as of 2006-08-14) of the tutorial
http://java.sun.com/docs/books/tutor...ndI/index.html,
interface is not particularly given a definition.
References:
Java lang spec, 2nd ed, 8.4.2 on Method Signature,
http://java.sun.com/docs/books/jls/s...doc.html#38649
Official Java documentation page for 1.5.0, where it calls itself API.
http://java.sun.com/j2se/1.5.0/docs/...w-summary.html
------------
This post is archived at:
http://xahlee.org/java-a-day/interface.html
Xah
xa*@xahlee.org
∑ http://xahlee.org/
