So we would have:
IDroid
IHandler
IOutlink
ITask
ILink
ITaskmaster
...
thoughts? I figure I should throw it out there while the API is in
flux ;)
I personally do not really like that too much. I am more the option b
type from
http://discuss.joelonsoftware.com/default.asp?design.4.331276.11
Droid droid = new DefaultDroid();
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...
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.
ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
