最好在Factory类的内部或外部有一个缓存机制？

Question

这里我的问题与语言无关，它更像是一般的编程概念。

如果我有一个具有返回Parser对象的方法的Factory类，以及这些解析器类，我知道，不需要每个迭代周期多次实例化（当然在工厂外）。

在使用和对象分离方面，最好为Factory内部的所有实例化Parser创建一个缓存机制，即：在方法调用期间，或者在方法调用之外，当方法已被调用时？< / p>

提前致谢。

Answer 1

也许你可以为你的Factory定义一个接口，然后有多个实现 - 一个实现可以在内部执行缓存，以保证Parser类只被实例化一次。另一个实现可以不执行缓存，只要有人要求提供新的Parser对象。

无论哪种方式，我建议您尝试将此逻辑保留在Factory实现中，并让其余的应用程序使用Factory接口。这样，如果您稍后决定不想缓存任何内容或者需要更改Parser实例化的方式，那么您只需创建一个对象点 - 在Factory内。这使得更改构造Parser对象的方式变得非常容易，而无需更改需要新Parser的应用程序的每个部分。

再一次 - 如果您创建了在Factory之外运行的缓存机制，那么这些机制将遍布您的代码，因为您必须在需要获取新Parser时使用它们。如果您稍后决定更改缓存机制，则必须触及大量代码，但如果您在Factory内执行缓存，则只需更改Factory实现。

Answer 2

我不明白这个问题：工厂类的客户端不关心他们收到的对象是否被缓存。因此缓存逻辑必须属于工厂。

此外，当你实现这个时，你首先实现没有缓存的工厂，以便快速工作（做最简单的事情）。然后，您实现缓存。请注意，执行其他任何操作都是过早优化的情况。如果客户端类必须知道对象是否被缓存，那么您的开发过程会很快腐烂。

您如何实施它取决于您。我喜欢写一个通用缓存类并在这种情况下重用它，但你可以考虑其他机制。此外，我不做java，因此我不能说明在这里做什么更好。

（PS：我在这个问题的答案中看到了很多设计模式的噪音。这在java人群中是否常常在模式方面进行思考？没有单例设计，没有代理类可以在这里写，只有关于哪个界面无法改变的简单推理。

Answer 3

听起来我需要使用的是Singleton Pattern。

Answer 4

正如Shakedown所说，一种方法是针对接口工作并提供缓存实现和单独的非缓存实现。在某些情况下，这可能会有点麻烦（你的应用程序真的需要两种不同的实现吗？）。

如果您有许多这样的类，您可以考虑使用代理模式。 Proxy类将实现与Factory实现相同的接口，并且仅当将从Factory返回的对象尚未在Proxy的缓存中时才委托给工厂。

使用动态代理将扩展此方法，并允许您在任何需要的位置实现缓存，只需要很少的额外库膨胀（但代价是增加了复杂性）。