design patterns - software - ¿Por qué Singleton es considerado un antipatrón?
patrones de diseño pdf (4)
Creo que se considera un antipatrón porque una clase Singleton no puede ser instanciada de forma normal por otro objeto (excepto llamando a ese método comúnmente llamado "getInstance"). Por lo tanto, parecerá que la clase se está utilizando directamente sin instanciarlo para crear primero un objeto utilizable.
Estoy de acuerdo con usted en que Singleton puede servir como una instancia global única. Aprendí de algunas personas que, como alternativas para Singleton, podemos usar variables estáticas y / o finales, y también podemos usar la enumeración (para que podamos agrupar múltiples variables bajo un nombre de grupo como lo que solemos hacer cuando trabajamos usando un clase / objeto normal).
Sin embargo, estas alternativas solo pueden coincidir con la capacidad de una clase Singleton en el almacenamiento de estados / valores. Si necesitamos funciones únicas para trabajar, esas variables y enumeraciones estáticas / finales no pueden ayudar. En mi opinión, este es el caso cuando necesitamos usar una clase Singleton (cuando necesitamos algunas funciones únicas para trabajar con estados / valores estáticos / finales).
Saludos ... :))
Posible duplicado:
¿Qué tiene de malo Singletons?
Recientemente escuché que Singleton es un antipatrón. Sé que tiene que ver con el hecho de que hacer una clase singleton es como hacer que esa instancia única sea una variable global, pero también está haciendo mucho más que eso (limitando el número de instancias de ese objeto, administrando la creación de instancias, etc.).
¿Por qué exactamente Singleton es considerado un antipatrón? Y cuales son las alternativas?
Los singletons a menudo están mal implementados. Ver doble bloqueo comprobado.
En qué ámbito debe una instancia Singleton ser único. Al igual que los entornos multi-Threaded, clustering, etc.
Singletons puede ser difícil de probar.
La memoria asignada a un Singleton no se puede liberar.
Con el uso excesivo de singletons, se va de la programación orientada a objetos a la programación de procedimientos.
No consideraría exactamente que singleton fuera un antipatrón.
Sin embargo, singleton es básicamente una forma de usar variables globales. Y las variables globales son malas porque cualquier código en cualquier parte del sistema puede cambiar sus valores. Por lo tanto, al realizar la depuración, puede ser difícil determinar qué ruta de código conduce al estado actual del singleton.
Para ayudar con la respuesta, aquí hay más sobre el comentario anti-patrón:
se usa en exceso, introduce restricciones innecesarias en situaciones en las que no se requiere realmente una instancia única de una clase e introduce estado global en una aplicación
De: http://en.wikipedia.org/wiki/Singleton_pattern
Para obtener más información al respecto, puede consultar: https://www.michaelsafyan.com/tech/design/patterns/singleton
Aquí hay un gran final para el blog de arriba:
En resumen, el patrón singleton hace que el código sea más complejo, menos útil y un verdadero dolor para reutilizar o probar. La eliminación de singletons puede ser complicado, pero es una tarea que vale la pena.
De acuerdo, entonces, la razón por la que se trata de un antipatrón se describe bien en este párrafo y, como expresa el autor, ajusta fuertemente el código al singleton.
Si encuentra que desea utilizar un singleton, es posible que desee considerar su diseño, pero hay momentos en los que es útil.
Por ejemplo, una vez que tuve que escribir una aplicación que podría tener como máximo una conexión de base de datos, para procesar miles de solicitudes. Por lo tanto, un singleton tiene sentido ya que tengo recursos limitados a tener solo una instancia.
Pero, generalmente esto se usa para simplificar el código, sin pensar en las dificultades que se introducirán.
Por ejemplo, y esto también se aplica a las clases estáticas, si prueba una unidad, o tiene concurrencia, entonces el estado de una solicitud cambiará el estado y eso puede causar problemas, ya que la clase que llama a la instancia puede estar asumiendo que el estado es como esperado.
Creo que la mejor manera de desafiar el uso es pensar en cómo manejarlo si su programa es de subprocesos múltiples, y una manera simple de hacerlo es probarlo en unidades, si tiene varias pruebas que se ejecutan a la vez.
Si encuentra que aún lo necesita, utilícelo, pero descubra los problemas que se presentarán más adelante.