| The building process of bridges is currently as follows:
- a builder is instantiated
- its initialize() method is called, passing the annotation as a parameter
- its build() method is called, returning a bridge
- the bridge's bind() method is called, passing the binding context as a parameter.
It's a bit complex, and more importantly it implies that bridges are mutable until their bind() method is called. We could probably simplify this by using "binders" instead of "builders".
- a binder is instantiated
- its initialize() method is called, passing the annotation as a parameter
- its bind() method is called, passing the binding context as a parameter. The method returns the bridge instance. Any "optional" data returned by the binder (field type for value bridges, in particular) is returned through the binding context.
Advantages:
- It's simpler: one fewer step
- It's cleaner: the bridges become completely immutable, since the bind() method on bridges disappears.
- It does not have to be more verbose: binder implementors can simply pass the context to the constructor of their bridge, and move to that constructor what they previously did in the bind() method.
- It's more flexible: binders can pick a bridge implementation based on the binding context, for example based on the property type...
- It solves the problem of how to pass "parameters" (see
 HSEARCH-3608 Open ): we would pass them to the binder directly, through an "initialize" method.
Cons:
- It may require one interface per bridge type. Things could get complicated if we consider we also need one sub-interface to support annotations. Maybe we should expose a non-generic initialize(Annotation) method on all binders, with a default implementation that throws an exception?
- We may need to add generics to the binder interfaces. For example to make sure that a ValueBridge binder only ever declares a field type that is consistent with the F parameter of the returned bridge.
- Value bridges referenced by their type, without a builder/binder, can no longer define a custom type. Since that's advanced usage, I would argue it's reasonable to require a binder.
|
