¿Es mejor tener un mecanismo de almacenamiento en caché dentro o fuera de una clase de fábrica?

Question

mi pregunta aquí no está estrictamente relacionada con el lenguaje, es más un concepto de programación general.

Si tengo una clase Factory que tiene un método para devolver objetos Analizador, y estas clases de analizador, lo sé, no es necesario crear instancias más de una vez por ciclo de iteración (fuera de la fábrica, por supuesto).

Es mejor, en términos de uso y separación de objetos, crear mecanismos de caché para todos los Parseadores instanciados dentro de la Fábrica, es decir: durante la llamada al método, o fuera de ella, cuando el método ya ha sido llamado?

Gracias de antemano.

Answer 1

Quizás podría definir una interfaz para su Factory, y luego tener múltiples implementaciones: una implementación podría realizar el almacenamiento en caché internamente para garantizar que una clase Parser solo se instanciara una vez. Otra implementación podría realizar caché y simplemente proporcionar nuevos objetos Parser cada vez que algo lo solicite.

De cualquier manera, le sugiero que intente mantener esta lógica dentro de sus implementaciones Factory y que el resto de su aplicación funcione con la interfaz Factory. De esta forma, si luego decide que no desea almacenar en caché nada o que necesita cambiar la forma en que se crea una instancia de Parser, solo tiene un único punto de creación de objetos, dentro del Factory. Esto hace que sea muy fácil cambiar la forma en que construyes los objetos Parser sin tener que cambiar cada parte de tu aplicación que desee un nuevo Parser.

Una vez más, si crea mecanismos de almacenamiento en caché para operar fuera del Factory, esos mecanismos estarán en todo su código ya que debe usarlos cada vez que desee obtener un nuevo Parser. Si luego decide cambiar el mecanismo de almacenamiento en caché, tendrá que tocar una gran cantidad de código, pero si lo hace dentro del Factory, solo tiene que cambiar la implementación Factory.

Answer 2

Me parece que lo que necesita es el Singleton Pattern.

Answer 3

Como dijo Shakedown, un enfoque sería trabajar contra una interfaz y proporcionar una implementación de almacenamiento en caché y una implementación separada que no sea de almacenamiento en caché. Sin embargo, esto puede llegar a ser un poco engorroso en algunas circunstancias (¿su aplicación realmente necesita dos implementaciones diferentes?).

Si tiene varias clases como esta, puede considerar usar un patrón Proxy. La clase Proxy implementará la misma interfaz que la implementación de fábrica y la delegará en la fábrica solo si el objeto que se devolvería desde Factory no está ya en la caché del Proxy.

El uso de un proxy dinámico extenderá este enfoque y le permitirá implementar el almacenamiento en caché en cualquier lugar que desee con muy poco aumento adicional de la biblioteca (pero a costa de una mayor complejidad).

Answer 4

No entiendo el problema: a los clientes de la clase de fábrica no les importa si los objetos que reciben están en la memoria caché o no. Por lo tanto, la lógica de almacenamiento en caché debe pertenecen a la fábrica.

Además, cuando implemente esto, primero implemente la fábrica sin almacenamiento en caché para tener algo trabajando rápido (Haga lo más simple que pueda funcionar). Luego, implementas el almacenamiento en caché.Tenga en cuenta que hacer cualquier otra cosa es un caso de optimización prematura . Si las clases de los clientes tenían que saber si los objetos están en la memoria caché o no, su proceso de desarrollo se pudriría rápidamente.

Cómo lo implementa depende de usted. Me gusta escribir una vez una clase genérica de almacenamiento en caché y reutilizarla en situaciones como esta, pero podrías pensar en otros mecanismos. Además, no hago Java y, por lo tanto, no puedo decir qué es mejor hacer aquí.

(PD: Veo un montón de ruido de patrón de diseño en las respuestas a esta pregunta. ¿Es común entre los java pensar siempre en términos de patrones? No hay clases únicas para diseñar, no hay clases de proxy para escribir aquí, solo un razonamiento simple sobre qué interfaz no puede cambiar).