Use cacheing in Factories

[mmitch]

While it's nice to have so many easy to use Factories around, calling them multiple times within every loop iteration is cleary a performance issue with all those object creations. After all, this is Java we're talking about.

Cacheing is the obvious solution to this.

All existing Factories should either implement a CacheingFactoryInterface or a PlainFactoryInterface (this needs a better name).

Factories implementing the PlainFactoryInterface work the same as now and create new instances on every invocation.

Factories implementing the CacheingFactoryInterface get to keep a local store of all created objects, so instead of creating new objects, an already existing object can be returned. (If the caller of such a Factory really needs a fresh object with no other references pointing to it, the caller can clone() the returned object.)

The Cache itself would best be handled in an extra class which in turn is of course created by another Factory: for a proper production deployment it's neccessary to support different setups, from a plain in-memory HashtableCache up to an SQLBackendDrivenCache or a NetworkFileshareCache. A DoesNotCache for testing and debugging purposes will also be useful.

In low-memory environments (think embedded applications), the Caches should have extra logic to store either only the last n created elements or even better only the n most requested elements.

[ExPixel]

I hope that the second sentence of this issue is a joke...

[james-m-henderson]

I think that the existing factories should also implement an OptimizingFactoryInterface, which will always map to the optimal type of factory implementation (caching or plain). That way classes which are calling a factory that implements the PlainFactoryInterface or the CacheingFactoryInterface don't need to know which one it is using, just that it is the optimal sort of factory interface for that factory.