At the beginning of the year, I posted this in JavaRanch's "OO, Patterns, UML and Refactoring" forum:
Java without interfaces. I had just read Dr. Dichotomy's (Eamonn McManus) Development Diary:
Java API Design Guidelines, and
had heartily agreed with all his major points until I came to
Interfaces are overvalued:
A type should only be an interface if you have a good reason for it to be [one]. Like some Java-based Martha Stewart, I had always thought that
Interfaces are a good thing, but then I tried a thought experiment: what Java still be "Java" to me without interfaces? Or would the way I code have to dramatically change? Don't get me wrong. I'm not proposing that Java drop interfaces or that Java must prove it is consistent as code is accelerated to near the speed of light
I just wondering if it would be life, Jim, but not as we know it.
In that
thread, two things were mentioned that required interfaces and/or the ability to implement multiple interfaces:
1. Dynamic proxies require interfaces. I'm still not convinced that there isn't some way to get dynamic proxies into a interface-less Java, by hook or by crook...
2. Ilja Preuss mentioned the "Interface Segregation Principle", and that requires, or works most naturally with multiple inheritance of interfaces. I'm embarassed to say I've never designed an interface around that principle, although I found the article interesting and I'm still digesting it into the code I'm currently working with.
I still feel that one can go far (except for dynamic proxies) in Java by using abstract classes with all abstract methods in place of interfaces, and never missing mutiple inheritance of interfaces.
But getting back to the original "pattern" (I too wish it had a name): I think that it is still useful (with the interface at the top, or a heretical pure abstract class). Consider TableModel and AbstractTableModel (or most any of the Swing model examples). AbstractTableModel provides some boilerplate code for listener management by having a protected javax.swing.event.EventListenerList member. Now suppose you want to define a class that either implements more than one listener interfaces (or has an inner object for each listener interface in question) and you want to code this with a single shared EventListenerList for the object. (Recall that by design, you can store different types of listeners in the same EventListenerList.) If you use the abstract classes with their boilerplate code you will have mutiple EventListenerLists, unless you do this, which makes me queasy in the same way as those films where they change a monkey's brain with that of a man
Maybe I wouldn't feel so sheepish if those abstract classes had a constructor that let you pass in a EventListenerList. That would make this trick kosher.