with variable inside es6 singleton global-variables

inside - ok, la variable global está condenada, Singleton es despreciado, ¿cuál es la alternativa?



singleton es6 js (9)

Para la aplicación de escritorio que es. Esta es solo una pregunta general que quizás solo necesite respuestas generales.


Eso depende completamente del problema que estás tratando de resolver. Este bit de información clave fue omitido por usted. Si está buscando una solución general, no hay ninguna. Simplemente hay patrones que aplicamos cuando corresponda.


La preocupación más común que he visto tanto con los globales como con los singleton es que corres el riesgo de tener un mal comportamiento al usar los hilos. En este caso, siempre debe usar el alcance de ejecución como su unidad base. Esta es una de las fortalezas de la programación OO: puede usar los miembros del objeto para contener todos los datos relevantes con muy poco miedo al caos accidental de hilos. Esto contrasta con un lenguaje de programación no compatible con OO, donde tendrías que pasar los datos a través de parámetros.

La otra preocupación común tiende a ser organizacional: es difícil entender exactamente de dónde provienen los datos en un sistema grande cuando se puede leer / escribir en cualquier momento. Esto es, en mi experiencia, más un problema con el desarrollador que con el código per se. A menos que esté trabajando en uno de esos megasistemas de cien millones de líneas que parecen surgir principalmente en los libros de programación como ejemplos de problemas difíciles, podrá buscar en toda su base de código un artículo en particular en un plazo razonablemente corto. período de tiempo. El siguiente paso necesario es auditar regularmente la base de código para garantizar que las variables globales / estáticas no se asignen al azar. Esto es anatema para muchos enfoques de desarrollo, pero para sistemas de cierto tamaño y complejidad es una solución perfectamente viable.


La respuesta depende del idioma. Recientemente conocí a un chico cuya compañía desarrolla la pila USB que se ejecuta en muchos teléfonos celulares populares (por ejemplo, para que su teléfono pueda hablar con su computadora). Tienen una regla en su tienda que todos los procedimientos C deben ser reentrantes. En la práctica, esto significa que, en lugar de variables globales, usan un parámetro adicional para cada rutina; el parámetro apunta al estado que debe persistir entre las rutinas.

Uso esta técnica todo el tiempo para abstracciones con estado. Ejemplo: abstracción del lector para imágenes fotográficas: el lector proporciona acceso a un píxel a la vez; debe conocer el descriptor de archivo abierto, cuál es la posición actual en la imagen, etc. Toda esa información va a una estructura de C privada o a los miembros privados de una clase de C ++. Sin variables globales El mundo exterior ve:

typedef struct Pnmrdr_T *Pnmrdr_T; struct Pnmrdr_T *Pnmrdr_new(FILE *); pixel Pnmrdr_get(Pnmrdr_T); void Pnmrdr_close(Pnmrdr_T); void Pnmrdr_free(Pnmrdr_T *rp); // frees memory and sets *rp = NULL

Este estilo de programación es muy similar a los métodos OO.

¿Por qué mejor que las variables globales? No hay sorpresas Si algo sale mal o desea agregar una característica, sabrá que todo es explícito en los valores que se pasan. Además, sabe que puede conectar muchos módulos y no interferirán a menos que pase explícitamente el estado entre ellos. Mi contacto en el negocio de teléfonos celulares dice que esta propiedad ha sido enorme para su compañía: son un equipo de software OEM y pueden conectar fácilmente diferentes piezas para diferentes clientes.

Realmente me gusta programar de esta manera porque puedo ver todo lo que está sucediendo, y mis estructuras de datos privadas están protegidas de miradas indiscretas :-)


Las variables globales son excelentes en los programas pequeños, pero cuando se hacen más grandes, uno empieza a tener efectos secundarios extraños cuando alguien hace un cambio o corrige un error al decir "oh, voy a establecer esto global y el problema desaparece".


No me importaría si no se recomiendan las variables únicas o globales. Si siento que esa es la forma más lógica de implementarlo, lo usaré.


Una clase estática con miembros de datos estáticos? Pero a quién le importa. Los miembros de datos estáticos son solo variables globales con un embalaje más políticamente correcto.

No dejes que la moda anule tu sentido común. No hay nada malo con el uso de una antigua variable global simple. El patrón singleton a menudo es excesivo y molesto de escribir, y molesto cuando estás solo pasando por el código para depurarlo.

Suponiendo que está utilizando C / C ++, le recomendaría que no tenga variables globales que sean instancias de clase que asignen memoria desde el montón. Le dificultarán usar herramientas que verifiquen las pérdidas de memoria. Declare global como un puntero, nuevo al principio de main (), elimínelo al final.

EDITAR DESPUÉS DE 6 COMENTARIOS: Piense en iniciar sesión. ¿No le gustaría poder escribir una línea en su registro desde cualquier lugar de su aplicación? ¿Cómo concretamente logras eso sin que haya algo globalmente visible para hacer esa tala? Si quieres algo globalmente visible, adelante y hazlo visible globalmente.


Una solución común para esto es usar clases de instancia única en lugar de variables únicas / globales.

Su aplicación será responsable de asegurarse de tener solo una instancia.

Esta solución es una mierda porque no se puede evitar que las personas instanciando tu clase (no es un singleton) por lo que debe ser una clase interna.

Sin embargo, no me interesarían demasiado las guerras religiosas sobre el patrón de singleton: si creo que se adapta a mis necesidades, generalmente lo uso.


Primero, no tiene sentido pretender que las uniones son de alguna manera mejores o más aceptables que las globales. Un singleton es solo un mundo disfrazado para parecerse a OOP. Con muchos otros problemas.

Y la alternativa es, por supuesto, no tener datos globales. En lugar de que su clase acceda a alguna variable estática (global) en alguna parte, pase los datos a su constructor. Sí, significa que debe agregar algunos argumentos al constructor, pero ¿es eso algo malo? Hace que las dependencias para la clase sean explícitas. Puedo probar la clase simplemente proporcionándoles diferentes objetos en el constructor, mientras que si se basa en datos globales, esos valores globales tienen que existir en mi prueba, que es desordenada.

Del mismo modo, puedo refactorizar fácilmente, porque no hay dependencias mágicas en clases que no sean las que pasaron directamente al objeto.

La seguridad del subproceso es más fácil de administrar porque ya no tiene todos sus objetos que se comunican con la misma instancia global. En cambio, se les pueden pasar instancias separadas de la clase.


Después de usar los globales y los singletons y ver todo enredado, llegué a esta solución.

  1. hacer que cada variable global sea miembro de una clase. Lógicamente, cada variable global pertenece a la aplicación (o sistema). solo crea una clase de aplicación. definir objetos globales como propiedades. para que se creen cuando se llama por primera vez.

  2. crea un singleton para la clase de la aplicación, para que puedas acceder a él de manera global. Este será el único singleton en tu código. bueno, al final es como objetos system.out o system.in en java.

nota: lo sé, esta es una pregunta muy antigua, pero sigue siendo popular.