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 .