Re: [hibernate-dev] [HSEARCH] Autodiscoverable field bridges next steps
On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
## Splitting the BridgeProvider in two methods
A way make the inelegant code structure
FieldBridge bridge = provider.provide(…);
if ( bridge != null ) {
return bridge
}
Is to ask of the provider to answer two question:
- boolean canProvideBridgeFor(…)
- FieldBridge createFieldBridge(…)
The code would become
if ( provider.canProvideBridgeFor(…) ) {
return createFieldBridge(…)
}
I prefer the latter. I tried already all sorts of arguments on the pull requests, but it
might be that I stand alone here.
I think it is more intuitive since it avoids the null check and I almost can implement the
provider without looking at the Javadocs
telling my what to do. Also in the real world, you would first ask me whether I can make
you something, before telling me to do so, right?
One of the counter arguments I’ve heard is, that having two methods instead of one creates
some code duplication in the implementation.
I find this a weak argument. If I look at the API I first look at what I want this API to
do and how it should do it. Whether the impl needs to repeat
some piece of code is a different question. And if nothing else, the implementation can
extract the common code into a method.
Another concern is that if the answer to can… and create… are
inconsistent, we are in trouble.
Well, if canProvideBridgeFor returns true it should create the bridge when provide is
called. Unless there is of course an (runtime) error when creating
the bridge. However, this would throw an exception. If the bridge provider does not behave
this way, you have indeed a bug, but I don’t see the big difference
to this type of bug to any other implementation error.
—Hardy