correctamente usando el patrón de diseño Singleton

Question

Estoy corriendo un servidor que en ocasiones tiene que buscar lo que a consultas de los clientes. Me gustaría escribir la consulta del cliente en el disco para los registros, pero no quiero ralentizar la búsqueda más de lo necesario. (La búsqueda ya es el cuello de botella ...)

Por lo tanto, cuando el cliente realiza una búsqueda, el hilo del cliente envía un mensaje a un hilo singleton, que manejará la escritura del disco, mientras que el hilo del cliente continúa manejando las solicitudes del cliente. De esta forma, el archivo en el disco no se encuentra con problemas de sincronización y no desacelera la experiencia de los clientes.

Tengo una pregunta conceptual aquí: ¿es el singleton apropiado en este caso? He estado usando demasiado el patrón de diseño singleton en mi programación reciente, y quiero asegurarme de que lo estoy usando para su uso previsto.

Cualquier comentario es muy apreciado.

Answer 1

El singleton pattern es definitivamente usado en exceso y viene con su cuota de difficulties (la prueba unitaria es el ejemplo canónico), pero como todo en el diseño, debe sopesar los pros y los contras para su escenario específico. El patrón singleton tiene sus usos. Hay opciones que pueden permitirle obtener el comportamiento singleton, al tiempo que se alivian algunos de los problemas inherentes:

Interception (a menudo se denomina programación orientada a aspectos, aunque he visto el debate de que no son exactamente lo mismo. ..no puedo encontrar el artículo que leí sobre esto en este momento) es definitivamente una opción. Puede usar cualquier combinación de inyección de construcción, el patrón decorator, una fábrica abstracta y inversion of control container. No estoy al tanto de mis contenedores Java IoC, pero hay algunos contenedores .Net que permiten la interceptación automática (creo que Spring.Net lo hace, así que probablemente Spring (Java) tenga esto incorporado). Esto es muy útil para cualquier tipo de inquietud transversal, donde necesita realizar ciertos tipos de acciones en múltiples capas (seguridad, registro, etc.). Además, la mayoría de los contenedores IoC le permiten controlar la administración de por vida, por lo que podría tratar su registrador como un singleton, sin tener que implementar manualmente el patrón singleton.

En resumen. Si un singleton se ajusta a su situación (parece plausible de su descripción), vaya por ello. Solo asegúrate de haber sopesado los pros y los contras. Es posible que desee probar un enfoque diferente y comparar los dos.