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).
如果我有一个具有返回Parser对象的方法的Factory类,以及这些解析器类,我知道,每个迭代周期不需要多次实例化(当然,在工厂之外)。
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?
在使用和对象分离方面,最好为Factory内部的所有实例化的Parser创建一个缓存机制,即:在方法调用期间,或者在方法调用之外,当方法已被调用时?
Thanks in advance.
提前致谢。
4 个解决方案
#1
5
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.
也许您可以为Factory定义一个接口,然后有多个实现 - 一个实现可以在内部执行缓存,以保证Parser类只实例化一次。另一个实现可以不执行缓存,只要有东西要求一个就提供新的Parser对象。
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.
无论哪种方式,我建议您尝试将此逻辑保留在Factory实现中,并使其余应用程序与Factory界面一起使用。这样,如果您稍后决定不想缓存任何内容或者您需要更改实例化Parser的方式,那么您只需要在Factory中创建一个对象点。这使得更改构造Parser对象的方式变得非常容易,而无需更改需要新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.
再一次 - 如果你创建了在工厂外运行的缓存机制,那么这些机制将遍布你的代码,因为你必须在想要获得新的Parser时使用它们。如果您稍后决定更改缓存机制,则必须触及大量代码,但如果您在Factory中执行缓存,则只需更改Factory实现。
#2
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.
你如何实现它取决于你。我喜欢写一个通用缓存类并在这种情况下重用它,但你可以考虑其他机制。此外,我不做java,因此我不能说明在这里做什么更好。
(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).
(PS:我在这个问题的答案中看到了很多设计模式的噪音。这种情况在java人中总是常常用模式来思考吗?没有单例设计,没有代理类写在这里,只是一个简单的推理关于哪个界面无法改变)。
#4
0
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?).
正如Shakedown所说,一种方法是针对接口工作并提供缓存实现和单独的非缓存实现。在某些情况下,这可能会有点麻烦(您的应用程序确实需要两种不同的实现吗?)。
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.
如果您有许多这样的类,您可以考虑使用代理模式。 Proxy类将实现与Factory实现相同的接口,并且仅当将从Factory返回的对象尚未在Proxy的缓存中时才委托给工厂。
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).
使用动态代理将扩展此方法,并允许您在任何地方实现缓存,只需要很少的额外库膨胀(但代价是增加了复杂性)。
#1
5
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.
也许您可以为Factory定义一个接口,然后有多个实现 - 一个实现可以在内部执行缓存,以保证Parser类只实例化一次。另一个实现可以不执行缓存,只要有东西要求一个就提供新的Parser对象。
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.
无论哪种方式,我建议您尝试将此逻辑保留在Factory实现中,并使其余应用程序与Factory界面一起使用。这样,如果您稍后决定不想缓存任何内容或者您需要更改实例化Parser的方式,那么您只需要在Factory中创建一个对象点。这使得更改构造Parser对象的方式变得非常容易,而无需更改需要新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.
再一次 - 如果你创建了在工厂外运行的缓存机制,那么这些机制将遍布你的代码,因为你必须在想要获得新的Parser时使用它们。如果您稍后决定更改缓存机制,则必须触及大量代码,但如果您在Factory中执行缓存,则只需更改Factory实现。
#2
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.
你如何实现它取决于你。我喜欢写一个通用缓存类并在这种情况下重用它,但你可以考虑其他机制。此外,我不做java,因此我不能说明在这里做什么更好。
(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).
(PS:我在这个问题的答案中看到了很多设计模式的噪音。这种情况在java人中总是常常用模式来思考吗?没有单例设计,没有代理类写在这里,只是一个简单的推理关于哪个界面无法改变)。
#3
#4
0
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?).
正如Shakedown所说,一种方法是针对接口工作并提供缓存实现和单独的非缓存实现。在某些情况下,这可能会有点麻烦(您的应用程序确实需要两种不同的实现吗?)。
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.
如果您有许多这样的类,您可以考虑使用代理模式。 Proxy类将实现与Factory实现相同的接口,并且仅当将从Factory返回的对象尚未在Proxy的缓存中时才委托给工厂。
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).
使用动态代理将扩展此方法,并允许您在任何地方实现缓存,只需要很少的额外库膨胀(但代价是增加了复杂性)。