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

[Kevin Day <kevin@trumpetinc.com>]

We do create our own Property implementations (code outside the API), but I could live with Interface + Abstract Base Class as a compromise, if there's a solid reason for making that change.

 

My concern, though, is that for the situation that Peter is wanting to use it for (I think - I'm still a little unclear), we would wind up with tons of little implementations of the *interface* in all of our beans, not derived from the base class.  A change to the interface would then have massive impact to existing code (code that really never intended to have anything to do with Property - but was just using it as a convenient way of exposing it's properties).  I'm pretty sure that having an abstract base class that implements the interface would not address the issue (that would just put Peter right back where he is now, I think).

 

I could be wrong on this - maybe he is planning on using dynamic proxies to implement a new type of Property?

 

I'm quite eager to see some examples of how interface would impact his strategy.

 

- K

----------------------- Original Message -----------------------

  

From: Fabrizio Giudici <fabrizio.giudici@tidalwave.it>

To: dev@betterbeansbinding.kenai.com

Cc: 

Date: Wed, 15 Jul 2009 21:19:25 +0200

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

  

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
c an 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.< BR>
> 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
Tid alwave 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