Adam Heath wrote:
Adrian Crum wrote:
David,
I've been thinking about this more. Here are a couple of ideas I came up
with:
1. Move the existing delegator cache maintenance methods to a separate
interface+class. Add a method to DelegatorInterface that retrieves an
instance of the class for peripheral code to work with. End result: +1
cache maint class, +1 delegator accessor method, -14 delegator cache
maintenance methods.
I've thought this too. So all delegator calls would be wrapped,
effectively, and do cache storing.
The code in entity/cache has some algos that could be used for this.
They take their parameters, convert them into a 'key', and use that for
access.
Yesterday I played around with the code to do this - it was really simple. No, the delegator calls
wouldn't be wrapped... I think. I'm not sure what you mean. I moved all of the DelegatorInterface
ClearAllCacheXxx and ClearCacheXxxx methods to a separate interface and added the accessor method to
the DelegatorInterface. Then I added the cache maint interface implementation to GenericDelegator as
an inner class. The end result was the GenericDelegator code size didn't change - because the outer
class methods were simply moved to the inner class, but the Delegator API was simplified.
