[BBB-DEV] Re: org.jdesktop.beansbinding.Property should be interface

[Fabrizio Giudici <fabrizio.giudici@tidalwave.it>]

Kevin Day wrote:
> First - I want to say that I'm quite impressed with what you've put 
together on the whiteboard.  I
Just to recall (in case the message wasn't delivered ;-) that 
whiteboards are open to everybody, you just need to ask the "Content 
Developer" role in BBB. I think they are important - for explaining a 
structured idea, such as Peter's, the mailing list is not good because 
it jeopardizes the code listings; furthermore, with the whiteboard you 
can edit and refine your things. So, guys, please feel free to use them.

> And now to answer the question:  The primary driver behind using an 
abstract baseclass instead of an interface is that interfaces are 
incredibly difficult to evolve.
>  
> If it became necessary to add a method to Property, it would not be 
possible without breaking every bit of code out there.  With an abstract 
base class, new methods can be added without breaking existing code.  
That's pretty important for an API like BBB, and this sort of thing is 
actually done quite a bit in frameworks to ensure future flexibility.
This is clearly explained in Jarda Tulach's book "Practical API design", 
that contains some examples of this issue (maybe something can be found 
on his wiki too: http://wiki.apidesign.org/wiki/TheAPIBook).

While I agree with most of Jarda's thoughts, this is one that still I 
don't get (perhaps because I'm not comfortable with binary 
compatibility, unless I try a concrete example with a tool such as 
SigTest). I mean, you can always resort to defining an interface an 
abstract class that implements it (partially, of course), and advicing 
people to preferably avoid a direct implementation of the interface, 
rather than subclassing the abstract class. In this way, a new method 
can get a default implementation in the abstract class, still you have 
the interface and the capability of an alternate implementation (note 
that I'm thinking of an alternate implementation *still in the API*, so 
you can make consistent updates; even in case your alternate 
implementation is in another API, it is however possible to say that v2 
of "base API" requires a v2 of "derived API". At this point, one of the 
counter-responses of people preferring an abstract class is that while 
with my described approach consistency relies on the *good will* of 
programmers, with an abstract class the control fully stays with the API 
provider. Of course, if a programmer breaks something with a practice 
that has been discouraged, he can be blamed for that; but in the end, 
this would likely raise a controversy. It's the same reason for which 
people prefer to put "final" everywhere is possible, to prevent people 
from misusing inheritance.

> If Property was an interface, how would that simplify/improve your 
approach?  I'm having a bit of a hard time getting my head into what the 
benefit would be - maybe an example would help to clarify?  I really 
like what you've put together, and I suspect that understanding the 
interface/abstract base class issue you are running into will help me to 
really understand it.


Peter's point in the wb:

"The requirement for Props to be an interface is in supporting the same 
sheme of Property factories to be used on Java Bean style of interfaces 
(interfaces with setter/getter methods). Since we model parallel 
hierarchy of Java Bean types and property factory types we must support 
multiple inheritance."


Actually, if Peter can provide an example (I suggest: directly on the 
whiteboard!) we can understand better.   


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941