design-patterns - es6 - singleton pattern c#

¿Son los Singleton realmente tan malos? (12)

Posible duplicado:
¿Qué tiene de malo Singletons?

Es comprensible que en algunos casos se abuse de muchos patrones de diseño y, como siempre, mamá dijo: " Demasiado de algo bueno no siempre es bueno ".

Me doy cuenta de que en estos días estoy usando mucho los Singletons, y me preocupa que pueda estar abusando del patrón de diseño, y me estoy volcando cada vez más en un hábito de mala práctica.

Estamos desarrollando una aplicación Flex que tiene una estructura de datos jerárquica bastante grande guardada en la memoria mientras el usuario trabaja en ella. El usuario puede cargar, guardar, cambiar y actualizar los datos a pedido.

Esta información se centraliza por medio de una clase Singleton, que agrega un par de ArrayCollections, Arrays, objetos de valor y algunas otras variables de miembros nativos expuestas a través de getters y setters.

Para obtener una referencia a nuestros datos desde cualquier lugar de la aplicación, hacemos todo el tipo de método del método Model.getInstance () que estoy seguro de que todos conocen. Esto garantiza que siempre tengamos en nuestras manos la misma copia de datos, ya que cuando diseñamos, dijimos que solo una vez se permite que exista instancia durante la vida útil de la aplicación.

Desde este repositorio de datos central, es fácil para nosotros, por ejemplo, despachar eventos cambiados a la propiedad, y podemos tener múltiples componentes de IU que hacen referencia a los datos centrales, actualizar sus pantallas para reflejar los cambios en los datos que se han producido.

Hasta ahora, este enfoque ha sido eficaz y comprobado como muy práctico para nuestras circunstancias.

Sin embargo, estoy descubriendo que estoy un poco ansioso al crear nuevas clases. Preguntas como si una clase fuera un Singleton, o si más bien se administrase de otra manera, como por ejemplo usar una fábrica por ejemplo, a veces se vuelve un poco difícil, con un poco de incertidumbre.

¿Dónde dibujo la línea con singletons? ¿Hay una buena pauta para decidir cuándo usar Singletons y cuándo mantenerse alejado de ellos?

Además, ¿alguien puede recomendar un buen libro sobre patrones de diseño?

En mi opinión, el uso de Singletons señala directamente un defecto de diseño. La razón es simplemente que permiten eludir los mecanismos normales de creación y destrucción de objetos integrados en C ++. Si un objeto necesita una referencia a otro objeto, debe pasar una referencia a él en la construcción o crear una nueva instancia internamente. Pero cuando usas un singleton estás ocultando explícitamente el ciclo de creación y desmontaje. Un problema relacionado es que es extremadamente difícil controlar la vida útil de un singleton. Como resultado, muchos paquetes que incluyen implementaciones singleton genéricas también incluyen gestores de vida útil de objetos torpes y similares. A veces me pregunto si estos no existen simplemente para administrar los singletons.

Básicamente, si necesita usar un objeto en muchos lugares, debe crearse explícitamente en el punto común más alto de la pila y luego pasarlo por referencia a todos los que lo utilicen. A veces las personas usan Singletons porque tienen problemas para pasar múltiples argumentos a nuevos hilos, pero no se deje engañar por esto, defina explícitamente los argumentos de hilo y páselos al hilo nuevo de la misma manera. Descubrirá que su programa fluye mucho más limpio y no hay sorpresas desagradables debido a dependencias de inicialización estáticas o errores de desmontaje erróneos.

Google parece estar convinced que los Singleton son una mala idea.

Eso no es para sugerir que todo lo que Google hace es perfecto o que todas sus opiniones son el final de cualquier discusión, pero han llegado al extremo de escribir este detector Singleton para eliminarlas. Decídete de una vez.

Hemos comenzado un proyecto donde básicamente nos enfrentamos a la misma pregunta, es decir, cómo acceder al modelo , y especialmente a su elemento raíz. ¡El proyecto no es una aplicación Flex, sino un juego! aplicación web, pero eso no importa realmente.

Tener un único objeto único en el sistema está bien, el problema es cómo acceder a él . Entonces, el debate sobre singleton está relacionado con la noción de inversión de dependencia (DI) y cómo obtener objetos.

Los principales argumentos para DI son los siguientes:

capacidad de prueba y burla
desacoplar la instanciación de objetos del uso (que puede conducir a la administración del ciclo de vida)
separación de intereses

Los posibles enfoques para DI son (vea el article clásico de Fowler):

pasar el objeto en los parámetros del método
localizador de servicio
Marco DI

Bajo esta perspectiva, el patrón singleton es solo un tipo de localizador de servicio, por ejemplo, Model.getInstance() .

Pero para proporcionar la máxima flexibilidad frente a los cambios futuros, la referencia al objeto único se debe pasar tanto como sea posible, y se obtiene con Model.getInstance() solo cuando sea necesario. Esto también producirá un código más limpio.

La clave para recordar es que los patrones de diseño son solo una herramienta para ayudarlo a comprender los conceptos abstractos. Una vez que tenga esa comprensión, restringirse específicamente a una "receta" de un libro no tiene sentido y perjudica su capacidad para escribir el código más apropiado para su propósito.

Dicho esto, leer libros como GoF le presentará más formas de pensar sobre los problemas para que cuando llegue el momento de implementar algo por su cuenta, tenga un conjunto más amplio de perspectivas para abordar el problema.

En su caso, si usar singleton tiene sentido en todos los casos, continúe adelante. Si se adapta "de alguna manera" y tienes que implementarlo de una manera un tanto torpe, entonces necesitas encontrar una nueva solución. Obligar a un patrón que no es perfecto es como martillar una clavija cuadrada en un agujero redondo.

Dado que usted dice "este enfoque ha sido eficaz y ha demostrado ser muy práctico para nuestras circunstancias", creo que lo está haciendo bien.

Aquí hay algunos buenos libros:

Gang of Four Book - el libro clásico para patrones de diseño

Patrones de diseño de Head First : he escuchado esto recomendado por algunas personas como alternativa

Los Singletons ciertamente no son malos. Tienen sus usos, algunos de ellos muy buenos. Los singleton tienden a ser utilizados en exceso por los desarrolladores inexpertos, ya que a menudo es el primer patrón de diseño que aprenden, y es bastante simple, por lo que lo tiran por todos lados sin pensar en las implicaciones.

Cada vez que desee utilizar un singleton, intente considerar por qué lo está haciendo y cuáles son los beneficios y los aspectos negativos del uso de este patrón.

Los Singleton crean efectivamente un conjunto global accesible de ''cosas'' (ya sean datos o métodos) y creo que la mayoría de la gente estaría de acuerdo en que usar demasiadas variables globales no es una gran idea. El objetivo de las clases y la orientación de los objetos es agrupar las cosas en áreas discretas en lugar de simplemente colocar todo en un espacio global masivo.

Uno de los "patrones" que encuentro que prefiero a los singletons es pasar los objetos necesarios desde la parte superior. Los creo una vez durante la fase de inicialización de mi aplicación y los paso por todos los objetos que necesitan acceso a ellos. Imita la parte de ''creación única'' de un patrón singleton, pero sin la parte ''global''.

El objetivo de un singleton es que sea para objetos donde solo 1 debería existir. Usted menciona un conjunto de clases de control de datos. Tal vez tenga en cuenta que, en realidad, hay casos en los que una aplicación podría querer crear 2 conjuntos de clases de control de datos, por lo que quizás aplicar un Singleton no sea del todo correcto. En cambio, si creó estas clases de datos en la aplicación init, y las pasó, solo estaría creando 1 conjunto, ya que eso es lo que necesita la aplicación actual, pero deja abierta la posibilidad de que en algún momento, si necesita un segundo conjunto puedes crearlos fácilmente. Además, las clases de control de datos deberían ser accesible globalmente desde cualquier lugar de la aplicación. Creo que no, en su lugar, probablemente solo deberían ser accesibles desde una capa de acceso a datos de nivel inferior.

Algunas personas han recomendado el libro GOF. Yo diría que sí, que es un gran libro, pero primero intente primero encontrar un libro sobre arquitectura general, primero lea sobre diseño de 2/3 / n-tier, encapsulación, abstracción y este tipo de principios. Esto le dará una base más sólida con la cual entender el uso apropiado de los patrones de los que GOF habla.

[Editar: La otra vez que una variante de singleton puede ser útil es cuando quieres un punto de acceso único para algo, pero el detalle de la implementación en realidad podría ser más de una cosa. La persona que llama no necesita saber que, bajo las cubiertas, su solicitud del objeto singleton se resuelve realmente contra varios objetos disponibles y se devuelve uno. Estoy pensando en algo así como un grupo de subprocesos aquí, donde va el uso, hey, solo dame un hilo, necesito 1, pero no me importa cuál]

Los desarrolladores de software parecen estar bastante divididos en dos campos, según si favorecen un estilo de codificación idealista o uno pragmático:

Idealista: nunca use el patrón singleton.
Pragmático: evite el patrón singleton.

Personalmente, estoy a favor del enfoque pragmático. A veces tiene sentido romper las reglas, pero solo si realmente entiendes lo que estás haciendo y estás dispuesto a aceptar los riesgos asociados. Si puede responder "sí" a las preguntas siguientes con respecto a su caso de uso específico, el patrón de singleton puede generar algunos beneficios prácticos.

¿Es el singleton externo a tu aplicación? Las bases de datos, los servicios de puesta en cola y los ESB son todos ejemplos macro perfectamente válidos del patrón singleton.
KISS: ¿Toda tu aplicación está limitada a 2-3 singletons internos?
DRY: ¿Son esos singletons inherentemente globales y, por lo tanto, resultarían en tener que insertar las referencias en casi todos los objetos en su aplicación? (por ejemplo, un registrador o mediador componente)?
¿Sus singletons dependen solo unos de otros y / o del entorno operativo?
¿Se ha asegurado las secuencias correctas de inicio y cierre para cada singleton, incluidas las consideraciones de administración de memoria? Por ejemplo, un grupo de subprocesos de estilo "Grand Central" puede necesitar métodos Run () y Shutdown () de instancia en main () para garantizar la ejecución de tareas solo cuando los objetos en los que operan están en un estado válido.

Los singleton no matan programas, los programadores matan programas.

Como cualquier construcción de programación, cuando se usa apropiadamente, no te dispararás en el pie.

Los libros recomendados están bien, pero no siempre brindan suficientes antecedentes que vienen con la experiencia sobre cuándo podría elegir usar Singleton.

Esa experiencia solo llega cuando has descubierto que Singleton es una mala elección cuando necesitas tener varias instancias y, de repente, tienes muchos problemas para inyectar las referencias de objetos en todas partes.

A veces es mejor seguir adelante y tener las referencias de objetos en su lugar, pero el hecho de que esté utilizando Singleton ayuda a identificar el alcance del problema que enfrentaría si tuviera que refactorizarlo a un diseño diferente. Lo cual creo que es algo muy bueno: es decir, el solo hecho de tener una clase (incluso si está mal diseñado) le da cierta capacidad para ver los efectos de un cambio en la clase.

No, no son necesariamente malos.

En cuanto a un libro, debes comenzar con los clásicos .

Pensé que los solteros eran buenos .

Sé que este es un hilo viejo, pero nadie parecía mencionar el patrón real que se ajusta a lo que el OP intentaba hacer. Lo que creo que está describiendo una necesidad se llama Patrón de Mediador . SourceMaking es un sitio fantástico para aprender / hacer referencia a este tipo de información. Definitivamente voy al lugar para presentar a las personas los patrones del software. Además, generalmente es una buena idea no aceptar la idea de que cualquier patrón de diseño es inherentemente bueno o malo. Todos tienen su uso, solo aprender cuándo y dónde usarlos es el truco. Las personas que dicen que nunca deben usar Singletons, para mí, no entienden su utilidad.

Sí, los singletons son malos. Son malas porque todo lo que hacen por ti es combinar dos propiedades, cada una de las cuales es mala aproximadamente el 95% del tiempo. (Lo que significaría que, en promedio, los singletons son malos 99.75% del tiempo;))

Un singleton, como lo define el GoF, es una estructura de datos que:

Otorga acceso global a un objeto, y
Implica que solo una instancia del objeto puede existir alguna vez.

El primero generalmente se considera algo malo. No nos gustan los globals. El segundo es un poco más sutil, pero en general, prácticamente no hay casos en los que esta sea una restricción razonable para hacer cumplir .

Algunas veces, solo tiene sentido tener una instancia de un objeto. En cuyo caso, elige crear solo uno. No necesita un singleton para aplicarlo.

Y generalmente, incluso cuando "tiene sentido" tener solo una instancia, resulta que no tiene sentido después de todo. Tarde o temprano, vas a necesitar más de un registrador. O más de una base de datos. O tendrá que volver a crear recursos para cada una de las pruebas de su unidad, lo que significa que debemos poder crearlos a voluntad. Se elimina prematuramente la flexibilidad de nuestro código, antes de que comprendamos las consecuencias.

Singletons esconde dependencias y aumenta el acoplamiento (cada clase puede depender de un singleton, lo que significa que la clase no puede reutilizarse en otros proyectos a menos que también reutilicemos todos nuestros singletons) y porque estas dependencias no son visibles inmediatamente (como parámetros de función / constructor) ), no los notamos, y normalmente no pensamos en eso cuando los creamos. Es tan fácil simplemente conectar un singleton, actúa casi como una variable local y todo, por lo que tendemos a usarlos mucho una vez que están allí. Y eso los hace casi imposibles de eliminar nuevamente. Terminas, tal vez no con el código de spaghetti, pero con gráficos de dependencia de espagueti. Y tarde o temprano, sus dependencias desbocadas significarán que los singletons comenzarán dependiendo de los demás, y luego obtendrán dependencias circulares cuando se intente inicializar.

Ellos hacen extremadamente difícil la prueba de la unidad. (¿Cómo se prueba una función que llama a funciones en un objeto singleton? No queremos que se ejerza el código singleton real, pero ¿cómo lo evitamos?

Sí, los singletons son malos.

A veces, realmente quieres un global. Luego use un global, no un singleton.

A veces, muy, muy raramente, puede tener una situación donde crear una instancia múltiple de una clase es un error, donde no se puede hacer sin causar errores. (Sobre el único caso en el que puedo pensar, e incluso eso es inventado, es si estás representando algún dispositivo de hardware. Solo tienes una GPU, así que si vas a asignarla a un objeto en tu código, sería tiene sentido que solo una instancia puede existir). Pero si se encuentra en tal situación (y nuevamente, para enfatizar, una situación en la que varias instancias causan errores graves, no solo una situación en la que "no puedo pensar en ningún caso de uso para más de una instancia"), haga cumplir esa restricción, pero hazlo sin hacer también que el objeto sea visible globalmente.

Cada una de estas dos propiedades puede ser útil, en casos excepcionales. Pero no puedo pensar en un solo caso donde la combinación de ellos sea algo bueno.

Desafortunadamente, muchas personas tienen la idea de que "Singletons son globales compatibles con OOP". No, no lo son. Todavía sufren los mismos problemas que los globales, además de presentar otros, que no están relacionados. No hay absolutamente ninguna razón para preferir un singleton sobre un simple viejo global.

Singletons no son "tan malos". Si tiene muchos Singletons relacionados y puede reemplazarlos / consolidarlos usando Factory, sin perder nada que le importe, entonces es cuando debería hacerlo.

En cuanto a los libros, bueno, hay una especie de canon .