On Oct 6, 2008, at 7:06 PM, Ryan McKinley wrote:
I like this one. Of course, my Lucene experience would argue that
interfaces are a royal pain when it comes to back-compatibility in
public, open source projects for all but single method interfaces,
where you never know where the next great idea is coming from... ;-)
It took me a while to understand the fear of interfaces -- you have
to replace the things you learn about OO programming with a concern
for back-compatibility. I get it now, but it seems a shame...
I wouldn't call it fear, so much as pragmatism. Interfaces make a ton
of sense in a lot of situations, and I'm very pro Interfaces, but...
The thing that happens is that interfaces are great when all the ideas
about modifying them is self-contained, but in O/S, you just never
know who's going to have a great idea that might need to change an
interface, and then it can break others. Like I said, though, not a
concern anytime soon for Droids...
I don't think early stage projects should worry too much about back-
compat. At least not until 1.0.
How do other projects deal with back-compatibility with interfaces?
Since this is a new project, we are in a position to define the
contract for major/minor release compatibility. Perhaps every
interface has a concrete/abstract implementation and we say
something like "interfaces *may* add new functions between minor
releases (they will not be removed) -- to protect your code for back-
compatibility be sure to extend an concrete class rather then
directly implement the interface. If you implement the interface
directly, you may need to add functions in order to link to a new
version."
Interfaces make good sense in OO programming (and testing) - it
seems a shame to lock things to an abstract super class.
Perhaps my vision is blurred a bit by my use of Wicket and the
automagic bean binding (via spring or whatever) -- using interfaces
is nice because you know everything can be wrapped as a proxy --
with classes, you can run into funny proxy problems.
I agree.
ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
