¿Es una mala idea crear una clase que solo tenga una instancia?

¿Es una mala práctica / diseño de codificación hacer una clase que solo se instanciará una vez?

Tengo algunas variables y funciones que se pueden agrupar bajo una clase para "verse bien" (a falta de una mejor descripción) ya que están algo relacionadas, pero pueden ser variables globales y funciones globales.

(Por cierto, estoy usando JavaScript, AngularJS, Express, MongoDB.)

Una instancia única para una clase tiene sentido si el objeto representa un recurso único, como una conexión de Ethernet o el administrador de tareas del sistema operativo, por ejemplo.

Las funciones se colocan en una clase solo si actúan sobre las variables de instancias de esa clase, de lo contrario el mantenedor se confundirá acerca de la intención de esa clase.

Por lo general, existe una buena razón por la cual su aplicación tiene variables globales. Intenta encontrar el propósito común de ellos y diseña una clase alrededor de este propósito. No solo aclarará el diseño, sino también su mente.

No hay problema con escribir una clase que termine siendo instanciada solo una vez.

Si reunir algunas variables y funciones dentro de una clase tiene sentido, tiene un valor semántico o hace que el código sea más fácil de leer y manipular, entonces que así sea, los mantenedores estarán agradecidos.

Sin embargo, lo que puede estar muy mal es hacer cumplir la unicidad desde adentro.

Muchas personas tienden a disparar el patrón singleton tan pronto como piensan que solo necesitarán una instancia de algo. Vea, por ejemplo, cómo no ha descrito su contexto en profundidad, pero la mayoría de las respuestas ya le sugieren que use un singleton. Y luego, el diseño podría estar atornillado porque si necesita otra instancia en algún momento por cualquier razón, la clase le impedirá hacerlo sin cambiar mucho código.

Como conclusión, una instancia está bien, pero asegúrese de saber si:

1. que sólo necesita un ejemplo, o
2. no puedes tener más de una instancia (un caso muy, muy raro en mi experiencia).

¿Es una mala práctica / diseño de codificación hacer una clase que solo se instanciará una vez?

No, incluso si solo se instancia una vez, necesita una clase para ello. Pero no suponga que siempre necesitará solo una instancia, ahora y en el futuro.

Supongamos que haces un juego y tienes una clase de jugador:

class Player {
    ...
}

Instanciará una clase de jugador en su juego y usará siempre el mismo objeto. No tiene nada de malo.

Sin embargo, ¡no hagas un Singleton! Hoy diseñas tu juego y piensas "Bueno, siempre será un juego de un jugador. Usaré un Singleton para mi jugador". Pero en la versión 2, es posible que desee implementar el modo multijugador, y luego se está metiendo en problemas. Tendrá que volver a escribir y adaptar una gran cantidad de código, porque su diseño no admite la creación de instancias de varios jugadores.

Lo mismo ocurre con los cachés. O madereros. O interfaces de red. Hoy, crees que solo necesitarás uno, siempre, seguro. Pero en una versión futura necesita agregar un segundo. Ten en cuenta esta situación.

Hay clases singleton y ese es un patrón de diseño común.

También hay clases que nunca se instancian. Si tiene funciones que NO operan en ningún estado persistente (por ejemplo, toman la entrada y la transforman), generalmente puede usar un método estático. En algunos lenguajes (como Java), estos métodos estáticos se declararían en una clase, pero la clase en sí misma nunca se instanciará.

El patrón singleton es común. Le permite imponer una sola instancia de clase.

Pero para algunos es demasiado común, por lo que se convierte en un antipatrón. La razón de esto es porque es prácticamente lo mismo que el estado global. Y cualquier estado global es difícil de burlar y probar y difícil de depurar. Pero al mismo tiempo, tener que pasar explícitamente esta instancia a todas partes en su código puede hacer que el código se hinche mucho. Pero esto te hará pensar en una arquitectura adecuada. Si un montón de clases usan este singleton, puede pensar que están relacionados de alguna manera y crear un ancestro común para ellos, que encapsulará esta instancia para ellos.

Es malo asumir que algo es universalmente malo. En su caso, tal vez sería una buena idea, pero dado que está utilizando un lenguaje que no es OO en el núcleo, es más apropiado probablemente usar métodos y variables sueltos y colocarlos en una biblioteca común que incluya en su otro trabajo.

Estás haciendo dos preguntas en una.

1. No, no hay nada malo en tener una clase que solo tendrá una instancia.
2. Agrupar variables y métodos en una clase sin una razón real es un mal diseño.