Java 最好在工厂类内部或外部有一个缓存机制？

我这里的问题不是严格的语言相关问题，它更多的是一个通用的编程概念

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

在使用和对象分离方面，最好为工厂内的所有实例化解析器创建缓存机制，即：在方法调用期间，还是在方法调用之外，当方法已经被调用时

---

提前感谢。

也许您可以为

工厂定义一个接口，然后有多个实现-一个实现可以在内部执行缓存，以保证
解析器
类只实例化一次。另一个实现可以不执行缓存，只要在有东西需要时提供新的
解析器
对象

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

再次—如果您创建缓存机制以在
工厂之外运行，那么这些机制将遍布您的代码，因为您需要在任何时候获得新的
解析器时都必须使用它们。如果您稍后决定更改缓存机制，您将不得不接触大量代码，但如果您在
工厂
中进行缓存，则只需更改
工厂
实现。
如调试所述，一种方法是使用接口并提供缓存实现和单独的非缓存实现。但在某些情况下，这可能会有点麻烦（你的应用真的需要两种不同的实现吗？）

如果你有很多这样的类，你可以考虑使用代理模式。代理类将实现与工厂实现相同的接口，并且仅当将从工厂返回的对象不在代理缓存中时，才会委托给工厂
使用动态代理将扩展这种方法，并允许您在任何需要的地方实现缓存，而只需要很少的额外库膨胀（但以增加复杂性为代价）。
我不理解这个问题：factory类的客户端不关心它们接收的对象是否被缓存。因此缓存逻辑必须属于工厂

此外，当您实现这一点时，您首先实现工厂而不缓存，以便让某些东西快速工作（做可能工作的最简单的事情）。然后，实现缓存。请注意，执行任何其他操作都会导致过早优化。如果客户机类必须知道对象是否被缓存，那么您的开发过程将很快崩溃

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

（PS：我在这个问题的答案中看到了很多设计模式噪音。java人总是按照模式思考是不是很常见？这里没有要设计的单例，没有要编写的代理类，只有关于哪个接口不能更改的简单推理）。
另见@Tom Brito：我理解这个原理，但你需要解释它是如何应用于这种情况的。事实上，我已经把它发布给了任何看到你答案的人，不是专门为你。这一原则适用于这种情况，因为他在问他的班级是否应该承担更多的责任。按照这个原则，答案是否定的，缓存机制应该放在外部，在另一个类中。当然，这在很大程度上取决于他的项目，但如果他想遵循一种模式，这可能是一种好的模式。@Tom Brito，你告诉我最好创建一个缓存类，并在工厂外保持缓存，而@Shakedown告诉我的正好相反，你们两人都对此提出了很好的理由，现在我应该选择…如果你制作了一个
缓存装饰器
你根本不需要更改你的代码…只要用
缓存装饰器
包装你的工厂，当你的代码要求一个新对象时，装饰器决定它是返回旧的缓存对象还是从里面的工厂返回一个新对象。我已经按照你说的做了，第一个实现没有缓存，我现在介绍缓存作为一种优化形式，并想知道什么方法应该是最好的。是的，在Java世界中，以模式思考是很常见的，是四人帮塑造了我们所有人，幸运与否：）@Lex：对我来说，设计模式一直都是你可以自己想出的琐碎东西，或者是缺少语言支持的变通方法。滥用模式就是把程序员变成一个程序。但是，如果你能很好地理解它们在什么时候适用，最重要的是当它们不适用时，它们可以帮助你想出好的设计实践。我觉得“java学校”（在法国，最糟糕的编程学校教java，因此我对java抱有毫无根据的偏见）会尽力避免让你思考。