It is better to have a caching mechanism inside or

问题:

my question here is not strictly language related, it is more a general programming concept.

If I have a Factory class that has a method to return Parser objects, and these parser classes ,I know, do not need to be instantiated more than once per iteration cycle (outside of the factory, of course).

It is better, in terms of use and object separation to create a caching mechanisms for all the instantiated Parsers inside of the Factory, ie: during the method call, or outside of it, when the method has already been called?

Thanks in advance.

回答1:

Perhaps you could define an interface for your Factory, and then have multiple implementations - one implementation could perform the caching internally to guarantee that a Parser class is only instantiated once. Another implementation could perform no caching and just provide new Parser objects whenever something asks for one.

Either way, I suggest you try to keep this logic inside your Factory implementations and have the rest of your application work with the Factory interface. This way if you decide later that you don't want to cache anything or that you need to change the way a Parser is instantiated, you only have a single point of object creation - inside the Factory. This makes it really easy to change the way you construct Parser objects without having to change every part of your application that wants a new Parser.

Once again - if you create caching mechanisms to operate outside of the Factory, then those mechanisms will be all over your code since you have to use them whenever you want to get a new Parser. If you decide later to change the caching mechanism, you're going to have to touch a lot of code, but if you do the caching inside the Factory, you only have to change the Factory implementation.

回答2:

I don't understand the problem: the clients of the factory class don't care whether the objects they receive are cached or not. So the caching logic must belong to the factory.

Moreover, when you implement this, you first implement the factory without caching in order to have something working fast (Do the simplest thing that could possibly work). Then, you implement caching. Note that doing anything else is a case of premature optimization. If the client classes had to know whether the objects are cached or not, your development process would rot quickly.

How you implement it is up to you. I like writing once a generic caching class and reuse it in situations like this, but you could think about other mechanisms. Besides, I don't do java and therefore I cannot state about what is better to do here.

(PS: I see a lot of design pattern noise in the answers to this question. Is this common among java people to always think in term of patterns ? There are no singletons to design, no proxy classes to write here, only a simple reasoning about which interface cannot change).

回答3:

Sounds to me like what you need to use is the Singleton Pattern.

回答4:

As Shakedown stated, one approach would be to work against an interface and supply a caching implementation and a separate non-caching implementation. This can get to be a bit cumbersome in some circumstances though (does your app really need two different implementations?).

If you have a number of classes like this, you might consider using a Proxy pattern. The Proxy class will implement the same interface as the Factory implementation and delegate to the factory only if the object that would be returned from the Factory is not already in the Proxy's cache.

Using a dynamic proxy will extend this approach and allow you to implement caching wherever you want with very little additional library bloat (but at the cost of increased complexity).