Several times, I've encountered the following view:
Interfaces in Java don't have any semantics attached. Only a concrete class can define the semantics of a method.
I've always thought that this was a very strange thing to believe. The /semantics/ of an object or operation are whatever a human user understands the object or operation to represent. The /implementation/ of an operation is primarily a set of instructions to the machine - and of course the machine has no use for semantics.
So if the semantics of an object or operation do not reside in the implementation of the object or method, exactly where are the semantics defined?
Well, I would argue that the semantics are declared in two places:
- The names of things
- The JavaDoc
These are the places where we find /English/ words in our code; therefore, they are meant for /human/ consumption, not machine consumption. The machine is every bit as confortable with a method called A$_128__() of a class named a$aaBxw as it is with the submit() method of Order. Only semantics need to be expressed in English.
And when we look at a Java interface, we see that it contains
very little extra information beyond a list of names and
JavaDoc. So, in fact, an interface is as close to a pure
declaration of semantics as you're ever going to find in Java
source code! If interfaces don't have semantics:
- How would we know what to call them?
- What would we write in the JavaDoc?
Of course, an implementation of an interface can add additional semantics - indeed, any subtype of an abstract type /must/, by definition, add additional semantics. But that doesn't mean that the most abstract type in a type heirarchy has /no/ semantics.
Well, except, perhaps, for Object. Does Object have semantics? It's operations certainly do, but what about the class itself? Let's pretend for a second that Java's type system is not completely broken: there are no primitive types, so all types extend Object. Then does it /mean/ anything to know that something is an Object? I'm not sure. Let's leave that as an exercise for the comment thread ;-)
But one thing I /am/ certain about: when we declare that our object implements an interface, we're definitely saying something /meaningful/ about what kind of thing it is.
To make a semantic distinction, interfaces have semantics, but they do not have enforcible semantics.
If someone is going to take such a strict definition of semantics, they'd have to admit that even concrete Java classes only have enforcible semantics if they declare final behaviour. Otherwise their semantics can be subverted by subclassing. The Object class defines very particular semantics for the equals and hashcode methods, but from the evidence of more developer interviews than I care to admit to, there are a lot of objects out there that don't follow them.
I was going to comment here, but I realised it was just a bit long. So I put it on my blog and did this manual trackback :-) : http://batmat.net/blog/post/2007/12/16/Do-Interfaces-have-semantics To sum up, I agree with Gavin.
Well, the comment area doesn't seem to like URLs... I put the link to the entry in the area instead.
Interfaces do have semantics(Business semantics in this case). As they are abstractions of what the object implementations will finally do. Without semantics in the interfaces, it be pointless to code the implementations...
If u find yoself in a position u have an interface without semantics, abandon it en do a redesign...:-)
Yes, it does. You quite often have done it - you have used introspectors to find out: - about its type or kind - about the methods - maybe even about fields containing state - (I drop annotations here as they just add another dimension) - about the name (some pointer thing) - you aggregate your knowledge about such an object and search for to do something with them later
So the semantics you have just knowing it is a java Óbject in all its beauty is: It has a name or address and when you move it around and it has the same name you know it is the same thing (with entities or pooled objects this might be very inaccurate or with less abstraction even wrong), it has a kind or type, it has state and it has behaviour. But you don't know what the semantics of the state are and what exactly the behaviour is, not even which and how to trigger it. Again I'm saying that annotation at this point add complexity.
Imagine you have your eyes closed and just touch something. First, it is just a thing currently your scope. You might immediately forget about it if you don't find any contract how to identify it. You know it has some properties - maybe you immediately find out it has edges, but you never get to know its color. And you imagine it might have a behaviour you just don't know how to trigger ... at least yet.
This is like an Object :-)
Kind regards, Stefan
Baptiste, the way to write URLs is [points to my URL => http://myurl.com/relative]
I'd like to add to this list. The difference between methods and properties is semantic: methods retrieve dynamic information or results, whereas properties retrieve relatively static information.
Also the difference between typing something as an interface and typing it as a class is semantic: I want exactly one of these and I am very particular about it, versus anything that does this is fine I don't care.
Do you think I have something? Or am I understanding wrong?
Thanks Emmanuel. And now I notice the beautiful question mark on the left :-/. At work, having to support people doing this kind of things makes me crazy... Shame, shame, shame... :-)
So, OK, so that's where I put my opinion about the subject .
Errr, John, what do you call properties ? Class attributes ? Parameters ?
And I don't get your second sentence (I'm no native english speaker) :
Could you develop ?
Have to agree with Gavin in general. One of the most fundamental OO Idioms, that is, program-to-interface, is consistent with the idea of introducing as much of the semantics of an operation before any of the details of the implementation. Be it an abstract or concrete implementation behind a reference, it's the which defines that ref's type.
In fact, this is how Java tried to distinguish itself from it's predecessors. A class can implement as many interfaces as it needs to. This is how Java wants you to introduce semantics in your code. There's NO need to extend concrete implementations in order to do so - ergo single inheritance.
So, to conclude, there exists semantics in every class, from the most abstract - interface - to the fully implemented. BUT, a design reveals as much of semantics sooner (in interfaces) than later (in concrete implementations).
Nice post. At first I was amazed that people could claim such a thing, but now I'm guessing at least part of it is simply failing to be clear about the difference between what a method or class should do (hopefully described in javadoc and name) versus what the method or class actually does (perfectly described in the implementation code).
We call the first of these , but if you're used to crappy javadoc and naming, you'll tend to look at the the second as your way of finding out what the method is supposed to do, and not even bother with the interface (this is obviously very bad, and almost certainly the usual practice). Also, in normal life (
Hmm. What happened to the rest of my post? Oh, it didn't like that character.
Anyway ...
Also, in normal life (non-IT :-) we always reverse-engineer semantics from implementations (the only way to get semantics, since the world only contains implementations - Dennet likes to write about this kind of thing).
I believe the first post is confused about this too. We don't have to enforce a semantics; it just is. If the implementation doesn't conform, it's not changing the semantics - it's a bug
We don't have to enforce a semantics; it just is. If the implementation doesn't conform, it's not changing the semantics - it's a bug