Patrón Singleton

Question

¿Cuándo deberíamos usar el patrón Singleton y por qué?

Answer 1

En teoría: cuando necesita restringir la creación de instancias de un objeto a una instancia. En la práctica: nunca.

Answer 2

Si tiene una situación en la que se necesita exactamente un objeto para coordinar acciones en el sistema, puede usar este patrón. Un buen ejemplo de esto es Facade, es decir, las Fachadas se pueden implementar como singleton porque a menudo se necesita un objeto Facade en todo el sistema.

Pero, en general, suele ser una mala práctica y debe evitarse, una de las principales razones es que inhibe enormemente la extensibilidad.

Answer 3

http://sites.google.com/site/steveyegge2/singleton-considered-stupid

¿Por qué el Singleton tan atractivo? Seré el primero en admitir: me gustó también. No, rayar eso - I amaba el Singleton. Se sintió como un viejo amigo desde el momento en que lo vi. Fue simple y hermoso.

Te diré por qué: es porque el patrón Singleton es un retroceso a la programación no OO. Es un salvavidas para las personas que no entendieron una sola palabra que The Gang of Four intentaba decir. No sé cómo llegó allí, en primer lugar, algo de presión política de OOPSLA, sin duda, pero no pertenece allí. Es Mal ...

Aquí está el resumen "corto" ...

a) no han cubierto ni la décima parte de los problemas. Pero nombraré algunos de ellos.

b) Una es la gestión de la memoria; un Singleton es básicamente solo una pérdida de memoria, si nadie va a usarlo por un tiempo. Pero no tienes idea de cuándo desasignarlo, porque nadie va a llamarte y decir "¡nadie te va a usar por un tiempo!"

Además, no se puede decir quién se ha mantenido cerca de las referencias a su instancia de Singleton, ya que usted fue bastante fabuloso con la distribución, ¿no? (Nota: las referencias débiles de Java pueden ayudar con este problema).

c) Hablando de pérdidas de memoria, ¿qué pasa si su Singleton tiene un control sobre algún recurso limitado, como una base de datos o un manejador de archivo? Supongo que debes mantener ese tonto abierto hasta que finalice tu programa. Gracias a Dios, los programas de C++ nunca duran más de 10 minutos antes de fallar, generalmente se están quedando sin recursos, o de intentar acceder a un Singleton que alguien liberó.

d) Otro problema es que el diseño de Singleton es sintácticamente ruidoso; la mayoría de los idiomas no lo soportan (bueno, Ruby lo hace, lamentablemente, pero eso fue probablemente antes de que Matz lo supiera), así que tienes que seguir el código repetitivo no solo en Singleton, sino en todos los que lo usan.

e) Luego está la cosa de subclases. Es casi imposible crear una subclase de Singleton, y si la administras, entonces no deberías haber estado usando Singleton en primer lugar. Usted no , incluso quiere ir allí. He recorrido caminos que no me atrevo a contar. Solo pretenda que no puede hacerlo, y se ahorrará una cantidad increíble de dolor.

f) métodos estáticos son tan flexibles como el granito. Cada vez que usa uno, está proyectando parte de su programa en concreto. Solo asegúrate de no tener el pie atascado mientras lo ves endurecerse. Algún día te sorprenderá que, por Dios, realmente necesites otra implementación de esa clase de PrintSpooler, y debería haber sido una interfaz, una fábrica y un conjunto de clases de implementación. D'oh!

Supongo que eso es todo. Hay muchos otros problemas. Por ejemplo, intenta agregar multihilo en y ver qué pasa. Bueno, te diré lo que sucede: la mitad del tiempo, obtienes un Doubleton o un Tripleton, a menos que seas un experto en sincronización, y tener un Tripleton es tan deseable como tener tres Balrogs en tu fiesta de té. E incluso si eres un experto en sincronización y obtienes correctamente el doble control idiomático, todavía tienes que lidiar con un Balrog, y no son un día de campo.

Pero estos problemas se desvanecen en la insignificancia todo en comparación con el grande, y es que el Singleton "patrón" le invita a olvidar todo lo que sabe acerca de diseño orientado a objetos, ya que es difícil OO, y procedimental es fácil ...

Answer 4

Cuando desee que un conjunto de objetos diferentes puedan hacer referencia a un solo objeto. Tal vez quieran que todos usen el mismo PhysicsEngineDude o algo así ... ¡No querrás objetos diferentes que tengan diferentes modelos de física cuando vivan en el mismo mundo!

Answer 5

Cuando solo necesita una instancia de una clase. Uno de los mejores ejemplos es el registrador. Solo necesitas una instancia de esto.

Answer 6

Cuando solo hay una instancia de una clase que se necesita en el sistema. Dado que solo tiene una instancia, puede decidir de forma rígida cómo los usuarios pueden acceder a ella.

Answer 7

Como dije, la intención de un patrón singleton es asegurar que una sola instancia de una clase sea instanciada.

El patrón singleton se considera como uno de los patrones "incorrectos" en el GOF pattern catalog ya que el singleton conduce al acoplamiento en el código y hace que la prueba (unidad) del código sea difícil. El último punto no es 100% verdadero en (la mayoría) de los lenguajes de tipo dinámico/flojo porque puedes usar el código de parche de mono.

Echemos un vistazo al acoplamiento: cada pieza de código que utiliza Singleton se acopla directamente a la implementación de Singleton. Esto es difícil/imposible de simular y, dado que los Singleton se usan a menudo para servicios de infraestructura como una capa de acceso a la base de datos, la unidad que desea probar está acoplada a la implementación concreta de la capa de acceso a la base de datos. Pero para una prueba unitaria no desea golpear la base de datos, quiere tener alguna capa de acceso de datos falsa. Usted termina en una situación en la que se pregunta por qué utilizó el patrón singleton.

Recomendaría el patrón de singleton solo para software "simple" pero como todos sabemos, el software tiende a crecer. Para comenzar complejo simple y final después de algunos años.

Answer 8

Cuando no desea crear varias instancias del mismo tipo, necesita ir a singleton. Pero lo mismo se puede lograr si usa clases estáticas. Entonces, el punto aquí es que no es la única instancia, sino el control sobre la creación de instancias, evitando así el consumo innecesario de recursos preciosos.

Answer 9

Piense en todo en donde más de una instancia sería un error (inconsistencia). Esto podría ser un objeto Aplicación (objeto raíz para una aplicación) o un administrador de seguridad de toda la aplicación, etc. El singleton es solo una forma de hacer cumplir que en clase solo puede tener una instancia.

Answer 10

• En la ingeniería de software, el patrón Singleton es un diseño
  patrón que restringe la creación de instancias de una clase a un objeto.
  Esto es útil cuando se necesita exactamente un objeto para coordinar
  acciones en todo el sistema.

• La aplicación necesita una y solo una instancia de un objeto.
  Además, la inicialización lenta y el acceso global son necesarios.

Más aquí ...

http://www.dzone.com/links/r/java_ee_singleton_design_pattern_introduction.html

Answer 11

El patrón Singleton se debe utilizar cuando se quiere cumplir sólo una instancia de una clase creada en su aplicación. Esto podría deberse a que:

• la creación de estos objetos es intensivo en recursos

• el objeto es un objeto de nivel de aplicación; por lo tanto, tener instancias múltiples de ellos no tiene sentido.

Por lo tanto, diseñar una clase como singleton tiene sentido. Para obtener más información, consulte singleton design pattern explained with c# .net example

Answer 12

El patrón Singleton está a punto de garantizar que una clase tenga solo una instancia y proporcione un punto de acceso global a ella.

Answer 13

Java Runnable es el mejor ejemplo del Singleton Pattern. Cuando desee agregar una restricción que no le permita crear más de instancia única de una clase particular, entonces es mejor implementar un Singleton Pattern. puntos clave para implementar Singleton:

• constructor privado
• estático Instancia Privada variable de la propia clase Singleton

• captador Pública método sólo a primera vez que se inicializará por encima de la variable, y siempre devuelve la misma instancia de una clase Singleton.

  class Singleton { 
  
       private static Singleton instance; 
  
       private Singleton(){ 
       } 
  
       public static Singleton getInstance(){ 
       if(instance=null){ 
        instance=new Singleton(); 
       } 
  
       return instance; 
       } 
       ........ 
      } 
  

  Y para seguridad de los subprocesos: getInstance() necesita ser sincronizado.