R
Roedy Green
Of course, and how many, many, dozens (hundreds?) of times has this happened
in the core library?
could you give an example of the problem?
Of course, and how many, many, dozens (hundreds?) of times has this happened
in the core library?
Not at all. It just means your end object has the behaviours
described by the interface. How it got them is immaterial.
However, IMHO, this is almost (note I don't say always) an anti-pattern.
If we used the Interface Segregation Principle, then we would not need
to have so many interfaceAdaptors.
HTH
Andrew
I fail to see your point.So all in all, unless my prediction of trouble ahead is flawed, I think you
need to go back to the drawing board on this one.,..
Roedy Green said:the notion of which interface does a method belong to just does not
come up in Java. A method conforming to two different interfaces
belongs to both interfaces.
You can access the method via a class reference or either interface
reference.
Chris said:I hardly ever use Adapters. They are mainly there to support anonymous
inner classes, which is a quick (and dirty?) way of creating a
Listener on-the-fly. In my opinion, it sort of takes event handling
back to look somewhat like the java1.0 event model. But of course, it
all boils down to a matter of taste.
Oliver said:The issue I'm trying to raise here is what if there are three
programmers involves: Author A, Author B and myself. Author A writes an
interface "InterfaceA" which defines one method "foo()" which does one
particular thing. Author B writes an itnerface "InterfaceB" which defines
another method "foo()" which does something different.
I want to write a class that implements both these interfaces. I'd like
to write two different method bodies because the two "foo()" actions
semantically do different things, but I can't in Java, whereas I could in
C#.
Andrew McDonagh said:But... interfaces do not specify WHAT the method does, just that there is
a public method with that signature on that TYPE of object.
This problem is not just limited to Java, any language that supports
Polymorphism has this issue. Some languages go to various lengths to
'help' get around it (like C#).
Its not just a problem of Interfaces either.
Though what you describe as wanting, is Multiple Implementation
Inheritance , not Multiple Interface Inheritance .
java.awt.Component,I fail to see your point.
If Sun suddently changed the signature or function of, say,
So i am resting quite assured that it won't happen.
jan V said:Who's talking about changing any method signatures? That's not what I
said,
I wrote "reimplementing [methods], possibly with their functionality
subtly
changed".. in other words I'm talking about the precise semantics of a
method being subtly changed. The method signature isn't touched at all.
The problem with your scheme is that
a) you pick arbitrary methods from abstract/concrete classes which are not
the subject of any interface contracts written by the same authors of the
classes
b) you define an interface which contains those same methods (as
signatures
only, obviously), and by doing so you "freeze" a particular *semantic
contract* for these methods
c) you now subclass a third-party class (Sun's), and impose on this class
your interface's contract.
From now on, any future changes to the *precise semantics* of the methods
you picked, as altered or enhanced or rewritten by Sun, may very likely
break your scheme.
Why? Because Sun don't know or care about your interface's rigid semantic
contract, but you do... and suddenly the methods you tagged as "belonging"
to your interface don't match the semantics you imposed on them. The Sun
changes lead to a branching in semantics for these methods: one branch for
Sun's semantics, and one branch for your interface's semantics. Now guess
who's going to loose the battle of this splitting evolution? You, not Sun,
since Sun aren't even aware some clever guy decided to try to impose a
semantic straightjacket on a subset of Component methods....
So i am resting quite assured that it won't happen.
Do you understand the scenario now?
problem as opposed to a "depending on undocumented behaviour" problem. I
think you'd have the exact same problem if you used one of Sun's classes in
composition and depended on a particular behaviour; if Sun changed the
behaviour, your code wouldn't work anymore.
I'd imagine typically that if one were to create an interface for a
particular set of methods from one of Sun's classes, the documentation
explaining the semantics of those methods would pretty much be taken
straight from Sun's javadocs. Then the interface creates no new restrictions
on behaviour that weren't already publicly documented on Sun's site.
Erm... no, they don't have anything to do with anonymous inner classes.
Yes lots of examples use anonymous inner classes derived from Adapters,
but thats completely separate.
Do you use (non static) inner classes?
Chris said:I don't say that adapters are the only use of anonymouse inner
classes,
an anonymous inner-class, I find it difficult to justify sub-classing
an adapter.
Most of the listener interfaces - if not all - have very
few methods, and implementing them explicitly as empty {} is a good
way of 'documenting' that you intentionally left them as such.
Still, that's my opinion, not the definite truth.
Of course, but named inner classes as opposed to 'normal' classes, in
my opinion, have a different use, namely to limit the scope. Or am I
missing something?
Andrew said:Well thats strange, seeing as the entire reason for this idiom is to
provide an Abstract baseclass that fulfills the interface specified by
either the Abstract class the Adapter derives from, or the Interface it
implements.
Lets take the usual example of MouseAdapter...
public abstract class MouseAdapter
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/event/MouseAdapter.html
Its an Abstract class even though it fully satisfies the MouseListener
Interface - purely so that we have to Subclass it to add our own
overridden behavior to 0,1 or * of the methods.
Another reason to subclass Adapter classes is that future versions of
the API might add to the interface. If you have extended the Adapter
class, then you have nothing to change.
Ray
"...An anonymous class is always an inner class (§8.1.2);..."
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#252986
they are purely a mechanism for declaring nested classes which we care
to to name - nothing more.
Daniel Dyer said:I didn't know that C# did things differently in this respect. I'm not
sure I like it, it would appear that you can change the observed behaviour
of the object just by casting. It reminds me of multiple inheritance in
C++.
In the second example, what happens if I do this:
t.MyFunction();
???
Does this result in a compile-time error because it's ambiguous or does it
prefer the I1 version because it is specified first in the extends list?
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.