Style Question
I have the following class:
publicabstractclass FrameListener{
publicvoid frameClosed(){}
publicvoid destinationReached(){}
}
The reason I did this instead of an interface is so that I can do:
frame.addFrameListener(new FrameListener(){
publicvoid destinationReached(){
//do something
}
});
and not have to worry about putting in empty methods into the anonymous inner class. Is this ok because of its convenience, or should I do what Sun does and have a framelistener interface and have an abstract frameadapter class.
[1220 byte] By [
Nethera] at [2007-11-26 17:02:11]
Personally, I prefer the idiom where you provide an interface and an abstract implementation of the interface.
Doing it the Sun way (interface + adapter) doesn't hurt, and only takes a second, but does it buy you anything *useful*? Well, you can then do this:
class MyPanel extends JPanel implements FrameListener {
...
}
But how useful is that? I don't think it is particularily useful, because you could always do the following, if all you defined was FrameAdapter:
class MyPanel extends JPanel {
private FrameAdapter fa = ...;
...
}
1. In this case you have the option of instantiating fa with either an anonymous subclass or a previously defined top-level class.
2. fa is hidden, which is usually a good thing, because typically it is merely an implementation detail, but you could expose it with a getFrameAdapter method.
In conclusion, I wouldn't miss the interface in this particular case.
I think it comes down to how much you want to establish FrameListener as an important type. How big a role it plays in the larger design. The more prominent it is the more you want to make it an interface.
Hmm, that is interesting. I think for now I'll skip the interface just because this class does not play a huge role. But I now understand how having the interface and adapter can be useful.Thanks
> I think it comes down to how much you want to
> establish FrameListener as an important type. How
> big a role it plays in the larger design. The more
> prominent it is the more you want to make it an
> interface.
What's the reasoning behind that, beyond a design style that likes to make prominent type interfaces? Especially in this case, where having a default implementation with empty bodies isn't violating any method specs. (Yes, you can appeal to the usefulness of java.lang.reflect.Proxy... but apart from that!)
I'm saying this because one nice thing about starting with the class is that latter, if you add another method, you can provide a stub for it and all the old code compiles. With an interface, you would have compiler errors whereever the interface had been directly implemented.
> What's the reasoning behind that, beyond a design
> style that likes to make prominent type interfaces?
Well, that's a large part of it. In my experience code is less error prone when important parts are expressed in interfaces. It also makes it easier to grok an existing codebase, if you can look at the interfaces and the relationships between them and one or two major classes and get a sense of how the whole thing works. This is a purely subjective thing of course...
> I'm saying this because one nice thing about starting
> with the class is that latter, if you add another
> method, you can provide a stub for it and all the old
> code compiles.
That's nice but IMHO not super important. If this were really important, Java should just get rid of interfaces and implement multiple inheritence.
> With an interface, you would have
> compiler errors whereever the interface had been
> directly implemented.
Yeah, but that might be a good thing. If this type is really important, then simply inheriting a no-op implementation may be a trivial but incorrect way of solving whatever problem prompted adding the new method to begin with. And the fact that the classes in question didn't implement the abstract implementation (with no-op implementations of methods) suggests that those classes shouldn't be inheriting no-op implementations anyway. By separating the type and the implementation, you'd be forcing the programmer to make a conscious decision about the best way to implement those methods.
