On 2 April 2012 10:44, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Apr 2, 2012, at 11:16 AM, Emmanuel Bernard wrote:
> What's your definition of an SPI, in the team we have slightly different ones.
>
> In Hibernate search an SPI is targeted at frameworks or hyper advanced user who are
willing to integrate or enhance Hibernate Search. Otherwise, they are considered APIs -
which includes interfaces you might need to implement like FieldBridge. Hibernate ORM has
a different semantic where an API is what the application directly code on.
The HV interpretation of SPI is the same view as in ORM. Imo It makes for a simpler,
easier to understand cut between API and SPI.
> For your second question, I have used the idea of an interface combined with an
abstract class with success. The interface used by the consumers and the abstract class
extended by implementors.
I also think that an abstract class can be beneficial. However, I would not generalize
this approach. In the case of the HV interfaces in question we have very simple
interfaces
(single method ones) with a very low likelihood that they will change. I don't think
that the abstract base class is needed in this case, especially since it forces you to use
inheritance.
I agree as I don't think we have ever set a rule in stone, but it
doesn't force to use inheritance. It's a suggested base class, the
hard contract is still the interface only.
So the implementor can decide to stop inheriting at any time if it
suites best: a base class is indeed not guaranteed to be useful, but
when it's not it doesn't make things harder.
Cheers,
Sanne