Utilizo una clase que solo extrae datos de un objeto conocido y los distribuye a otros objetos conocidos. No se necesita una configuración persistente o tal en esa instancia de clase.
¿Cómo debo decidir si configurar esa clase como singleton , o simplemente crear una instancia cada vez que lo necesite? ?
A veces se considera que el singleton es un antipatrón . A menos que el problema que se resuelva específicamente requiera el uso del patrón Singleton, generalmente es mejor evitarlo.
Usted menciona que la función no tendría requisitos de estado u otros requisitos de larga duración, por lo que tampoco existe la necesidad inmediata de un objeto .
Una función libre sería la mejor (o una función estática o similar dado el idioma y el destino), ya que no tiene ningún estado y no presenta ningún problema asociado con el singleton.
Si una función libre no es una opción, un objeto vacío (sin miembros de datos) probablemente sea una segunda opción lo suficientemente cerca.
En general, mi consejo al elegir un patrón es entender primero qué problema busca resolver el patrón y cuáles serían las limitaciones y limitaciones del patrón. Una vez entendido, si el problema que se está resolviendo cae dentro del espacio de problemas de ese patrón, ese patrón sería un candidato para su uso.
¿Cómo determina qué son estos 'objetos conocidos'? Si su código está codificado (es decir, el objeto es un objeto estático o singleton), entonces puede usar un método estático para realizar el procesamiento; según sea necesario.
No puedo ver por qué necesitaría una clase completa para este proceso, a menos que los objetos conocidos se consideren como un estado interno de la clase. En este caso, depende de la frecuencia con la que lo necesite y el costo de su construcción, requiere mucho esfuerzo, probablemente lo mejor sea un singleton.
Creo que la respuesta de Niall es buena y que la respuesta aceptada es correcta, pero deseo agregar un poco en la vena de usar Singletons.
El patrón Singleton es un poco como el comunismo. Se ve bien en el papel, pero cuando se mezcla con la gente, las cosas tienden a desmoronarse.
La cuestión es que el patrón Singleton no es, intrínsecamente, un antipatrón. Es más que la mayoría de las implementaciones (ingenuas) tienden a hojear aspectos importantes o causar posibles problemas.
Por ejemplo, en C ++, un Singleton inicializado globalmente se puede asignar casi siempre que se inicie el ciclo principal. La combinación de varios Singletons de esta manera significa que no tiene idea de qué orden se inicializarán entre sí. El orden de limpieza es igualmente arbitrario (pero generalmente es el reverso del orden en el que se iniciaron). (Hay ALGUNAS reglas básicas para esto, pero principalmente se deja a demonios nasales .)
Los objetos globales y fácilmente accesibles también tienden a terminar en los reinos de una God Class , que es mucho Un anti-patrón. Ideas como "Ya tengo una clase de Gerente, simplemente la pegaré allí" son fáciles y la solución es rápida. Este es un caso de Deuda técnica .
Un Singleton controlado y administrado correctamente puede ser muy útil y no causar problemas, pero es un patrón más difícil de acertar de lo que las personas tienden a esperar. La peor parte es que los ejemplos de libros de texto tienden a enseñar malos hábitos para Singletons.
Para su caso específico, ya que no tiene un estado y no necesita cargar o descargar, no necesita un objeto. Una función estática o equivalente debe satisfacer sus necesidades.
Y, dado que no puedo comentar (sacude el puño) , quiero secundar el punto de Niall sobre la comprensión de lo que resuelve un patrón y dónde funciona. También recomiendo investigar cómo funciona y cómo implementarlo mejor, ya que implementar un patrón correctamente es al menos tan importante como elegir el patrón correcto .
Lea otras preguntas en las etiquetas class class-design singleton instance