What is an interface?

[Tor Iver Wilhelmsen]

An interface in Java is a contract to implement a set of method signatures,
nothing more and nothing less.

Yes it is: It is also a part of the type system. Otherwise, having
"empty" interfaces like Cloneable or Serializable would be pointless
with your definition.

 

[Mike Schilling]

Yes it is: It is also a part of the type system. Otherwise, having
"empty" interfaces like Cloneable or Serializable would be pointless
with your definition.

True, it's something you can reflect on as well; that is the only use of
empty methods, to be able to say

if (o is Cloneable)

That's kind of a bastard use of interfaces; it would have been better to use
attributes, if they'd been around at the time.

But an interface isn't the same as a C++ abstract base class; the methods
that implement the interface are not marked as inherited from the interface
in any way. Thus the problem that if you want to implement two interfaces
that declare a method with a common signature but different semantics,
you're screwed: there is no way to implement the two foo() methods
differently. In C++, there is a solution to this problem, because
base1::foo() and base2::foo() are different things with different identities
(different offsets in the virtual table, if you want to talk
implementation.)

 

[Mike Schilling]

I think you are taking a simplistic meaning from what is a woolly training
wording of 'interfaces as contracts to implement' .

Yes, a class implementing an Interface is bound to either implement or
mark as abstract the method signatures defined within the interface.
However they are first and foremost a typing mechanism.

If it wasn't a type specification, how could we pass objects around as
either their direct class type OR the interface they implement?

Of course they're types; I didn't think that was in dispute.

But they're quite different from base classes. See my response to Tor for
further explanation.

 

[Dale King]

Interfaces are nothing like a function pointer.

They are a Type-ing mechanism, much like a C++ pure abstract class, only
with greater restrictions with which they can contain.

They are something like the way you use function pointers in C. That is
why I said "somewhat". Of course they aren't the same thing and I didn't
say they were.

An interface gives you a way to point to an object that provides a set
methods or functions (let's not get hung up on the terminology here)
that you can call. A function pointer gives you a way to point to a
single function that you can call. In that way they are "somewhat" like
each other.

In most C threading API's you give it a function pointer to the code you
want to run (and usually a parameter that is passed to point to some
state information). With Java you give it a pointer to an instance of
Runnable which has the pointer to the "function" and the state is
contained in the instance.

From their use in this respect for specifying the code to run for a
thread they are very similar.

 

[Will]

Yes Dale, thats interesting. The thread class behaves
in this way. Once it gets a Runnable object then it
calls the run() method (after start(). - Mimicking a
delegate sort of thing. (excuse my loose wording).

I was thinking of Action Listener interfaces in
which callbacks and events are actually used
(I assume) to run the methods in our applet
classes etc when a button is clicked.
But its similar in effect to Thread calling
run(). (or have I sinned here?)

 

[blmblm]

Yes Dale, thats interesting. The thread class behaves
in this way. Once it gets a Runnable object then it
calls the run() method (after start(). - Mimicking a
delegate sort of thing. (excuse my loose wording).

I was thinking of Action Listener interfaces in
which callbacks and events are actually used
(I assume) to run the methods in our applet
classes etc when a button is clicked.
But its similar in effect to Thread calling
run(). (or have I sinned here?)

Well, I'm not Dale, but it sounds to me like you're
starting to get the hang of interfaces -- the
ActionListener interface, like the Runnable interface,
allows code in some other class (something in Swing for
ActionListener, Thread for Runnable) to make a callback
to code in your class (actionPerformed() or run()
respectively). Do you also feel like it's starting to
make sense to you?

(I'm wondering in writing this reply what you mean by
"thats interesting" in your first paragraph. It's
obviously a reply to something someone else wrote, but
I can't easily find that previous post, and since you
didn't quote .... Well, maybe it's just the antique
newsreader I use, but I think there's a case to be made
for quoting a bit of what you're replying to.)

 

[Will]

Well, I'm not Dale, but it sounds to me like you're
starting to get the hang of interfaces -- the
ActionListener interface, like the Runnable interface,
allows code in some other class (something in Swing for
ActionListener, Thread for Runnable) to make a callback
to code in your class (actionPerformed() or run()
respectively). Do you also feel like it's starting to
make sense to you?

(I'm wondering in writing this reply what you mean by
"thats interesting" in your first paragraph. It's
obviously a reply to something someone else wrote, but
I can't easily find that previous post, and since you
didn't quote .... Well, maybe it's just the antique
newsreader I use, but I think there's a case to be made
for quoting a bit of what you're replying to.)

I agree about quoting what your replying to. So many
programmers use of language is terrible. They know exactly
the flow of their meaning but do their readers? Not often I
suggest (or is it just me?)
As for Interfaces, all the text books seem to say is 'contracts'
and empty methods stubs, but the practical use of
Intefaces is usually the fact that the method that is
called in our own classes are in fact called from,
a helpful class, like Thread or ActionListener where
all the hard work is done for us. This is the Multiple
Inheritance-like behavior that I was looking for and
was never explained in books (or anywhere). Explanations
like 'a cat is a mammal that cannot fly and eats fish
pizzas but not worms on Sundays' leaves my head reeling.
But the looking in the class Thread and actually seeing
it call run() after doing a bit of magic is an
understandable use of Interfaces IMHO.
I think I get them now. THANKS TO ALL (shouting).

or ActionListener