On 1 April 2014 21:19, Hardy Ferentschik <ha...@hibernate.org> wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emman...@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?
Lol, I'm imagining you politely asking your dog to see if he has time
to fetch your tablet :)
>
> 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.
What I meant is that in certain situations the state of the
underlaying service might change between invocations. Let's say your
bridge implementor is configured via an external resource, containing
like a list of things it's supposed to handle. Now let's assume that
this can be reconfigured at runtime (crazy stuff which seems common in
OSGi world, but also not too unusual via JMX): at one moment of time,
your implementation could say "yes I can", and right after be forced
to return null or throw an exception.
True, you could classify this as an "implementation error" .. but if I
where that developer I wouldn't be sure how to fix it, while a single
method API would have been straight forward.
We might not expect these things to be configured at runtime, but we
had several examples in which things which where expected to be quite
"static" have later needed to be refactored in mutable things. If you
take the MutableSearchFactory and our complex boot, I guess you
immediatly see what kind of pain I'm referring to when we need to fix
such an assumption in a second phase.
-- Sanne
>
> —Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
